Platform / Lost Transaction Recovery

The revenue you already earned and quietly never collected.

A meaningful share of declines are not fraud and not insufficient funds — they are timeouts, stale credentials, issuer noise, and retries nobody ever made. SoniqPay treats a failed transaction as the start of a recovery workflow rather than the end of a sale.

Request access See the API

Retry logic: Issuer-aware scheduling
Credential refresh: Account updater + network tokens
Scope: One-time and recurring
Attribution: Recovered volume reported separately

How it works

Lost Transaction Recovery, end to end.

Four stages, each observable in the dashboard and addressable over the API.

Step 1

Classify

Every decline is normalized across processors into a reason we can actually act on.

Step 2

Refresh

Stale credentials are updated through account updater and network token lifecycle events.

Step 3

Re-attempt

Retries are scheduled by issuer behavior and scheme rules, not a fixed timer that burns attempts.

Step 4

Recover

Successful recoveries are attributed and reported so you can see exactly what the layer returned.

Why it is missed

Nobody owns the transaction after it fails.

The processor reports a decline and moves on. The merchant's checkout shows an error and moves on. The customer closes the tab. The orchestration layer is the only place with a complete view of the attempt, the instrument, the customer, and every alternative route — which makes it the only place recovery can actually happen.

Complete attempt historyEvery attempt on an instrument, across every processor, in one timeline.

Alternative routes availableRecovery can use a path the original attempt never tried.

Live session recoveryCascade inside the same checkout session before the customer ever sees a failure.

Failure type	Recovery approach
Soft decline	Immediate in-session cascade to an alternative route
Timeout or provider error	Automatic re-attempt on a healthy MID within the same session
Expired or reissued card	Credential refresh via account updater, then retry
Insufficient funds	Issuer-aware scheduled retry within scheme attempt limits
Recurring failure	Dunning sequence with configurable retries and customer messaging

Capabilities

What you get.

Everything below ships as part of lost transaction recovery — no separate module, no separate contract.

Normalized decline codes

Processor-specific codes mapped to one taxonomy, so a rule written once works everywhere.

Issuer-aware retry windows

Retry timing modeled on how each issuer actually behaves, within scheme attempt limits.

Automatic credential updates

Reissued and expired cards refreshed before the next attempt is even made.

Cross-processor retries

A retry can go to a different provider than the original attempt when the rules call for it.

Recurring billing recovery

Dunning sequences for subscriptions with configurable messaging and grace periods.

Honest attribution

Recovered volume is reported as its own line, not folded into headline approval rates.

Rest of the stack

Works better with the pieces around it.

Each component is independently useful, but the value compounds when they share a decision path.

Bring your own MID. We will bring everything else.

Early access is opening to platforms running real volume. Tell us your stack and we will tell you plainly where the technology moves your numbers.

Request access Read the API docs