A refused payment is a result to investigate, not an instruction to send the same request again. First identify the failure stage and current transaction state; then choose the next action.
A useful decline review connects the customer journey, your platform events and the provider’s response. The framework below helps a payment team separate preventable request errors, authentication issues, issuer refusals and uncertain technical outcomes without hiding them inside one global decline rate.
1. Identify where the payment stopped
An HTTP success response is not proof of payment approval. Adyen’s refusal documentation explicitly explains that a processed request can return HTTP 200 while the payment is refused. Read the payment result and relevant status events, not just the transport status.
Map the journey from the customer submitting payment details to your platform confirming the business outcome. For each incident, identify the last confirmed stage. A checkout abandoned before an authorization request is different from an issuer refusal after submission. Keep those cases separate in your reporting.
2. Classify the outcome before choosing an action
| Outcome group | First question | Practical next step |
|---|---|---|
| Request or configuration error | Was the request valid for the intended method and currency? | Fix the request or configuration and verify it with the documented test flow |
| Authentication required | Did the customer complete the required authentication flow? | Follow the provider’s supported authentication flow rather than blindly resending |
| Issuer refusal | What action does the issuer or provider response recommend? | Follow that guidance; stop when retrying is explicitly prohibited |
| Technical or unknown outcome | Is the final state already known elsewhere? | Check the existing transaction and its status events before creating a new payment |
A generic do_not_honor response does not identify a single root cause. Stripe’s code reference distinguishes it from a specific authentication_required outcome. Keep that distinction in support notes instead of guessing that every refusal is a risk-rule problem.
3. Collect evidence that can answer a specific question
Give support one coherent incident record. A screenshot of a generic error message rarely explains which stage failed.
- Internal order or payment reference, provider reference, timestamp with timezone, amount and currency.
- Payment method, relevant market or issuer-country segment, route and environment, without unnecessary personal data.
- Exact result and refusal codes, authentication outcome, related status events and number of attempts.
- The expected result, actual result and any relevant release or configuration change.
Use masked references and access-controlled logs. Do not store CVV after authorization; PCI SSC classifies it as sensitive authentication data. Keep detailed refusal reasons in authorized operational tools, not in the customer-facing message.
4. Separate a transport retry from a new payment attempt
A timeout does not establish that the payment failed. Look up the existing operation first. Where the provider supports idempotent requests, retry the same operation using its documented key and parameter rules; Stripe’s API documentation describes how this avoids duplicate operations.
- Document which outcomes require customer action and which can be reconsidered under provider guidance.
- Follow explicit no-retry instructions instead of treating every decline as temporary.
- Keep an attempt history linked to the original order so repeated requests cannot look like unrelated sales.
- Check the provider’s current retry rules and limits before implementing an automatic schedule.
Idempotency protects an operation from accidental duplication. It does not turn an issuer refusal into an approval, and it is not a reason to bypass an authentication requirement.
5. Measure the customer outcome, not only the number of requests
Start with clearly defined denominators. The following are reporting definitions you can adopt and document; they are not claims about a particular provider’s performance.
| Measure | Example definition | What it helps explain |
|---|---|---|
| First-attempt authorization rate | Approved first submitted authorizations / all first submitted authorizations | How often the initial submitted attempt is approved |
| Eventual authorization success | Orders with an approved authorization / orders with at least one submitted authorization in the defined observation window | Whether later attempts help the same customer order |
| Authentication completion | Completed required authentication flows / started required authentication flows | Where customers leave a required authentication step |
Compare like-for-like segments: method, market, issuer-country group, currency and reporting period. Keep checkout abandonment separate from submitted authorization outcomes. Count a successfully authorized order once, even if it needed several requests, and define how late events enter the report.
6. Give the customer a next step and the team a decision log
Use a clear customer message that matches the supported next action, such as completing authentication or trying another available payment method. Do not expose internal fraud-rule decisions. Give authorized support staff the evidence needed to investigate the specific event.
Record the classification, owner, chosen action and result. Change one relevant variable at a time when investigating a pattern, then compare the same segments over a defined period. The goal is a reliable explanation and an appropriate recovery path, not more retries for their own sake.
Sources and further reading
- Adyen — Refusal reasons: https://docs.adyen.com/development-resources/refusal-reasons/
- Stripe — Decline codes: https://docs.stripe.com/declines/codes
- Stripe — Idempotent requests: https://docs.stripe.com/api/idempotent_requests
- PCI Security Standards Council — FAQ 1318: https://www.pcisecuritystandards.org/faqs/1318/
Public references checked on 13 October 2026. Code names and permitted recovery actions vary by provider and payment method; apply the documentation for the route you actually use.