Taking the payment is easy. Knowing it arrived is the work.

Three ways money moves out of a chat

Most Indian SMEs selling on WhatsApp today land on option one, and it is usually the right call. It works whatever the customer has installed, it runs on a merchant relationship you already hold, the money lands where your accountant already looks, and — decisively — it emits an event your systems can listen for.

One honest limitation of this page: Meta’s own documentation for in-chat payment message types in India was not reachable when we wrote this, so we are not going to describe native flows we could not verify. If native in-chat payment matters to you, ask your provider what is enabled on your specific number today — that answer changes by market and by account.

The regulatory ceiling that used to shape this

If you looked at WhatsApp payments a few years ago and concluded it was not a serious channel, that conclusion was correct at the time and is now out of date.

NPCI capped how many users WhatsApp Pay could onboard onto UPI — 40 million in 2020, raised to 100 million in 2022 — which meant most of the country simply could not use it. That cap was lifted around the start of 2025, opening the service to WhatsApp’s full Indian base. Separately, NPCI’s proposed 30% ceiling on any single app’s share of UPI transactions has been deferred to 31 December 2026.

What that changes for a business is smaller than it sounds, because the payment-link route never depended on WhatsApp Pay in the first place. What it does mean is that the consumer habit of paying inside a chat is no longer artificially constrained, and the direction of travel is clear.

Why the UPI QR everyone starts with stops working

Almost every small business begins by sending a UPI ID or a QR code in the chat. It costs nothing, it takes ten seconds, and at ten orders a day it is completely fine.

It breaks at scale for one reason: a UPI credit tells you an amount arrived, not which order it was for. Two customers paying ₹1,299 on the same afternoon are indistinguishable in your bank feed. So somebody spends their evening with a chat window in one hand and a statement in the other, matching payments to conversations. That person is doing reconciliation by hand, and they will eventually get one wrong — shipping an unpaid order, or worse, chasing a customer who already paid.

Screenshots make it worse rather than better. A customer sending a payment screenshot is asking you to trust an image, and images are trivially faked. Any process whose confirmation step is “customer said they paid” is not a payment integration.

What an integrated flow actually looks like

The difference between sending links and closing orders is that every step below is triggered by a system event rather than by someone noticing.

1. 1. The order is assembled in the conversation. Items, quantities, delivery address, total. Nothing is generated until the customer has actually agreed to what they are buying.
2. 2. Stock is held. Before the link goes out, not after payment. Otherwise you will sell the last unit twice on a busy day and spend the refund conversation explaining it.
3. 3. A link is generated for that specific order — carrying that exact amount and a reference tying it to the order record. This is the step that makes automatic reconciliation possible at all.
4. 4. The gateway webhook confirms. Payment success arrives as an event from the gateway, not as a message from the customer. The order flips to paid on that event and on nothing else.
5. 5. Confirmation and downstream actions fire. The customer gets a confirmation, the order writes into your sheet or ERP, and the held stock converts to sold. All from the same event.
6. 6. Failures escalate rather than sit. Link expired, wrong amount, duplicate payment, payment with no matching order — each goes to a human with the conversation attached. An agent should never decide a refund.

Step four is the one worth insisting on when you evaluate any vendor. Ask directly: how does the system learn that a payment succeeded? If the answer involves the customer telling it, you are buying a link generator.

Timing the link costs you nothing — or something

There is a small economic detail worth knowing. If the customer is mid-conversation with you, the service window is open and your messages — including the payment link — are free. If the conversation went cold and you reach back out to chase an unpaid order, that is a template and it is charged.

So the cheapest payment flow is also the one that converts best: send the link while the customer is still engaged, rather than assembling an order and chasing it tomorrow. Payment reminders sent days later cost money on top of converting worse. The full mechanics of which messages are free are in how WhatsApp Business API billing works.

Remember also that these are separate bills. Your gateway takes its cut of the transaction; Meta charges per delivered template whether or not anyone pays. Model both, plus GST, and count the message cost on the conversations that did not convert too.

Where this sits in the sale

Payment is the last step, and it is rarely where sales are actually lost. How to sell on WhatsApp covers the full journey and the earlier moments where orders quietly disappear. What the customer is buying from comes from your catalogue, and the confirmations and dispatch notices that follow a payment all run through message templates.

If you want the reconciliation handled rather than described, an agent on your number holds the stock, issues the order-specific link, listens for the gateway event and writes the confirmed order into your system — with the failure cases going to a person rather than being guessed at.