| ▲ | alberth 4 days ago |
| Re: transition to micro services (from monolith). I’m surprised a network so sensitive to latency (as are payment networks), was able to achieve their latency SLAs with micro services. Maybe Amex being a closed-loop network helps with latency? |
|
| ▲ | skrtskrt 4 days ago | parent | next [-] |
| Every major high-throughput database now runs as microservices, not sure why people still act like things just grind to a halt when the network is involved. |
| |
| ▲ | usrnm 3 days ago | parent [-] | | High-throughput is not the same thing as low latency. In fact, they're often at odds with each other |
|
|
| ▲ | mattclarkdotnet 4 days ago | parent | prev | next [-] |
| Since when were payment networks latency sensitive? It’s usually 2 or more seconds to even get a payment up on the card terminal from the merchant POST system, then 2-5 seconds more from card presentation to getting approval back. |
| |
| ▲ | inkyoto 3 days ago | parent | next [-] | | > Since when were payment networks latency sensitive? Since the advent of e-commerce, POS-networking and fraud detection systems in 1990's-2000's. User-facing and authorisation path are highly latency sensitive. It includes tap-to-pay, online checkout, issuer authorisation, fraud decisioning, and instant payment confirmation – even moreso for EFT payments. > […] 2-5 seconds more from card presentation to getting approval back. This is the mid-1990's level QoS when smaller merchants connected the acquirer bank via a modem connection, and larger ones via ISDN. Today, payments are nearly instant in most cases, with longer than one-second card payment flows falling into the exceptions territory or inadequate condition of the payment infrastructure. | |
| ▲ | alberth 4 days ago | parent | prev | next [-] | | I’m fairly certain that’s a POS issue, not the payment network. I’ve heard anecdotally that it’s < 140 ms for payment networks. Anyone, please correct me if you know better. | | |
| ▲ | solumos 4 days ago | parent | next [-] | | It's definitely not 140ms round-trip. Issuer processors typically have a ~2.5s window for approval. In practice, the POS sends a message to the acquirer processor -> hits the network -> is sent to the issuer processor, and back again. https://medium.com/wharton-fintech/the-anatomy-of-the-swipe-... | | |
| ▲ | Spiff1985 3 days ago | parent [-] | | yeah, if the card is an EMV chip card, and might also have a SVA so everything is handled between the terminal and card, it can be blazingly fast. In EU they use of offline PIN was used massively before PSD2 and contactless, that made the terminal request during the time it took for validating the transaction online, and basically as soon as the PIN was ok'ed by the card that confirmed the transaction. That gave a perception of speed. Now it's basically online PIN mostly or contactless, but that means you perceive a "wait for an ok", that you had before but was masked by the PIN capture and check on device/card. So we went a bit backwards for cards, but wallets like ApplePay went a bit forward. You win some you lose some I guess |
| |
| ▲ | felipellrocha 4 days ago | parent | prev [-] | | 140ms is still a ton of time to do a simple transaction | | |
| ▲ | ivlozada 4 days ago | parent [-] | | It's not simple though. In that 140ms the network is checking fraud rules, validating the card, checking available credit, applying rewards logic, and routing across multiple parties. The actual subtract-one-number-from-another takes microseconds. The rest is trust verification across organizational boundaries — which is the hard part of any payment system. | | |
| ▲ | mattclarkdotnet 3 days ago | parent [-] | | At best it’s checking available credit. All the other stuff is done after the fact. The idea that any banking transaction involves “subtracting one number from another” is so wrong it’s barely worth engaging with. | | |
| ▲ | dcrazy 3 days ago | parent | next [-] | | You speak so confidently, yet it appears you’ve never gotten a text asking you to approve or deny a charge that you are performing. | |
| ▲ | skywhopper 3 days ago | parent | prev [-] | | Some (rewards processing) is probably done later, but the fraud check definitely isn’t. |
|
|
|
| |
| ▲ | compounding_it 3 days ago | parent | prev | next [-] | | >Since when were payment networks latency sensitive? Apple Pay is extremely fast from my experience (at least the web version). There is a high percentage of market loss if payments take long or fail. Im sure there must be a graph for where it plateaus with diminishing returns when it comes to speed but faster payments definitely help with sales. | |
| ▲ | hrmtst93837 3 days ago | parent | prev [-] | | [dead] |
|
|
| ▲ | bob1029 3 days ago | parent | prev | next [-] |
| > Maybe Amex being a closed-loop network helps with latency? Yes, this is a huge deal. VisaNet and friends have to wait on the actual bank cores in order to perform online authorization. Amex can guarantee end to end latency. |
|
| ▲ | dzikimarian 3 days ago | parent | prev [-] |
| Doesn't matter if you have 500 microservices if only one or two take part in card authorization (as it should be if microservices were architected correctly). There's ton of logic on non-critical path that can be extracted to other microservices and called asynchronously - settlements, refunds, rewards, all management and reporting functionalities - to name just a few. |
