Failed and pending payment recovery on WhatsApp
These customers chose, entered their details and pressed pay. The hardest part is already done.
A customer whose payment did not go through is further down the funnel than anyone in your abandoned-cart list. They chose the product, entered their details and pressed pay. Something technical stopped them, and frequently they do not know it failed.
That makes this one of the highest-value flows a store can build, and one of the least built — largely because the event that would start it is not as simple as it looks.
What actually happens when a payment does not complete
Three different situations get called "failed payment", and they behave differently in your store:
| Situation | What your store shows | Recoverable? |
|---|---|---|
| Card declined at checkout | Usually no order at all — an abandoned checkout | Yes, via cart recovery |
| Order created, payment pending | An order with an unpaid payment status | Yes — this is the good case |
| Payment gateway timed out | Varies: sometimes an order, sometimes not | Sometimes |
The middle row is the one worth building for. An order exists, so you have the customer's details, the items and the total — everything a message needs.
The buildable Shopify pattern
Rather than waiting for a "payment failed" event that Shopify's connection does not send, start from the order and check its payment status. The store-event condition can read the payment status field directly, which makes this a three-block question rather than a guess.
Catching the unpaid order
The delay matters here more than in most flows. Some payment methods confirm minutes later, and messaging someone about a payment that has since succeeded is worse than not messaging at all.
If your platform does emit a payment event
The trigger for it exists — payment failed is one of the store events you can start a flow from. Two ways it gets used in practice:
- A platform that sends one. If your store or gateway emits a failed-payment event, the flow starts directly from it, and everything after the trigger is the same.
- Your own system posting it. If the knowledge lives in software you control — a payment gateway integration, an ERP — you can post the event yourself and start the flow from that. The route is in starting a flow from your own system.
Both are cleaner than inferring it, because they fire at the moment the failure is known rather than after a delay you chose.
What the message should say
The tone here is different from a cart reminder, and getting it wrong is what makes these messages feel accusatory. The customer did not do anything wrong. Their bank, or a network, or your gateway did.
- Lead with the fact, plainly: the order was placed but the payment has not gone through.
- Give them the link to complete it. One tap, no hunting.
- Offer an alternative, if you have one — a different payment method, or cash on delivery where you support it.
- Offer a person. Payment problems produce anxious customers, and a route to a human resolves them faster than any flow.
What not to do is imply they abandoned or hesitated. They did not, and telling someone they nearly bought something they thought they had bought is a bad first line.
Which template category this is
This one is usually a utility message rather than marketing: it concerns a specific transaction the customer initiated, per Meta's template documentation. That is a meaningful difference, because utility templates do not depend on marketing opt-in.
Do not stretch it. A message about an unpaid order is utility; the same message with a discount attached to encourage them to complete is marketing, and it should be categorised that way.
Timing, and the pattern that works
- Wait long enough for slow methods to settle. Bank transfers and some wallets confirm well after checkout.
- Check the payment status again if your flow can, rather than assuming the state from an hour ago still holds.
- Send once. A payment problem is not a taste question; if they did not act, a second identical message will not change it.
- Escalate to a person if the order value justifies it, rather than sending a third message.
Step three deserves emphasis. Chasing a payment repeatedly reads as debt collection, and it is a fast way to be blocked by someone who was, an hour ago, a customer.
Cash on delivery changes the picture
In markets where cash on delivery dominates, the failed-payment case is less common and the confirmation case matters far more — the risk is not an unpaid card but an order that gets refused at the door. That is a different flow, covered in cash-on-delivery order confirmation.
The two coexist for stores that offer both. An unpaid prepaid order can sometimes be converted rather than recovered — offering cash on delivery to someone whose card failed is often the fastest resolution, and it is covered in converting between the two.
What it costs
One template per recovered order, billed under Meta's pricing documentation because it lands on a chat with no open window — the customer checked out on your website rather than messaging you, so no 24-hour window exists under Meta's sending messages documentation.
Against the value of the order, that is not a difficult trade. It is one of the few flows where the arithmetic barely needs doing.
Frequently asked
Will it message people whose payment later succeeded?
Only if your delay is too short or the flow does not re-check. Both are fixable, and both are worth fixing before you publish.
Is this the same as cart recovery?
No. Cart recovery catches people who never got an order created. This catches people who did. Different event, different message, different template category.
Should I offer a discount to complete?
No. Nothing about their payment failing suggests price was the obstacle, and it converts a utility message into a marketing one.
How do I know which of my orders are unpaid?
Your store's payment status field, which is what the store-event condition reads. Start there rather than building anything.
How many of these you actually have
Before building anything, count. Filter your orders by payment status for the last 30 days and see how many never reached paid.
Three outcomes, three decisions:
| What you find | What to do |
|---|---|
| Almost none | Skip this flow — your cart recovery matters more |
| A steady handful each week | Build it. The value per message is high |
| A large share of all orders | Fix the checkout first — the flow is treating a symptom |
The third row is not hypothetical. A gateway that fails routinely, or a payment method your customers want and you do not offer, will produce far more unpaid orders than any message can recover.
Two variables that must resolve
The message depends on values coming out of the order event, and the two that matter are the order reference and the link the customer taps. If either arrives empty the message is worse than useless, so guard them.
The block that stops a run when a value is missing exists for this, and it is the difference between a customer receiving a broken message and receiving none. The general habit is covered in tagging and segmenting customers automatically.
A week-one checklist
- Confirm your utility template is approved.
- Place a test order and leave it unpaid.
- Watch the condition catch it in the activity view.
- Confirm the message arrives with a working link.
- Pay the test order and confirm no second message follows.
Step five is the one that proves the flow will not chase people who have already paid, which is the only way this message can genuinely damage a relationship.
Payment methods that behave differently
The right delay depends almost entirely on how your customers pay, and the range is wide:
| Method | Settles in | Implication |
|---|---|---|
| Card | Seconds — it either worked or it did not | A short delay is safe |
| Bank transfer | Hours, sometimes the next working day | A short delay will chase people who are paying |
| Wallet or instant transfer | Usually seconds, occasionally minutes | Short delay, but re-check before sending |
| Buy now, pay later | Depends on the provider's approval step | Treat as pending, not failed |
If you offer more than one, set the delay for the slowest rather than the fastest. A message that arrives 2 hours late costs you nothing; one that arrives while the customer's transfer is in flight costs you their confidence.
What to do with the ones that never pay
After one message and a reasonable wait, an unpaid order is inventory you are holding for nobody. Two decisions worth making in advance rather than case by case:
- How long you hold stock for an unpaid order.
- Whether the order gets cancelled automatically or reviewed by a person first.
Neither is a messaging decision, but both belong in the same conversation, because the flow is the thing that will surface how many of these you have.
The shape in one paragraph
1 trigger on the order, 1 condition on the payment status, 1 delay sized to your slowest payment method, and 1 utility template carrying the order reference and a link. No discount, no second chase, and a route to a person for anything unusual.