Recover Overview
SolydFlow Recover is the automated resilience engine designed to eliminate revenue leakage caused by network drops, dropped sockets, delayed USSD prompts, and missing gateway webhooks.
In emerging markets, up to 18% of successful payments fail to unlock customer access immediately because the mobile app closes or cellular data drops before the confirmation callback returns. Recover detects these stranded transactions, establishes truth, and enforces customer access automatically.
The Settlement Gap Problem
Standard payment architectures assume a linear, uninterrupted connection:
[Ideal Flow]:
Checkout ➔ Payment ➔ Webhook ➔ Entitlement Unlocked ✅
[Emerging Market Reality]:
Checkout ➔ Bank Debits User ➔ Cellular Timeout ➔ Missing Webhook ➔ User Locked Out ❌
Without an automated recovery layer:
- The customer gets debited by their bank.
- Your app keeps features locked because no callback was received.
- The customer files a chargeback or angry support ticket, assuming they were scammed.
- You lose customer trust and incur support overhead.
SolydFlow Recover eliminates this gap.
The 5 Pillars of Recover
| Pillar | Problem Solved | Mechanism |
|---|---|---|
| Transaction Recovery | Pending transactions that stall mid-checkout. | Background re-querying across connected provider APIs. |
| Orphaned Transactions | Payments completed at the bank while the app was killed. | The Sweeper Engine matches orphaned intents against bank logs. |
| Failed Webhooks | Dropped, timed-out, or blocked inbound gateway webhooks. | Direct REST verification with fallback polling. |
| Retries & Jitter | Transient provider network timeouts (504 Gateway Timeout). | Exponential backoff with randomized jitter. |
| Recovery Workflows | Cross-device re-engagement for abandoned carts. | SMS, email, and WhatsApp recovery triggers. |
How Recover Differs from Recharging
Recovery never submits a new charge attempt to a customer's card or triggers a second mobile money PIN prompt.
Instead, Recover verifies the existing transaction reference:
- If the user was already debited, Recover verifies the settlement and unlocks access immediately.
- If the user cancelled or was declined, Recover transitions the transaction state to
FAILED_DECLINEDso the user can cleanly retry.
Real-World Example: The M-Pesa STK Delay
- A customer initiates an M-Pesa payment for a KSh 500 subscription.
- Safaricom sends the SIM toolkit PIN prompt to their handset.
- The customer receives a phone call, minimizes your app, and enters their PIN 45 seconds later.
- The operating system kills your mobile app in the background to free memory.
- Safaricom settles the funds, but the app is closed.
- SolydFlow Recover intercepts: The Sweeper detects the open intent, queries Safaricom Daraja, records
SETTLED_CONSENSUSin your cloud ledger, and cachespro_accessso the user has full access the next time they open the app.
Explore Recover Documentation
🔄 Transaction Recovery
How SolydFlow resolves stalled payments and reconciles pending intents.
Read Guide →🔁 Retries & Backoff
Exponential backoff strategies for provider API rate limits and timeouts.
Read Guide →