Failed payments occur when a payment attempt does not complete. Cross-border card transactions can face extra issuer checks, but the right response depends on the failure reason. Chargebacks after a successful payment, and delays in merchant settlement, are related payment issues rather than the same state as a failed checkout.
Key takeaways
- Authorization rate measures approved payment attempts, not unique buyers or orders.
- Routing can optimize an eligible card payment path, but switching to another payment method requires a new, buyer-selected flow.
- 3DS can support card authentication, and merchants can respond to eligible chargebacks with evidence.
- Payment confirmation and merchant payout timing are separate; the latter depends on the provider and agreement.
Why e-Commerce payment authorization rates fall for cross-border merchants
Authorization rate is the share of submitted payment attempts that the issuing bank approves. Cross-border transactions may face extra checks related to geography, currency, authentication, fraud signals, or issuer policy.
In a Brazil example, Antom's Brazil market research found cross-border card authorization below 60% and local Pix payment success above 90%. These figures describe two different payment flows in one market; they are not universal cross-border averages.
A payment attempt is not the same as a unique buyer or order: one order may generate several attempts. Compare like-for-like approval and completion metrics before estimating lost orders or revenue.
For the checkout configuration that puts fast-completing local methods ahead of cross-border cards, see our e-Commerce checkout optimization guide.
How to fix a failed cross-border card payment
Match the fix to the failure reason. Retrying a decline the issuer has already refused wastes attempts, and ignoring a decline that only needs updated card details loses a buyer you could have kept.
How to tell a soft decline from a hard decline
Card declines fall into two groups, and the group decides how you respond.
- Soft decline: the issuer approved the transaction but a business rule or processor rejected it, so another attempt may succeed (Visa Acceptance).
- Hard decline: the issuer refused the payment outright. Retrying the same card will not work; the buyer needs a different payment method.
The table below maps the reasons you will see most often to the action that resolves them.
Failure reason | What it usually means | What to do |
|---|---|---|
Invalid or expired card details | The card number, expiry date, or security code did not match, or the card has expired | Ask the buyer to correct or update the payment details, then attempt the same card again |
Authentication required | The issuer or processor wants stronger verification, such as 3DS authentication | Send the buyer through the applicable authentication flow; do not switch processing paths to avoid it |
Network or processing error | No clear final status was returned for the transaction | Confirm the transaction's final status before retrying, so the buyer is not charged twice |
Temporary condition (insufficient funds or a temporary hold) | The issuer approved, but funds or limits are not currently available, a soft decline | Retry later within the provider's rules, and notify the customer if the condition persists |
Hard decline (lost card, stolen card, revoked authorization) | The issuer refused authorization outright | Stop automatic retries on that card and ask the buyer to choose another available payment method |
The grouping follows each processor's own rules rather than a universal standard, so which codes count as a hard decline can differ by gateway and card network. Read the reason code your gateway returns before you decide the action.
What you can fix automatically: routing and retries
Routing and retries are the two fixes you can apply without the buyer doing anything. Smart card routing selects among eligible card-processing paths using transaction and channel signals, and it does not silently convert a failed card payment into a different buyer-authorized method.
In Antom's regional payment guide, we found that our Card Revenue Booster makes routing and authentication decisions within a 50ms window. In an AliExpress deployment during a 2025 promotion, it lifted the card authorization rate by 2%–3% and recovered about 2% of lost orders through auto-retry. Those results come from one deployment, so treat them as an example rather than a benchmark for your own checkout.
Keep retries bounded and matched to the failure reason. A long retry tail can look like fraud to a card network and increase disputes, and hard declines should not be retried automatically. Confirm the final status of a network or processing error before you retry, so the buyer is not charged twice.
When a retry won't work, let the buyer choose another method
Some failures cannot be fixed by another attempt; they need the buyer to act. When a card cannot be recovered, invite the buyer to choose another available method in the same checkout.
What you ask the buyer to do depends on the method. In Brazil, a Pix payment asks the buyer to scan or copy a Pix code, review it in their banking app, and confirm; in Malaysia, an FPX payment sends the buyer to their online bank to authorize the transfer. Neither is an automatic card retry, because both are new, buyer-authorized payment flows.
Antom's regional payment guide also found that a clear failure message paired with another available option can recover about 6% of otherwise lost orders. Keep the wording neutral, such as “This payment wasn't completed. Try another available method,” unless the provider has supplied a specific decline reason.
Chargebacks vs. failed payments: what's the difference?
It is easy to lump every payment problem together, but a chargeback, a payout delay, and a failed checkout are three different events with different fixes.
A chargeback happens after a payment succeeds, when the buyer or their bank disputes the charge. A payout delay happens after the payment is confirmed, between your acquiring gateway confirming the buyer's payment and paying out to you. Neither is a failed payment.
If a chargeback does land, respond through the applicable process with evidence such as order, delivery, refund-policy, and customer-communication records. The outcome depends on the dispute reason, the evidence, the deadlines, and the card-network or provider rules, so no particular result is guaranteed. See Antom's guide on how to handle a chargeback.
Responding to a dispute is one half of the problem; the other half is reducing how many reach that stage. Two measures do most of that work:
- 3DS 2.0 sends transaction data to the issuer for risk assessment, which may approve a frictionless flow or request a challenge such as an OTP, banking-app approval, or biometric check (see the EMVCo 3-D Secure flow).
- A2A (Account-to-Account) transfers move funds between bank accounts without using the card-network chargeback process, so they do not generate card chargebacks. Refunds, fraud handling, recalls, and disputes follow the rules of each method.
On the response side, our own operations use an AI chargeback assistant that improved dispute win rates by 3 percentage points and cut resolution time by 46%.
Payout timing is set by your payment provider and the agreement you sign, and it can lag the payment itself. A method may confirm the buyer's payment in real time while the merchant is still paid out later, so check the settlement terms for each method instead of assuming real-time payment means real-time payout.