Cinco Salvaguardas en las Solicitudes Automáticas de Pago por WhatsApp

1. It will not ask someone who said stop

cost to us: a database blip means nobody gets asked, and that revenue is simply gone

Consent is checked before anything is sent, which is unremarkable. What matters is the direction it fails in. If the consent lookup itself errors, the request is refused. Not logged and continued. Refused.

The tempting alternative is to treat an unreadable consent record as no objection, because the sale is right there and the error is probably transient. That choice converts every database hiccup into a message somebody did not agree to receive, on a channel where the regulator and the platform both take that seriously, and the person who finds out is the customer.

2. It will not ask twice for the same thing

cost to us: a genuinely stalled request needs a human to clear it

An automation that runs nightly against a segment will happily ask the same person for the same item every night until they pay or block you. So an open request for a given contact and item blocks a second one.

This guard is also where we found the more interesting bug. A checkout the gateway refused used to leave the order stranded in its initial state, which the duplicate check counted as an open request. The result was software that answered "already requested" forever, about a person who had never once been asked. The state machine now has an explicit path for a refused checkout, so a failure is a failure rather than a permanent silence.

3. It will not sell what is not there

cost to us: a shop with untracked stock has to say so explicitly

Stock is decremented when an order is fulfilled, which is correct: a made-to-order piece can be days from dispatch. But it means a plain "is there stock" check passes repeatedly for the same unit. We measured it before fixing it. One item in stock, and the system was willing to ask fifty people to pay for it.

Fifty real payments, into the shop's real account, for one ring. The shop then gets to explain itself to forty-nine people and refund them, having done nothing wrong except trust its software.

The fix counts what is already promised: every open order containing that product has committed its units even though nothing has left the shelf. No reservation state was introduced, deliberately, because a reservation is a thing that can leak a hold when an order is abandoned and then quietly hide inventory nobody can sell.

4. It will not shout through a closed window

cost to us: a template has to be approved by Meta before this works at all

WhatsApp allows freeform messages only inside 24 hours of the customer's last message. Automation, by its nature, usually fires outside that. Inside the window we send the native interactive payment card, Meta's order_details message with a UPI intent, priced in INR because that combination is India-only. Outside it, an approved template.

There is a real constraint underneath that is worth knowing if you are building this yourself. Meta fixes a template's button URL at approval time, apart from a single trailing variable, so a template physically cannot carry an arbitrary gateway checkout link. We send a stable redirect ending in a per-order token, and resolve that token to whatever link the order actually has. The side effect is that the gateway becomes swappable without touching the approved template.

5. It will not call a deposit a sale

cost to us: an order sits open and somebody has to chase it

The links this product creates cannot be part-paid. But a shop can paste in a link it made by hand in its own gateway dashboard, where part payment can be switched on, and that gateway's notifications reach us regardless of who created the link.

Our webhook used to read any successful payment event as full settlement. On a ₹2,500 order, a ₹500 advance would have marked it paid, sent the customer a receipt, run fulfilment, decremented stock and closed the order. The shop packs a ring, having been paid a fifth of it, and finds out weeks later.

It now compares what arrived against what is owed. A shortfall leaves the order exactly where it was, records the real numbers in the ledger, and messages the shop with the opposite instruction from a sale:

Part payment received: ₹500.00 of ₹2,500.00
Still outstanding: ₹2,000.00
Customer: 9198xxxxxxx
This order is NOT paid and has not been fulfilled.
Collect the balance before sending anything.

And the customer receives nothing at all, because a receipt is a promise the shop has not yet been paid to keep.