# Payment Failure Recovery Page: https://alidemirbas.com.tr/en/lab/journeys/payment-failure-recovery Payment failed → classify reason → recover → paid or exit ## Purpose Recover a failed payment with the right action and channel for the failure reason, instead of sending the same generic message every time. Goal: Recovery & Retry · Category: Transactions, Delivery & Support ## Steps - **Trigger**: Payment failed - **Decision**: Why did the payment fail? - Insufficient balance: Is the user in an active app session? - Expired card / card details: Email: Explain the payment-method problem and link to update it or pay another way - 3D Secure / verification: Is the user in an active app session? - Bank decline: Email: Explain the payment-method problem and link to update it or pay another way - Temporary technical error: Wait briefly and retry automatically - Unknown / needs help: Is WhatsApp permitted? - **Decision**: Is the user in an active app session? - Yes: In-app: Explain the reason and offer a retry or another card - No: Email: Explain the payment-method problem and link to update it or pay another way - **Action**: In-app: Explain the reason and offer a retry or another card - **Action**: Email: Explain the payment-method problem and link to update it or pay another way - **Wait**: Wait briefly and retry automatically - **Decision**: Is WhatsApp permitted? - Yes: WhatsApp: Offer quick help and an alternative payment method - No: Email: Explain the payment-method problem and link to update it or pay another way - **Action**: WhatsApp: Offer quick help and an alternative payment method - **Wait**: Wait about 1 day - **Decision**: Payment completed? - Yes: Payment completed - No: Push: The payment is still pending - **Action**: Push: The payment is still pending - **Wait**: Wait 1–2 days - **Decision**: Payment completed? - Yes: Payment completed - No: Email: Last reminder with alternative payment options and support - **Action**: Email: Last reminder with alternative payment options and support - **Wait**: Wait about 1 day - **Decision**: Payment completed? - Yes: Payment completed - No: Is the transaction, reservation or subscription still valid? - **Decision**: Is the transaction, reservation or subscription still valid? - Yes: Leave it to the scheduled automatic retries; no more messages - No: Email: The original transaction is no longer valid; show the next available step - **Action**: Email: The original transaction is no longer valid; show the next available step - **Exit**: Payment completed - **Exit**: Leave it to the scheduled automatic retries; no more messages - **Exit**: Journey ends ## Guardrails - Stop immediately when payment succeeds. - Do not expose internal risk or decline codes to the customer. ## Core rule Never guess why a payment failed; act on the reason the payment system actually reports. ## When to set it up 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. ## How to set it up - **Trigger and entry**: A 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 enter**: One 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 channels**: First 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 handoff**: A 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 consent**: At 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. ## How to measure success **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. 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 rate**: Among 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 touch**: Read 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 unsubscribes**: Watch 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 transactions**: Watch 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. ## What to watch when reading the result - A 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. - These 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. - When the gap is small or spread thin across reasons, enter each group's attempts and completed payments into the [A/B test significance calculator](https://alidemirbas.com.tr/en/calculators/ab-test); 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. - Review 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. ## Frequently Asked Questions ### Should payment-failure messages depend on the reason? Yes. Incorrect details, insufficient funds, authentication and temporary errors require different actions. Read the reason from the payment system rather than inventing a bank or card problem. Offer contextual help in-session or an eligible secure route back. ### Should every failed payment be retried automatically? No. This example separates temporary technical failures from issues needing corrected details or user action. Follow the provider's error and retry rules. Do not treat an uncertain result as definite failure and initiate another charge. ### When should payment-recovery reminders end? Stop when payment is verified. Do not continue an old payment link after the order, reservation or subscription becomes invalid. This example checks validity at the end and does not extend messages indefinitely while scheduled retries continue.