3 ms·

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 in

by devmor 1y ago

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.

avianlyric 1y ago
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.
- majkinetor 1y ago
  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.
  - ifwinterco 1y ago
    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
    - concerned_user 1y ago
      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/integrationGuidelines/gettingStarted/authorize.html 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.
      - ifwinterco 1y ago
        That would make sense, and I guess if you tried something suspicious (larger order to a new address), you would get the full auth flow
      - avianlyric 1y ago
        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.
    - lxgr 1y ago
hakfoo 1y ago
A lot of the time, that's still API smoke and mirrors. The API call is labelled "sale", but it performs an auth and at the end of the day the system still generates a capture or settlement-style message.
- devmor 1y ago
  To an extent, yes. But functionally it doesn’t matter to the client of the gateway (or their downstream users, the cardholders). If the gateway allows you to complete a sale request at 7am that doesn’t start an auth until 9pm, you have an offline payment by any other name.
lxgr 1y ago
What gateways are you thinking of? Effectively all international card networks require online authorizations for almost everything.
- devmor 1y ago
  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.

by devmor 1y ago

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.

avianlyric 1y ago

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.

majkinetor 1y ago
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.
- ifwinterco 1y ago
  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
  - concerned_user 1y ago
    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/integrationGuidelines/gettingStarted/authorize.html 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.
    - ifwinterco 1y ago
      That would make sense, and I guess if you tried something suspicious (larger order to a new address), you would get the full auth flow
    - avianlyric 1y ago
      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.
  - lxgr 1y ago

hakfoo 1y ago

A lot of the time, that's still API smoke and mirrors. The API call is labelled "sale", but it performs an auth and at the end of the day the system still generates a capture or settlement-style message.

devmor 1y ago
To an extent, yes. But functionally it doesn’t matter to the client of the gateway (or their downstream users, the cardholders). If the gateway allows you to complete a sale request at 7am that doesn’t start an auth until 9pm, you have an offline payment by any other name.

lxgr 1y ago

What gateways are you thinking of? Effectively all international card networks require online authorizations for almost everything.

devmor 1y ago
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.