Taking payment on WhatsApp: what is and is not possible
The honest version of a question the field answers badly — and the three things that do work.
There is no checkout inside the conversation, and no payment gateway connected to it. A customer cannot enter card details in a chat with you and have the money arrive.
That is worth stating plainly, because the phrase "WhatsApp payments" gets used loosely and merchants make plans around it. What does work is a set of things that are less magical and, for most sellers, entirely sufficient.
The three that work
| Approach | How it works | Suits |
|---|---|---|
| Send a link | Your existing checkout or payment link, sent in a message | Anyone who already sells online |
| Cash on delivery | Confirm the order in chat; money changes hands at the door | Markets where this is normal |
| Bank transfer or wallet | Send details, customer pays, sends proof | Smaller sellers, wholesale |
All three are ordinary messages, so all three are free while the conversation is open — service conversations have been free and unlimited since 1 November 2024 under Meta's pricing documentation.
Sending a link, done well
The most common route and the one with the most avoidable friction. Four things:
- Send it at the moment they decide, not later. A link sent while the conversation is live gets tapped; one sent tomorrow needs a template and gets tapped less.
- Say what the amount is in the message. A bare link asks the customer to trust it.
- Use a link that already knows the items, such as your store's own checkout, rather than one where they rebuild the basket.
- Follow up once if it is not paid, and only once.
If your store is Shopify, the abandoned-checkout link is available to a flow as a field, which is exactly what a cart reminder uses — covered in abandoned checkout recovery.
How a flow can tell paid from unpaid
This is the part people do not realise is available. A Shopify order event carries its payment status, and a flow can branch on it — so paid and unpaid orders can be treated completely differently without anybody checking by hand.
Add an If Shopify Event Data condition after the order trigger and test the payment status field. Two branches worth building:
- Paid — a straightforward confirmation, and straight into your fulfilment flow.
- Not paid — a different message entirely, and a chase if it stays that way.
The same condition can test which payment method was used, so a cash-on-delivery order can go down its own path. The full pattern for chasing an unpaid order is in failed and pending payment recovery.
Cash on delivery is a payment method too
In a great many markets it is the dominant one, and WhatsApp is unusually good at the problem it creates: orders that get refused at the door.
A confirmation flow that asks the customer to tap Confirm or Cancel before you dispatch is the single highest-value automation available to a cash-on-delivery seller, and it is not really a payments feature — it is a conversation that prevents a wasted delivery. It is covered in cash-on-delivery order confirmation.
Bank transfer, and the proof problem
Common for wholesale and for smaller sellers. It works, and it has one weakness worth planning around: the customer sends a screenshot as proof, and that screenshot is now the only record.
Two habits fix it. Save the payment reference into a contact field rather than leaving it in an image, and keep your bank details in a quick reply so nobody retypes an account number at speed. Both are covered in quick replies for a team.
If your payment system can tell us
The one route that automates the rest. If the software that receives your money can send a web request when a payment lands, it can start a WhatsApp flow — so a paid receipt, an unlocked download or a booking confirmation can go out the moment the money arrives, with nobody watching.
That is one small task for whoever maintains that system, and the shape is in starting a flow from your own system.
What to be sceptical about
Two claims worth testing when you read them elsewhere:
- "Accept payments in WhatsApp." Ask where the card details are entered. If the answer is a web page, it is a link — which is fine, and it is not what the sentence implies.
- "Integrated with your payment gateway." Ask what a flow can do because of it. If the answer is "send a link", you already have that.
Meta does offer in-chat payments in a small number of markets under its own arrangements. That is a Meta product rather than something this platform connects to, and for almost every seller the practical answer today is a link.
Frequently asked
Can customers pay without leaving the chat?
Not through this platform. They tap a link and pay on your checkout.
Does sending a payment link cost anything?
Not while the conversation is open. If you are reaching a cold chat it is a template, and templates are billed under Meta's template rules.
Can a flow know when the customer has paid?
For Shopify, yes — the payment status arrives with the order event. For other systems, your own software posting an event is the route.
Is it safe to send bank details in a chat?
It is as safe as any message, and the practical risk is a typo rather than interception. Use a saved reply so the digits are never retyped.
Choosing an approach
Three questions settle it, and none of them are technical:
- Do you already sell online? Then send your existing checkout link — you have the hard part built.
- Is cash on delivery normal in your market? Then confirmation matters far more than collection, and that is a conversation rather than a payment.
- Are your orders negotiated? Wholesale, custom work, anything quoted — then bank transfer with a saved reply is usually the least friction for both sides.
Most businesses end up doing two of the three. The mistake is waiting for an in-chat checkout that does not exist rather than sending a link today.
What each approach costs you
| Approach | Friction for the customer | Admin for you | Risk |
|---|---|---|---|
| Checkout link | Low — one tap | None, it reconciles itself | They do not finish |
| Cash on delivery | Lowest | Reconciling cash | Refused at the door |
| Bank transfer | Highest | Matching payments by hand | Wrong reference, missed payment |
Reading across, the link wins on admin and the cash option wins on friction — which is exactly why cash-on-delivery markets stay cash-on-delivery, and why the work worth doing there is confirmation rather than collection.
The follow-up that is worth building
One message, a few hours after a link goes unpaid, sent only to people who did not pay. Not two, not a discount — just a check that they saw it.
The reply check is the part that matters, because a customer who already paid receiving a payment reminder is the fastest way to look disorganised. The shape is in delays and follow-ups in a flow, and inside an open conversation it costs nothing under Meta's pricing documentation.
Confirming payment without a gateway
Whichever route you take, somebody has to know the money arrived. Three ways, in increasing order of how little work they create:
| How you find out | Effort | Notes |
|---|---|---|
| The customer says so | Highest — you verify by hand | Fine at low volume; save the reference to a field |
| Your store marks the order paid | None | A flow can branch on it immediately |
| Your own system posts an event | One-off setup | The receipt goes out the moment the money lands |
Rough guidance on when to move: at fewer than 10 payments a week, checking by hand is genuinely fine. Past 50, the reconciling starts costing more than the setup would have, and past 100 it is somebody's part-time job.
Most businesses start on the first row and move to the second once they are selling through a store rather than through conversations. The third is worth it once the volume makes manual checking tedious.
What good looks like
- Payment details or a checkout link are one keystroke away for every agent.
- A flow treats paid and unpaid orders differently, automatically.
- Exactly one follow-up chases an unpaid link, and never reaches somebody who paid.
- Cash-on-delivery orders are confirmed before dispatch.
- Payment references live in a contact field, not in a screenshot.
None of that requires a payment integration, and all of it is buildable this week — inside conversations that stay free under Meta's pricing documentation.
The short version
No checkout in the chat. Send a link, branch on the payment status your store already reports, and treat cash on delivery as a confirmation problem rather than a payments one. Anything promising in-chat card payments is describing either a link or a Meta product you do not connect to.
Common questions
Can I send an invoice as a PDF?
Yes, and you should name the file properly before you do — the filename is what the customer sees when they go looking for it months later. See sending photos, documents and voice notes.
Is it safe to send a payment link?
It is your own checkout link, so it is as safe as your checkout. What matters is that the customer can tell it is genuinely from you, which is an argument for sending it inside a conversation they started rather than out of the blue.
Can I charge a deposit?
However your checkout supports it. If a flow works out the deposit amount, use the arithmetic step rather than an AI one — a model is not a calculator, and this is a number the customer is charged.
What about refunds?
Handled wherever you took the payment. WhatsApp is where you tell the customer it has happened, which is worth doing promptly.