A lot of internet payments work this way already anyways, not many gateways require auth before capture, processors/payfacs just do it because it gives lower interchange and reduces risk.
That depends on where you are. But all the major networks expect auths before capture, even if it isn’t technically enforced, and will punish gateways and merchants who have low auth rates.
Auth before capture doesn’t generally reduce interchange. What it primarily does is shift liability in the event of a dispute. If a chargeback is raised, and no auth happened, then the merchant simply looses immediately. They have no mechanism for fighting the chargeback. If they auth first, and got an approval, then it’s the banks problem in the event of a customer dispute. The merchant can reply to the chargeback by pointing out the valid auth they received from the bank, and the bank has to go pound sand.
You may see this as different “interchange” rates from a specific gateway. But that’s simply not true at the network level. The difference in pricing just exists so the gateways themselves can price in the additional risk associated with auth less captures, given the gateways are always on the hook, even if a merchant goes bust. The major networks force gateways to have funds kept in escrow that are guaranteed to cover any shortfall that might occur due to individual merchant failure, or failure of the gateway itself. That how networks make sure that zero real risk every accrues with them, they make everyone else put up huge stacks of cash to ensure that every virtual cent that’s in flight at any moment, is backed by a real cent in escrow somewhere.
I always wondered how come that some online merchants where I record the card do not ask for auth or 2 factor and some other does. For example, I have recorded my card info in a webapp that I use to pay the bills, and it never asks for anything, which is good, as I have many bills to pay, and I wouldn't want spam of 2FAs. Can you provide some technical terminology on this behavior or links, since you seem to be in the knows. Thanks.
Amazon as well seems to never do proper auth (at least here in the UK). When using an existing card where the delivery address matches the billing address, card transactions go through instantly
There is no rule that there has to be a single payment per authorization, if you read for example mastercard API https://in.gateway.mastercard.com/api/documentation/integrat... it says you can partially capture, you can extend authorization. So for all you know when you buy at amazon it just updates the authorization and charges you later but keeps authorization going and amazon might just check if they have auth token for your card and if they do system allows you to continue and to you it seems instant.
It’s a lot more complicated and nuanced than that. The API docs you link too are for an API that covers a tiny fraction of what can be expressed in the actual ISO 8583 messages which are the real “API” of the card networks. The docs for those are hundreds of pages long.
Plus you need to analyse how the different messages types and sequence of messages interact with the transaction processing rules, which are also hundreds of pages long.
Suffice to say, the entire system is insanely complicated, and just about everyone out there implements it all incorrectly, with the whole system on working because partners are only allowed to complain about the insanity if they actually loose money. Until that point they’re expected to just handle everything as best they can.
Ultimately all this stuff comes down to risk and risk management. The card networks themselves don’t provide any technical enforcement of most of their rules, beyond low level technical rules around message format and structure (and even that enforcement is pretty small).
Instead they effectively make all the parties that connect to the network responsible for rule enforcement. If a merchant follows all the rules correctly then they receive extremely strong chargeback protection, I.e. if an issuer sends a chargeback, and the merchant has plenty of grounds to dispute the chargeback and win.
If merchants don’t follow all the rules, then issuers can send chargebacks, and it’s much harder for the merchants to defend themselves.
In all scenarios it up to the issuers and merchants to explain in the chargeback what rules have been broken, by which party, and thus who should win based on network transaction rules. The networks themselves don’t even make a ruling directly, instead the issuer and merchant decide who wins via a back and forth process that includes escalating fees paid to each other, until one side gives up. The networks only get involved the two sides can’t resolve the issue themselves, and will charge the looser a significant fee for the privilege, so there’s a strong incentive for the parties to resolve the issue themselves.
How does of this interact with 2FA, auths etc etc. Basically 2FA, and ordinary auths are all just things a merchant can do, or trigger, to reduce their liability and get better chargeback protection. If the merchant performed a full 3DS auth, where the issuer is asked to perform 2FA, then they have pretty complete chargeback protection in the event of fraud, because they’ve basically asked issuer to make absolutely 100% that this transaction has been approved by the issuer’s customer, so there’s zero grounds later to claim that a stolen card was used or something similar. If the issuer’s customer wants to dispute the transaction, that’s the issuers problem.
But all of these mechanisms reduce checkout rates, and thus merchant revenue. As a result some extremely large merchants make a trade off of basically accepting all the risk of fraudulent transactions, and give up chargeback protection, but not following all the rules. The merchant does this because they’ve basically asked believe they have enough data to prevent fraudulent transactions, without using any of the tools the card networks provide.
For merchants that can do this (like Amazon), they build in-house fraud detection systems, and payment systems that evaluate the risk of each transaction, then change the exact way they perform the transaction to either reduce friction (because the transaction is very low risk) or increase friction (because the transaction is higher risk), thus allowing them to capture more revenue, without taking on more risk (because they have confidence their ability to detect fraud, and thus don’t need help from the issuers).
But there are very few merchants that can even do this, as it generally requires either a very collaborative payment gateway (who are ultimately on the hook for merchant misbehaviour), or a direct connection to the card networks (who aren’t interested in talking to people not moving millions of dollars every day). Which is why it tends to pretty rare.
The way gateways and networks handle auth are not the same thing and it gets really muddy and confusing, honestly.
If you’ve already tokenized the card on a gateway for a particular merchant, for example, they may allow you to keep pushing multiple charges while on their end still using the original network auth from the first tokenization - which ends up being entirely opaque to you, the client of the gateway.
Essentially you don’t have to care what the card network rules are, just how your gateway presents functionality to you.
