Getting paid without leaving the chat
The moment you send someone to a payment page is the moment you find out how much they wanted it. Every step between “yes” and paid costs you some of the people who said yes.
A customer has just said yes. They are in a conversation, on their phone, with their attention on you. This is the highest-intent moment you will ever get with them, and the standard next move is to send them somewhere else.
What each step costs
Every hop between “yes” and paid loses some of the people who said yes. The usual chain is longer than it looks:
- Tap the link, leave WhatsApp, wait for a browser.
- Read a page that does not look like the conversation they were just in.
- Find a card, or remember a mobile money PIN.
- Fill fields — name, email, sometimes an address you already have.
- Complete a verification step from their bank.
- Return to WhatsApp, if they remember to.
None of those is unreasonable on its own. Together they are a form, presented to somebody who thought they were having a conversation. Distraction does the rest: a message arrives, the browser tab is forgotten, and the sale is now a follow-up.
The measurable version of this: the gap between people who say yes and people who pay is usually blamed on price. Some of it is price. A meaningful share of it is the six steps above.
What “in the chat” actually means
Nobody is typing card details into a WhatsApp message, and no legitimate product asks them to. Collecting in the thread means the request lives in the conversation and the payment happens in as few steps as the method allows:
| Method | How it feels to the buyer |
|---|---|
| Mobile money push | A prompt on their handset. Enter PIN. Done — no browser at all |
| Card, hosted page | One tap, a page that names the amount, back to the chat |
| Bank transfer | Details in the thread, and a human reconciling — slowest, still common |
The difference from a generic payment link is that the request knows what it is for, who it is from, and which conversation it belongs to — so when it is paid, the thread says so, and nobody has to check a dashboard to find out.
The bookkeeping problem this solves
Ask anybody selling over WhatsApp how they know who has paid, and you will hear about a screenshot. The customer sends a screenshot of a transfer, somebody eyeballs it, and the order proceeds on trust. It works, mostly, and it does not survive volume.
A request tied to a conversation gives you the three things a screenshot cannot:
- A record created before the money moved, so a payment that half-fails has something to reconcile against rather than vanishing.
- A status you did not have to interpret — paid, pending or failed, from the provider.
- An audit trail that says which conversation, which agent, and which order.
Getting it right
Ask for the amount in the same breath as the thing
“Blue kettle, 12,500 — shall I send the request?” beats a bare payment request arriving with no context. People do not pay numbers, they pay for things.
Never dispatch on a screenshot alone
Doctored screenshots are the most common fraud in WhatsApp commerce and they are trivial to produce. If the provider says pending, it is pending.
Expect the half-failure
Mobile money times out. A customer’s connection drops after they enter the PIN and before you hear anything. Your system has to be able to ask the provider again rather than guess, and a request that was created before the call went out is what makes that possible.
Do not chase
One reminder about an unpaid request is service. Three is harassment, and on WhatsApp harassment is a report against a number your whole business depends on. The rule from drip campaigns applies exactly: stop when they reply, and stop anyway after one.
Where this sits in WaveSenda
Payment requests are raised against a conversation, from the console or by an agent, and settle back into the thread. Orders and payouts are visible in the console, and a request that fails ambiguously can be re-checked against the provider rather than assumed.
Common questions
Is it safe to take payments over WhatsApp?
The conversation carries the request, not the card. Payment happens in the provider’s own flow — a mobile money prompt on the handset, or a hosted page — so card details never pass through WhatsApp or through us. What the chat holds is a reference and a status.
What about customers who send a screenshot of a transfer?
Treat it as a claim, not a receipt. Doctored screenshots are the most common fraud in this channel and are trivial to make. Confirm against the provider or your bank before dispatching anything.
Which payment methods work in my country?
It depends entirely on the providers available where you operate — mobile money dominates much of West and Central Africa, cards elsewhere. Check what your own account supports rather than assuming a method is universal.
Can an AI agent take a payment?
It can raise a request, and there are good reasons to be careful about letting it. Anything involving money has an asymmetric cost when it goes wrong, and the time saved is small. Most businesses are better served letting the agent qualify and a person confirm.
What happens if a payment times out?
The request exists before the provider is called, so a timeout leaves a record to reconcile rather than a customer who may or may not have been charged. It can be re-checked against the provider, which is the only reliable way to find out what actually happened.