Where an international payment actually dies
Before fixing anything, it helps to know where the bodies are. A cross-border card payment can fail at six distinct points, and each demands a completely different remedy.
- At the form. The buyer mistypes, gets confused, or abandons before submitting anything at all.
- Before authorisation. The request is malformed, the card is invalid, or something about it was never going to be approved.
- In transit. A connection to the acquirer or card network is slow, saturated, or times out.
- At the acquirer. The transaction is routed through a processor poorly positioned for that card, that country, or that moment.
- At the issuer. A bank on the other side of the world declines — because of risk, a soft limit, or simply because the transaction looked foreign and unfamiliar.
- At 3D Secure. The challenge is imposed, the buyer is bounced to a bank page, and never comes back.
A merchant who moves from 85% to 96% has not solved one of these. They have chipped away at all six.
1. How you connect to the card networks is not a detail
Every card transaction eventually reaches a scheme - Visa, Mastercard, RuPay, Amex, and others. That much is not optional, and it is the same for everyone. What is entirely optional — and what separates a good processor from an ordinary one — is how you get there.
Persistent connections and connection pooling
The naive implementation opens a connection, performs a TLS handshake, sends an authorisation request, receives a response, and closes. This is ruinous at scale, because the handshake alone can cost more time than the authorisation itself — and it pays that cost on every single transaction.
We hold warm, persistent, pooled connections to our network and acquirer endpoints. The TLS session is already negotiated. The socket is already open. When an authorisation arrives, it travels down a connection established long before the buyer clicked pay.
Under load, this is also what prevents collapse. A connection pool exhausts long before a card network does, and an exhausted pool looks — to the merchant — exactly like a payment failure. Sizing, monitoring and gracefully queueing against that pool is unglamorous work nobody gives conference talks about, and it is worth more success-rate points than most of the things people do give talks about.
Your gateway to seamless payments!
Accept 120+ global currencies | 33+ payment methods | Instant FIRA
Get started →
Where you connect from matters
Geography is not negotiable. A connection to a network endpoint that is physically closer, over an optimised path, completes faster — and a transaction that completes faster is a transaction that has not timed out. This is the same argument we made about edge computing, applied to the back of the system rather than the front.
Never send a transaction that was always going to fail
This is the idea that most improves a success rate, and the one most often overlooked, because it is counter-intuitive: the best way to reduce failed authorisations is to send fewer authorisations.
Every doomed transaction you forward to an issuer costs you three times over. It burns latency. It contributes to a decline ratio that issuers themselves watch and quietly penalise you for. And it converts a problem you could have solved instantly, on the page, into a hard decline the buyer experiences as rejection.
So a great deal of engineering happens before the authorisation request is ever constructed.
- Validation at the edge. Card checksums, expiry sanity, CVV format, address structure — caught in milliseconds, on the buyer's own screen, while they are still engaged and can fix it.
- BIN intelligence. The first digits of a card identify the issuing bank, the country, the card type and the network. That tells you how to route it, which currency to present, whether 3D Secure will be demanded, and whether this issuer behaves better through one acquirer than another. Knowing all of that before authorisation is the difference between an informed request and a hopeful one.
- Device and session signals. Is this a real browser, a real device, a coherent session? Screening here catches traffic that was never going to convert and would only have polluted our decline ratios.
- Risk pre-checks. A transaction our risk engine will reject anyway should never consume an authorisation attempt.
"A decline is a neutral outcome you record. It is a cost you pay, and an issuer remembers."
Caching: the same lookup, ten thousand times a second
A payment request needs a surprising amount of reference data before it can be routed — BIN tables, merchant configuration, currency and FX reference rates, routing rules, tokenised card records, issuer behaviour history. Almost none of it changes between one transaction and the next.
Fetching that from a database on every transaction adds latency to the one path where latency is most expensive, and puts load on the one system — the ledger — that is hardest to scale. So it is cached aggressively, close to where the decision is made, with invalidation that is careful rather than clever.
Caching a BIN table sounds like the least interesting decision in a payments platform. It removes milliseconds from every authorisation, and milliseconds are what timeouts are made of.
Routing and fallbacks: never have one way home
A merchant with a single acquirer connection has a success rate entirely hostage to that acquirer's worst day.
Issuers do not treat all acquirers equally. A US-issued card presented through one processor may be approved, and through another declined — same card, same buyer, same amount, different path. Acquirers also have outages, degradations and regional weaknesses, and none of them will warn you in advance.
So we maintain multiple paths and choose between them per transaction, using the BIN intelligence gathered before authorisation: card country, issuer, network, amount, currency, and each route's recent approval behaviour. When a route degrades — rising latency, rising declines, timeouts — traffic moves away from it automatically, without a human noticing at three in the morning. This is what sits underneath PayGlocal's card processing, and it is one of the few interventions genuinely worth several points on its own.
Retries: intelligent, or actively harmful
Retrying a failed payment is either one of the highest-return things you can do or one of the most damaging, and the difference is entirely in the discipline. The rules we hold to:
Never retry a hard decline. A stolen card, a closed account or an explicit refusal will be refused again. Retrying it irritates the issuer, damages your decline ratio, and can look like an attack.
Retry soft failures — timeouts, temporary issuer unavailability, network errors, transient risk holds. These are precisely the failures that were never about the card at all.
Retry on a different path when the decline suggests the route was the problem, not the buyer.
Retry with idempotency, always. Every request carries an idempotency key, so a retry can never become a double charge. This is not negotiable, and it is the only reason we are able to retry aggressively at all.
Retry with timing that reflects why it failed, not on a fixed schedule.
A blind retry loop is not a success-rate strategy. It is a way to turn one failure into several.
The front end is a payments system too
It is tempting for an infrastructure team to treat the checkout page as somebody else's problem. It is the single largest source of lost international payments.
The transaction that fails at the form never appears in any authorisation metric. It is invisible — which is precisely why it goes unfixed. A field that rejects a correctly-typed international phone number. A form that will not accept a UK postcode. An address block that assumes an Indian PIN code. A price shown in rupees to a buyer thinking in dollars. A 3D Secure challenge thrown at someone who did not expect one. Each of these is a payment lost before the card network was ever contacted.
So the checkout is engineered with the same seriousness as the authorisation path. Dynamic Checkout is localised to the buyer's country and currency, tolerant of international address and phone formats, served from the edge so it renders instantly, and designed to capture everything we need for a clean authorisation without ever asking the buyer to work for it.
Every additional field is a tax on conversion. Every piece of information we can infer instead of ask is a payment we do not lose.
And on 3D Secure: authentication is not optional where it is mandated, but a frictionless flow — where the issuer is given enough signal to approve without challenging the buyer — is the difference between an authenticated payment and an abandoned one. Supplying that signal richly and correctly is engineering work, and it is worth points.
Why this is the whole point of PayGlocal
PayGlocal was not built to be another way to accept a card. It was built on a specific conviction: that Indian businesses selling to the world were quietly losing a large share of their international revenue to payment infrastructure never designed for them — global platforms retrofitted to India, or Indian platforms retrofitted to the world. Running inbound collections and outbound payouts on one authorised stack is what lets us see, and fix, both halves of that problem.
Nothing on the list above is a headline feature. Connection pooling, BIN caching, retry discipline, fallback routing, an address form that accepts a British postcode — none of it will ever appear on a billboard. But this is the work, and it is what the eleven points are made of.
There is no single thing that takes a merchant from 85% to 96%. There are fifteen things, each worth half a point, and someone has to care about all of them. That is the job.
What this costs, and what it returns to the merchant
Here is what makes this more than an engineering exercise.
Every intervention above increases the revenue a merchant earns from infrastructure we are already paying to run. A transaction recovered by an intelligent retry, or approved because it was routed through the right acquirer, or completed because the checkout rendered instantly from the edge, costs us essentially nothing extra to process. The servers, the connections and the engineers were paid for regardless.
Which makes success-rate engineering the rarest thing in infrastructure: work that raises merchant revenue and lowers our cost per transaction at the same time. Fewer wasted authorisations. Fewer doomed requests. Fewer retry storms. Less support load. A cheaper platform, and a better one, in the same motion.
Every rupee we take out of our cost per transaction is a rupee we can return to the merchant in pricing. Every point we add to their success rate is revenue they were already owed. That is the entire reason this work exists.
Ready to stop losing international payments?
PayGlocal runs international and domestic payments on one RBI-authorised stack, with acceptance across 180+ countries and payment success rates up to 96%. If your international payments are failing and you do not know where, that is usually because they are failing in six places at once.
Talk to our team, or read the APIs at
docs.payglocal.inYour gateway to seamless payments!
Accept 120+ global currencies | 33+ payment methods | Instant FIRA
Get started →
