Top-up failure recovery: bring the customer back in the moment of the glitch

Scenario

Customer in the operator’s app tries to top up by card. The card is declined (insufficient funds, expired, 3DS timeout). The customer sees an error, closes the app.

In most operators that is the end of it. Failed payment — an event in billing logs, no one reacts. Two to three hours later the customer:

• tops up at a competitor (if connectivity is critical),
• buys a voucher at a kiosk (the digital channel loses commission),
• forgets (revenue lost).

At a volume of tens of thousands of failed top-ups per day — this is a sizeable invisible leak.

Trigger

Event in the payment processor: payment.failed with reason code, amount, customer_id, channel.

A consumer in the decisioning layer is subscribed. Not every failure deserves action — filter:

• amount above threshold (>10k UZS),
• customer with a previous successful top-up (not first time),
• failure reason recoverable (not fraud, not permanent decline).

Action

Action window: 5-15 minutes after failure.

Option A: instant in-app banner. “Payment did not go through — try another method”. Button → choice of alternative payment (another card, wallet, USSD).

Option B: push (if app is closed). Concise: “Top-up did not work — here are 3 options”.

Option C: SMS (if push is off or not delivered within 5 min). With a short link to the recovery flow.

Channel is chosen by preference + last open + failure mode.

Alternative payment options

Often the failure mode hints at an alternative. Card declined → offer wallet or USSD. 3DS timeout → retry with another card. Insufficient funds → offer a smaller amount with the option to top up further.

What is measured

Recovery rate — what share of failed top-ups ended in a successful payment within 24 hours.

Recovery channel mix — what worked (in-app, push, SMS, USSD).

Time to recovery — from failure to successful payment.

Customer satisfaction — short survey after recovery.

What not to do

Do not send a recovery message after 24 hours — too late, the customer has already decided otherwise.

Do not offer only retry of the same card — high probability of repeated decline.

Do not bombard the customer through 5 channels at once — pick one best channel.

Do not forget consent — recovery is transactional, but the boundary with marketing is fuzzy.

How SamaraliSoft engages

Sprint Recovery Use Case — 4-6 weeks. Analysis of current failed top-ups, trigger logic design, channel orchestration, recovery UX. Pilot for 30-60 days with measurement of recovery rate.

Related

• /en/architecture/telecom-realtime-decisioning-architecture/ — decisioning
• /en/architecture/telecom-notification-fabric/ — notification
• /en/solutions/telecom-cvm-platform/ — CVM
• /en/insights/telecom-payment-friction/ — payment friction