Payment Failure Recovery

Build this journey when your payment logs show that many failed attempts never turn into a second attempt on the same obligation, and support keeps hearing why could I not pay. Before launch, make sure the payment system classifies the reason into insufficient balance, card details, verification, bank decline, temporary error and unknown, that an active app session can be read live, that in-app, email, WhatsApp and push permissions are stored, and that the validity of the transaction, reservation or subscription can be queried. If failures cluster on one provider or one card type, fix that integration first; reminders do not close a system fault.

Incremental payment recovery rate vs control

What counts is how many more messaged attempts end in a payment that settles the obligation than attempts in the control group; a clicked payment link or an opened card-update page is not a recovery on its own.

How it is counted: The denominator is every failed attempt assigned at entry to either group; the numerator is the attempts whose payment completes within the same follow-up window from assignment, and the gap between the two groups is the journey's effect. Payments that arrive through scheduled automatic retries count in both groups, and delivery or clicks do not change the denominator.

Also track

• Payment method update rateAmong assigned attempts, the share where the user updates the card or switches to another payment method; the intermediate step before completion and the real target of the card-details and bank-decline branches.
• Recovery by reason and by touchRead recovery separately for the six failure reasons and the three touches; the temporary-error branch recovers without a message and must not be blended with the others, and if the last email adds no payments, consider dropping that touch.
• WhatsApp complaints, push opt-outs and unsubscribesWatch WhatsApp complaints, push opt-outs and email unsubscribes per channel; if the payment reminder reads like a debt notice, the payments you won may have cost too much.
• Share of messages sent to invalid transactionsWatch how many attempts have a transaction that is no longer valid at the final check; if that share is high, reminders are going out for orders or reservations that have already lapsed and the waits should be shortened.

• Trigger and entryA payment attempt that fails after a finished checkout, with a reason reported by the payment system, enters the journey. Assign attempts at random to the journey group or to a control group that receives none of this flow's messages; scheduled automatic retries continue the same way in both groups.
• Who must not enterOne failed attempt and the obligation it was settling is one instance; no second flow opens for the same obligation. An unfinished checkout belongs to Checkout Recovery, a reservation on a payment condition to Reservation Payment Reminder, money going back out to Refund Recovery; this journey never returns to the cart.
• Timing and channelsFirst touch by reason: insufficient balance and verification, in-app in an active session, otherwise email; card details and bank decline, email; unknown reason, WhatsApp where permitted, otherwise email; temporary error, a short wait and an automatic retry, no message. If still unpaid: a push after about 1 day, a last email after 1 to 2 more days, then about 1 more day.
• Exit and handoffA completed payment at any check ends the journey at once and cancels queued messages. If the final check still finds no payment: a valid transaction is left to the scheduled automatic retries with no more messages, an invalid one gets an email with the next step and the journey ends. No handoff follows.
• Frequency and consentAt most four messages per attempt: the reason-based first touch, the push, the last email and, if needed, the invalid-transaction email; the temporary-error branch has no first touch. WhatsApp, push and email are each used only with their own consent, and no message ever shows an internal risk or decline code to the user.

1. 1A recovery rate in the journey group that does not exceed the control group means those payments would have arrived without messages; the payments the control group recovers through scheduled retries show that. Read the payment gap between the two groups together with the change in WhatsApp complaints and unsubscribes; the number of clicked payment links is not enough on its own.
2. 2These findings hold for this reason classification, this channel selection and the wait sequence of about 1 day, 1 to 2 days and 1 day. Do not confuse a payment handed over by Reservation Payment Reminder with the reservation being kept, or a Refund Recovery refund with a recovery here; write every payment record to exactly one journey.
3. 3When the gap is small or spread thin across reasons, enter each group's attempts and completed payments into the A/B test significance calculator; if the difference is not significant, try measuring only the busiest reason branch first and extend the follow-up window to cover the check after the last email.
4. 4Review the message copy regularly: a decline or risk code returned by the payment system must never appear to the user on any channel; the reason is explained only in terms of an action the user can take.