News for hackers. Stuff that matters.
Re:Privacy API: Programmable Payments by boling11 on Thursday July 12, 2018 @03:28PM (#17517822)
Hey there! I'm really sorry to hear about the negative experience.

I can't speak to a specific case on a public forum. However, you are correct that in very rare cases, merchants can push through transactions without prior authorization - it's against card network rules, and it’s typically a simple chargeback to win. Even in cases where we don’t win, we typically cover out of pocket.

I’m happy to look into this. Can you shoot me a note at [email protected]?

Re:Privacy API: Programmable Payments by tomnipotent on Thursday July 12, 2018 @11:35PM (#17520339)
> merchants can push through transactions without prior authorization

Why was the transaction not denied? What entity was responsible for the authorization? Trying to understand if your network was involved at any point during that transaction, and if so why a charge was allowed to go through. I'm aware that pre-auth for automatic billing can get pass closed accounts at traditional CCs, but if Privacy.com follows that same practice than doesn't that sorta defeat the purpose of disposable numbers?

Re:Privacy API: Programmable Payments by ikeboy on Friday July 13, 2018 @07:34AM (#17522011)
Google force post debit card transaction, several posts explaining (e.g. https://blog.crossplainsbank.com/force-sale-transactions-to-...).

Issuer doesn't get a say but can charge back after the fact. Seems like a flaw to me.

Re:Privacy API: Programmable Payments by boling11 on Friday July 13, 2018 @03:22PM (#17525894)
Force post transactions are literally when a merchant takes the money of the account without requesting authorization, so there is no opportunity to decline the transaction.

This very rarely happens. You won't see any big merchants like Spotify or Netflix doing this because you closed a card to cancel a subscription.

Speaking broadly, there is often some type of fraud, suspicious activity, or a serious loss potential for merchants to resort to this.

Examples - if you rent a car and don't return it, borrow books and don't return them, or abuse generous return policies (return items that are clearly not what you purchased).

All that said, even if we don't win the chargeback, we still often credit the user out of pocket in the interest of giving the user the benefit of the doubt.

Re:Privacy API: Programmable Payments by tomnipotent on Tuesday July 17, 2018 @02:56AM (#17547839)
This is fascinating. Thanks!
Re:Privacy API: Programmable Payments by ikeboy on Thursday July 12, 2018 @04:30PM (#17518354)
I'll look up the emails and forward to you. I think I was covered for some, then I stopped getting responses. Wasn't all force post, but the disputes process wasn't great on the other ones either (had to write a long reason for disputing, minimum word length enforced, when "didn't authorize charge" or the like wasn't enough).
Re:Privacy API: Programmable Payments by ikeboy on Thursday July 12, 2018 @07:10PM (#17519371)
Sent you an email. Looks like I did get refunded for the force post, but had issues later with other transactions.