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.
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!
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?