Retry intelligence
Retry intelligence decides whether a failed payment is worth retrying, and how. The options are retry the same route, fail over to another provider, or stop. Retry rules live in your policy, each retry decision accounts for provider health at that moment, and every reported outcome sharpens the next decision.
Blind retries compound the failure
Fixed retry schedules re-send failed payments without asking why they failed or whether anything changed. They hammer providers that are already degraded, spend money re-attempting payments that will never succeed, and skip recoverable failures that deserved another try on a different route.
Every retry is a fresh decision
- 01The failure is reportedYour stack reports the failed attempt to POST /v1/outcomes, and it becomes part of the payment's decision history.
- 02The retry is decided, not scheduledThe next POST /v1/decision evaluates your retry rules against current provider health and returns retry, failover or block, with reason codes.
- 03You execute, on your stackRetries run through your own providers like any other payment; Payinference only instructs.
- 04Outcomes tune the loopEach reported result feeds provider health and retry decisions, so the loop keeps learning from what recovery actually worked.
The products behind it
Every solution is the same four-part architecture doing its job. These are the parts doing the heavy lifting here.
Frequently asked questions
Common questions about retry intelligence with Payinference.
Two endpoints. Your backend calls POST /v1/decision with safe payment context and receives one instruction. You execute that instruction through your own providers, then report what happened to POST /v1/outcomes so future decisions keep improving. A server-side SDK wraps both calls.
Payinference is provider-neutral by design. Because it never calls a PSP itself, it needs no provider integration to work. Each decision request lists the providers available to you, and you execute the instruction through the stack you already run.
In shadow mode Payinference returns decisions and records what it would have done while your existing logic keeps executing, so you can evaluate decision quality against real traffic with zero risk. In enforce mode your stack executes the returned instruction.