Taking payment in a conversation: links, confirmation and reconciliation

To take payment in a WhatsApp conversation, send a payment link from your payment provider, never ask for card details in the thread, and treat only the provider's confirmation as proof that money arrived. The conversation is where a payment is requested and discussed. It is not where the payment happens, and a flow that treats it as the source of truth tells customers things that are not true.

Key takeaways

• Send a payment link and never accept card details, security codes or passcodes in a thread.
• Track three separate states: requested, reported and confirmed. Only the payment provider's confirmation closes a job.
• Include the amount, purpose, reference, due date and your business name in every payment request.
• Give customers a verification channel outside the thread for bank details, to reduce redirection fraud.
• Reconcile weekly in both directions, and pause reminders when a customer replies about payment.

What we'll cover

• Why payment in a chat works at all
• Never card details in a thread
• The message is not the source of truth
• What a payment request should contain
• Building it with CodeWords
• Bank transfer and redirection fraud
• Reconciliation, which is where it goes wrong
• Refunds, chargebacks and disputes
• Partial payments, deposits and the awkward cases
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

Why payment in a chat works at all

Payment in a chat works because it removes steps between the decision and the payment. Three things drive that, and none is about technology.

• The context is already there. The customer knows what the payment is for because they have discussed it for the last ten minutes.
• The action is one tap. Every extra step between intent and payment loses some people, and a link in a thread is about as short as the path gets.
• The agreement and the payment share a channel. The quote, the approval and the payment sit in one place, so the exchange feels like one transaction.

Send the payment request at the moment the customer decides, not in a batch that evening.

Never card details in a thread

Never accept card details in a conversation thread, and do not trade this rule for convenience. Four objections apply, and any one is enough.

• The number then exists on two handsets and in whatever backs them up.
• Card data security rules restrict how card numbers may be captured and stored, and a conversation thread does not meet them. Check the current rules with your payment provider.
• Your staff can read the number, which is access nobody designed.
• Each business that collects a card number this way teaches that customer it is normal, which is the belief an impersonator relies on later. Sending a link costs no extra effort and teaches the opposite.

The same applies to card security codes, one-time passcodes and banking login details. An automated flow must never ask for any of them. If a customer volunteers one, tell them not to share it and to change it.

The message is not the source of truth

Only your payment provider can confirm that a payment succeeded. A customer saying "paid" is a claim. A confirmation screen they saw is a claim. A redirect back into the conversation is not proof either, because a payment can fail after it. The flow therefore needs three separate states.

State	Meaning	What to do
Requested	A link has been sent	Wait
Reported	The customer says they have paid	Pause reminders and have a person check
Confirmed	Your provider says the money is there	Mark paid, close the job, issue the receipt

Do not mark anything paid, close any job or issue any receipt on a customer's say-so. A customer who reports paying and then receives an automated reminder has been treated badly, so a report must pause the reminders. Also design for delay, because a payment can succeed while its confirmation arrives late.

What a payment request should contain

A payment request should state six things, which prevent most queries.

• The amount, with VAT stated: whether it is included, and your VAT number if you are registered.
• What it is for, in the same words as the quote.
• A reference that matches your own records.
• When it is due.
• Who is asking. Put your business name in the message, because a payment link from an unsaved number looks like a scam.
• An alternative method, since some people will not pay by link.

Leave out urgency the situation does not have, and leave out threats about what happens if the customer does not pay. Those belong in a later, considered communication.

Building it with CodeWords

You build payment requests in CodeWords by describing the trigger, the message, and the confirmation handling to Cody, the automation builder. CodeWords connects to 3,000+ integrations (CodeWords pricing page, 2026), and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody: what triggers a payment request, what the message contains, what happens when the provider confirms, and what happens when it does not.
3. Authorize the connections to your payment provider, your invoicing or accounting system, and your WhatsApp Business Platform account.
4. Describe the exceptions: a partial payment, a disputed amount, a refund, a payment that arrives by a different route, a customer who reports paying when nothing has arrived.
5. Test the failure paths deliberately, because the success path is easy and every complaint comes from the others.

You describe the outcome; Cody builds it, connects it, and deploys it. The Free plan costs $0 and covers light use, Pro is $39 per month ($33 billed yearly) and Business is $100 per month (CodeWords pricing page, 2026). Details are on the pricing page.

Bank transfer and redirection fraud

Sending bank details in a message carries a specific risk: payment redirection fraud. The fraudster intercepts or imitates the message that carries the details, so the customer sends money to the wrong account. The customer believes they have paid you, the money is gone, and the relationship suffers whoever was at fault.

Two defences work.

1. Set up a verification channel outside the thread, and tell customers at the outset that any change to your details will be verified through it.
2. Follow that route if your details ever change. An announcement in the thread looks identical to the attack.

Say this to customers explicitly at the start. Customers who were told are the ones who ring to check.

Reconciliation, which is where it goes wrong

Payments taken in a conversation are easy to collect and easy to lose track of. Five practices keep the books straight.

• Give every request a reference that appears on both sides.
• Write confirmations back to one place, so the accounting system is the record and the thread is not.
• Handle payments that arrive by other routes. Customers pay by transfer against a link or pay cash on the day, and the automation must cope with a payment it did not see.
• Watch for duplicates. A customer who pays twice because the first confirmation was slow needs a refund and an apology.
• Check the unmatched list weekly: money with no matching job, and jobs marked paid with no matching money.

Refunds, chargebacks and disputes

Start a refund in the payment provider and reflect it back into the conversation. Tell the customer that it has been issued and roughly how long it takes to appear, because most refund complaints are about the wait.

A chargeback needs a person. It arrives through your provider with a deadline and a request for evidence. Here the messaging channel helps, because the thread holds the quote, the approval and the delivery confirmation with timestamps. Keep those where you can retrieve them, not only on a handset.

The automation cannot tell a genuine objection from simple non-payment. So any reply at all should halt the reminders until a person has read it. A scheduled nudge arriving in the middle of a complaint makes the complaint worse.

Partial payments, deposits and the awkward cases

Each of these cases is normal, and a flow that handles only exact payment in full will generate manual work every week.

• Deposits: the request should say what the deposit covers and what happens if the job is cancelled.
• Part payments: the system needs a balance, not a paid flag, or it will chase someone who has paid half.
• Overpayments: flag them instead of absorbing them.
• Payments from someone else: a parent, landlord or insurer pays, so the name on the payment will not match the customer. Match on the reference, not the name.
• Currency and fees: international cards cost more, and the customer may see a different figure from the one you quoted.

Making it survive

• Never accept card details in a thread, and make that a rule nobody can override.
• Mark paid only on provider confirmation.
• Pause reminders on any report of payment, then verify.
• Reconcile weekly, in both directions.
• Keep quotes, approvals and confirmations retrievable, because a dispute will ask for them.

Limits worth knowing about

• Payment methods vary by market, and customer expectations differ by country.
• Provider fees apply, and small transactions bear proportionally higher fees.
• Confirmation can be delayed, so do not assume immediacy.
• A link does not give a customer funds. A customer who cannot pay needs a conversation, not a flow.
• Faster collection does not fix underpricing. It only shows the problem sooner.

What to build first

Build the three states first, kept separate: requested, reported, confirmed. Before any messaging, confirm that your system can tell them apart and that only the third closes a job. Almost every payment problem in a conversational flow comes from collapsing them into one.

Two habits make the difference. Send a link and never handle card details, because the habit you teach a customer is the one an impersonator exploits. And reconcile in both directions every week, because payments taken in a chat are the easiest to collect and the easiest to lose track of.

Frequently asked questions

Can I take card details over a messaging app?

No. Card data security rules restrict this kind of capture, the number stays on handsets and backups, staff can read it, and the practice teaches customers behaviour that impersonators later exploit. Send a payment link instead.

What confirms that a payment has been made?

Your payment provider confirms it, and nothing else does. A customer saying they have paid, a confirmation screen they saw and a redirect back to the chat are all claims, not confirmation.

What should a payment request contain?

Include the amount with VAT stated, what the payment is for in the quote's wording, a reference matching your records, the due date, your business name and an alternative payment method for people who will not use a link.

What do I do when a customer says they have paid and nothing has arrived?

Pause the reminders straight away and have a person check with the payment provider. Chasing a customer who has genuinely paid does more damage than a few days of delay.

How do I reduce the risk of payment redirection fraud?

Set up a verification channel outside the thread, tell customers at the outset that any change to your bank details will be verified through it, and use that route yourself if your details ever change.

How should refunds be handled?

Start the refund in the payment provider and reflect it in the conversation, with a note of how long it takes to appear. Most refund complaints are about the wait, not the refund itself.

What about chargebacks?

A chargeback needs a person, because it arrives with a deadline and an evidence request. A thread that holds the quote, approval and delivery confirmation is useful evidence, provided you can retrieve it.

How do partial payments work?

The system needs a balance, not a paid flag. Otherwise a customer who has paid half is chased as though they paid nothing, which damages the relationship.

What if somebody else pays on the customer's behalf?

Expect it. Parents, landlords and insurers often pay for the customer, so matching by name fails. Give every request a reference and match payments on the reference.

What reconciliation is needed?

Reconcile weekly in both directions: money received with no matching job, and jobs marked paid with no matching money. The check takes about ten minutes and catches duplicates and mismatches early.

Related reading

• Data protection for a messaging bot
• Multi-stage flows and keeping state
• Putting conversations into a CRM