A customer ready to pay may abandon a purchase because a bank connection returns a technical error. Instead of asking for card details again after every failure, first understand why the transaction did not complete. MagicPay Payment Retry evaluates provider responses using a shared error model and retries eligible technical errors through a configured alternative acquiring service. Definitive declines, customer input errors and uncertain transaction outcomes are handled separately. Link failed payment recovery to a single sales record so support, engineering and finance can work from the same attempt history.
From error code to the right action
Evaluate different bank responses through common transaction states. Not every negative outcome needs the same next step. Technical bank or connection errors follow the retry policy, while definitive customer- or card-related declines are kept separate. Alternative routing decisions are based on what happened to the transaction, not just the wording of an error message.
- Technical error: Retry with an eligible alternative provider according to your configured rule.
- Definitive decline: Handle insufficient funds, blocked cards and incorrect details separately.
- Uncertain outcome: Check the existing transaction's status before making another attempt.
Resolve uncertain outcomes first
A timeout does not mean a payment has definitely failed. A new attempt is not initiated before the original request's provider record and transaction status are checked. Status queries, the first response and subsequent actions share a business reference. This approach helps reduce duplicate collection risk and makes it easier for support to understand which step was taken and why.
Manage your retry policy in the dashboard
Define which technical outcomes are eligible for retry and which eligible acquiring connections to use in your MagicPay integration. Update provider priorities centrally instead of coding them separately in every sales channel. Card, installment and transaction eligibility are evaluated again for the next attempt, while any authentication requirements remain part of the payment flow.
See the outcome of your recovery flow
Track how retried transactions end and which technical errors recur on which connections. Keep the initial unsuccessful response distinct from the subsequent outcome while reviewing both under the same payment request. Compare provider and rule decisions without treating multiple attempts as separate sales. Finance works from the completed payment, while engineering investigates the attempt history.
Controlled retries in three steps
Define what happens after a technical error while keeping every attempt connected to the sale.
- 1. Classify provider responses as technical errors, definitive declines or uncertain outcomes.
- 2. Configure and test alternative acquiring priorities and status queries for eligible errors.
- 3. Track the initial attempt, status check and subsequent outcome through the same order and payment reference.
For online sales and recurring collection teams
Use it in e-commerce, subscriptions and multi-provider payment operations to distinguish technical failures from customer decisions. AI Routing selects the initial route, Uninterrupted Payments manages connection health and Payment Retry focuses on the next step for an individual request. Support, risk and finance teams do not have to reconstruct the transaction across disconnected records.