Eleven points is not a rounding error
A payment either succeeds or it does not. There is no partial credit, and there is no second impression.
For an Indian business accepting international cards, the difference between a mediocre payment setup and a well-engineered one is roughly the difference between an 85% and a 96% success rate. Written down like that, it sounds like a technical footnote. It is not. It is eleven percent of everything the merchant sells overseas, disappearing — sometimes at an issuing bank in another country, and sometimes long before that, in a buyer who simply gave up.
And these are not marginal customers. A buyer at an international checkout is the most expensive visitor a merchant will ever have. They have been advertised to, persuaded, and are sitting there with a card in their hand. Losing them at the final step is the single most costly failure in the entire funnel.
The question we get asked most often is what the fix is. The honest answer is the one nobody wants to hear:
There is no silver bullet. A high success rate is not one clever thing. It is fifteen unglamorous things, each worth half a point, that nobody wants to do.
This is the list of those things.
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.
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.
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.
A decline is not 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.
Frequently asked questions
What is a good payment success rate for international transactions?
For Indian businesses accepting international cards, a poorly optimised setup typically sits around 85%, while a well-engineered one reaches roughly 96%. That eleven-point gap is not a technical statistic — it represents eleven percent of the merchant's overseas revenue, lost either at the issuing bank or at an abandoned checkout.
Why do international card payments get declined more than domestic ones?
Because there are more places to fail. A cross-border transaction crosses more networks, meets an issuer unfamiliar with the merchant, attracts greater fraud suspicion, is more likely to trigger a 3D Secure challenge, and is far more exposed to latency and timeouts. Each of these adds decline risk a domestic payment simply does not carry.
How can a merchant improve their payment success rate?
There is no single fix. Success rate is the sum of many interventions: persistent pooled connections to the card networks, validation and BIN intelligence before authorisation so doomed transactions are never sent, aggressive caching of reference data, multiple acquirer routes with automatic failover, disciplined retries that never repeat hard declines, and a localised checkout that does not lose the buyer before the payment is even attempted.
What is smart routing in payments?
Smart routing means choosing the best acquirer path for each individual transaction rather than sending everything down one connection. Issuers do not treat all acquirers equally — the same card can be approved through one processor and declined through another. Routing decisions use the card's BIN data (issuing bank, country, card type), the amount, the currency, and each route's recent approval and latency behaviour, and traffic is moved away automatically from any route that degrades.
Should failed payments be retried automatically?
Only selectively. Soft failures — timeouts, transient issuer unavailability, network errors — should be retried, ideally on a different route. Hard declines such as a stolen card or a closed account should never be retried: the issuer will refuse again, and repeated attempts damage the merchant's decline ratio. Every retry must carry an idempotency key so it can never result in a double charge.
Does checkout design affect payment success rates?
Substantially, and invisibly. Payments lost at the form never appear in authorisation metrics, so they are rarely fixed. An address field that rejects a valid UK postcode, a phone field that assumes an Indian number, a price shown in rupees to a buyer thinking in dollars, or an unexpected 3D Secure challenge will each lose the payment before the card network is ever contacted.
What is a BIN and why does it matter for payment routing?
The BIN (Bank Identification Number) is the first six to eight digits of a card, identifying the issuing bank, the country, the card type and the network. Reading it before authorisation lets a payment platform decide how to route the transaction, which currency to present, whether 3D Secure is likely to be required, and which acquirer historically performs best for that issuer — turning a hopeful authorisation request into an informed one.
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.in
