Platform capability
Smart retry
If a payment fails for a reason the customer didn't cause, Peneu can try it again on another eligible provider. It only retries when that's safe, and never in a way that could charge someone twice.
- Retries only failures that are recoverable
- Checks status before retrying a timeout
- Keeps one idempotency key across every attempt
Provider A times out. Peneu checks the payment status with Provider A, finds the payment was never created, and retries on Provider B with the same idempotency key. The customer approves once and the payment is authorized via Provider B.
The problem
Some failed payments were never the customer's fault
A share of failures have nothing to do with the customer. The provider timed out, lost its connection to the bank, or returned a system error. The customer had the money and entered the right PIN or OTP, and still saw “Payment failed”. Many won't try a second time.
The hard part is telling these apart from genuine declines, and making sure no one is charged twice while you find out.
Failures worth recovering
- Provider timeouts and 5xx errors
- Issuer or switch unavailable (for cards, response codes such as 91 or 96)
- Connection failures between the provider and the network
- Not these: insufficient funds, a wrong PIN or a customer who cancelled
Retry policy
What gets retried, and what doesn't
Retrying the wrong failure costs you more than it recovers, and repeated retries on risk declines can get a merchant flagged. This is the default split. You can tighten it.
| Failure | Example | Retry on another provider? | Why |
|---|---|---|---|
| Provider rejected the request | 5xx, connection refused | Yes | The payment never reached the bank |
| Provider timed out | No response within the limit | Only after a status check | A timeout can hide a success |
| Issuer or switch unavailable | Card response 91 or 96 | Yes, with fresh authentication where required | The bank side was down, not the card |
| Customer declined or abandoned | UPI request declined, OTP not entered | No | The customer chose not to pay |
| Insufficient funds or wrong PIN | Card response 51, wrong UPI PIN | No | Another provider won't change the answer |
| Risk or fraud decline | Issuer risk block | No | Retrying risk declines draws scrutiny |
Response codes differ by provider and network. Peneu maps each provider's codes to these categories, and the policy on top of them is yours to set.
How it works
Inside a retry
- 01
Classify the failure
The provider's response is mapped to a category: provider error, timeout, issuer unavailable, customer decline or risk decline. Only the first three can qualify for a retry.
- 02
Make sure the first attempt is really dead
For a timeout, Peneu asks the first provider for the payment's status. If the payment succeeded, the customer goes to your success page. If it's still pending, Peneu waits instead of retrying. Only a confirmed failure, or a payment the provider has no record of, moves on to a retry.
- 03
Pick the next provider
Routing runs again without the provider that failed. The retry keeps the same idempotency key and your reference, so your system sees one payment with two attempts, not two payments.
- 04
Stop when your limits are reached
You set the maximum number of attempts and a time budget. When either runs out, the payment fails with the last reason, and the customer can pick a different method.
Retry and failover are different
Retry works on one payment: this attempt failed, so try the next provider. Failover works on traffic: this provider is unhealthy, so stop sending it new payments. They're designed to work together.
Worth knowing
What the customer sees
That depends on where the first attempt failed. If it failed before the customer authenticated, for example because the provider was down while the payment was being created, the retry is invisible and the customer sees one checkout.
If it failed after they'd approved in their UPI app or entered a card OTP, the retry needs their approval again. The next provider can be offered straight away instead of an error page, which still beats starting over.
- Domestic card payments in India need an additional factor of authentication, so a card retry after the OTP step usually means a new OTP
- A retried UPI payment needs the customer to approve again in their app
Configuration
The policy, and the attempt trail
- One payment and one reference, with every attempt listed
- Illustrative field names
"retry": {
"enabled": true,
"max_attempts": 2,
"time_budget_ms": 20000,
"on": ["provider_error", "provider_timeout", "issuer_unavailable"],
"methods": ["upi", "card", "netbanking"],
"skip_if": { "amount_gte": 50000000 }
}{
"id": "pay_7Hq2",
"status": "authorized",
"reference_id": "order-10234",
"attempts": [
{ "provider": "provider_a", "result": "timeout",
"status_check": "not_found" },
{ "provider": "provider_b", "result": "authorized" }
]
}Where it matters most
Where recovered payments add up
SaaS and subscriptions
A failed first payment often ends a trial conversion. Recovering provider-side failures at signup protects the payment that starts the relationship.
Startups & SaaSGaming and digital content
Top-ups are small and impulsive. If the first attempt fails because of the provider, most customers won't try again, so every recovered attempt counts.
Gaming & digital entertainmentTravel bookings
Fares and seats are held for minutes. A retry on a second provider during a provider-side failure can save a booking that would otherwise expire.
Travel & hospitality
Evaluating it
Questions to ask about this, of any provider
Use these with any platform, including Peneu. For Peneu, what's available for your business is confirmed during onboarding.
- Which failure reasons are retried, and which never are?
- Retrying a payment that may have succeeded risks a double charge.
- How is a retry kept from charging the customer twice?
- Look for idempotency and a status check before any retry on an unknown outcome.
- Does the customer have to do anything again?
- Retries that need the customer to re-authenticate behave differently from silent ones.
- How are retries reported?
- You'll want to see recovered payments separately, to judge whether retry is worth it.
FAQ
Questions about smart retry
Can smart retry charge a customer twice?
It's designed not to. A timed-out attempt is status-checked before any retry, pending attempts aren't retried, and all attempts share one idempotency key. If a first attempt still turns out to have succeeded later, which can happen with delayed UPI confirmations, it shows up in reconciliation as a second payment against the same order so it can be refunded.
Which payment methods can be retried?
Any method that more than one of your connected providers supports. You choose which methods retry. Some teams retry cards and netbanking but not UPI collect, where the customer has to approve again.
Do failed attempts cost money?
Providers usually charge on successful payments, but some charge for failed attempts or API calls. Check your provider agreements. Every attempt is recorded per provider, so you can reconcile those charges.
Can I turn retry off for specific payments?
Yes: per method, per amount band, or on an individual request.
Works together with
Find out how many of your failures are recoverable
Share a sample of failure reasons from your current provider. We'll show you which ones a retry policy would cover.
Last reviewed . Samples on this page are illustrative.