International payments fail on Indian checkouts for four reasons: the issuer declines on cross-border risk, 3D Secure authentication drops the customer before authorisation is ever attempted, the card or billing data does not match what the issuer holds on file, or the transaction is routed through a path the issuer does not recognise or trust. Most Indian businesses selling globally see somewhere between 15% and 25% of foreign card attempts fail. The majority of those failures are recoverable, and the recovery is an engineering problem, not a sales problem.

• The four gates every cross-border payment has to clear
• What each decline code actually means, and whether a retry helps
• Why the same card that works on a US checkout fails on an Indian one
• The seven changes that move authorisation rates, ranked by impact

A cross-border payment has to clear four gates

Domestic payments fail at one place: the issuer says no. Cross-border payments can die at four, and three of them happen before the issuer has seen anything.

1. Data capture — Card, billing, device signals. Failure mode: incomplete request.
2. Authentication — 3D Secure challenge or frictionless. Failure mode: silent abandonment.
3. Routing — Which acquirer, country, currency. Failure mode: foreign-acquired.
4. Authorisation — Issuer risk model decides. Failure mode: decline code returned.

Only gate four returns a code. Gates one to three fail quietly.

01. Data capture

The checkout collects the card, and often the billing address, the email, and the device fingerprint. Indian checkouts are usually built for domestic flows, where address data is not part of the authorisation decision. Foreign issuers use it heavily. A checkout that does not collect and forward billing data is sending an incomplete request to an issuer that penalises incomplete requests.

02. Authentication

3D Secure is where the largest silent loss happens, because most of it is invisible in your decline reports. If a customer is challenged, redirected to their bank, and abandons, there is no decline code. There is only a transaction that never completed. Cardholders in markets where step-up challenges are rare treat an unexpected bank redirect as a phishing attempt and close the tab.

03. Routing

Which acquirer receives the transaction, in which country, in which currency, determines how the issuer sees it before it evaluates anything else. This is the gate most Indian merchants do not know exists, because in a domestic stack there is nothing to route.

04. Authorisation

The issuer decides. By this point the decision is already heavily shaped by what happened at gates one through three.

The decline codes that matter

Response codes are defined by the card networks and returned by the issuer. The wording varies slightly between Visa, Mastercard, Amex and local schemes, but the operational meaning is stable. Below are the codes that account for most cross-border failures on Indian checkouts.
One note on code 05. It is a bucket, not a diagnosis. When an issuer does not want to tell you why it declined, it returns 05. Any provider claiming to know precisely why a given 05 occurred is guessing. What you can do is change the conditions under which the request is made and watch the 05 rate move.

Soft declines and hard declines

The distinction matters more than the individual codes, because it determines whether a retry is a recovery or a violation.

Soft declines are temporary. The issuer might approve the same transaction under different conditions or at a different time. Hard declines are terminal. The card cannot be used.

Retrying a hard decline achieves nothing and creates two real costs. It burns the network's permitted retry allowance, and it feeds the issuer's risk model evidence that your merchant ID generates repeated invalid attempts. Card networks cap the number of authorisation attempts for the same transaction and monitor merchants who exceed them. Check the current thresholds with your provider before you configure retry logic, because they change.

Why cross-border declines are a different problem

This is the part that surprises most Indian merchants. The same card, the same customer, the same amount, gets approved on a US checkout and declined on yours. Four reasons.

The issuer is scoring geography. Every authorisation request carries the acquirer's country. When a US issuer sees a card-not-present transaction acquired in India, it applies a different risk model from the one it applies to a domestic transaction. Nothing about your business changed. The origin of the request did.

The BIN and the acquirer are mismatched. Authorisation rates are strongly correlated with whether the issuing country and the acquiring country are the same. Local acquiring exists precisely to remove this mismatch, so a French customer's card is presented to their issuer as a locally acquired transaction rather than a foreign one.

Your stack is sending less data than the issuer expects. Address verification is not part of the domestic Indian flow, so most Indian checkouts do not collect or forward it. Foreign issuers use it as a trust signal. Absence is not neutral. It is read as a weaker request.

There is no domestic rail to fall back on. When a card fails domestically, you offer UPI or netbanking. When a card fails at 2am for a customer in Germany, there is no fallback unless you have built one.

The seven changes that actually move authorisation

Ranked by the size of the shift we see when merchants make them.

1. Local acquiring in the customer's market. The largest single lever. It changes how the issuer classifies the transaction before it evaluates anything else.
2. Dynamic routing with real failover. Not a static primary and backup, but routing that reads the response in real time and moves the next attempt to a path with better observed performance for that BIN, country and amount. Detailed in our dynamic routing guide.
3. A deliberate 3DS strategy. Authentication is a lever, not a switch. Where exemptions are available for low-risk transactions, using them removes a step where customers abandon.
4. Network tokenisation and account updater. Removes expired-card and reissued-card failures from your recurring base entirely. Highest return available to any subscription business, and the least frequently implemented.
5. Data completeness and descriptors. Collect and forward billing data. Make the statement descriptor recognisable, because an unrecognisable descriptor generates disputes, and dispute history feeds back into future authorisation decisions.
6. Currency presentment. Showing the customer their own currency reduces abandonment and can change how the issuer treats the transaction.
7. Retry discipline. Fewer, better-timed retries beat more retries.

Three of these also lift completion at the checkout itself, covered in our piece on where global checkouts leak conversion.

Where this sits in the Realisation Ratio

We use a framework called the Realisation Ratio to model what an Indian exporter actually keeps out of what a global buyer intended to pay:

``` Realisation Ratio = (Acceptance capacity × Commerce intelligence) / Friction burden ```

Declines sit in the numerator, in acceptance capacity, and they are the most expensive leak in the model because the loss is total. A transaction that fails to authorise does not lose you a percentage. It loses you the entire order, and usually the customer, who does not try again.

Every other leak in cross-border commerce takes a slice. This one takes the whole thing.

What we see from the inside

I have spent twenty-eight years in payments, including years at Visa working on CyberSource, and the thing that has stayed constant is this: issuer trust is earned by the pattern of your traffic, not configured in a dashboard.

Merchants ask us to turn on better authorisation. There is no switch. What there is instead is a set of conditions that make an approval more likely, applied consistently until the issuer's model learns that your traffic behaves well. Local acquiring, complete data, sensible authentication, disciplined retries. Do those for a quarter and the curve moves. Do them for a week and nothing happens.

The other thing I would say to anyone building for global customers from India: your domestic payments experience is actively misleading here. Domestic acceptance in India is excellent, and it is excellent because of rails and behaviours that do not exist outside it. Assume none of it transfers. Build the cross-border path as its own system, because that is what it is.