Taking payment in a conversation: links, confirmation and reconciliation

Asking somebody to pay inside a conversation they are already having removes a genuine amount of friction. The customer does not have to find an email, open a portal or remember a reference, and for small amounts that difference is most of whether you get paid today or next week.

Getting it right is mostly about being clear on where the truth lives. The message thread is a place where a payment is requested and discussed. It is not where the payment happens, and building as though it is produces a system that confidently tells customers things that are not true.

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

Three things, and none of them are about the technology.

The context is already there. They know what it is for because they have been discussing it for the last ten minutes.

The action is one tap. Every additional step between intent and payment loses some proportion of people, and a link in a thread is about as short as that path gets.

It is the same channel as the agreement. The quote, the approval and the payment sit in one place, which makes the whole thing feel like one transaction rather than three.

That is the whole advantage, and it is worth having. It also means the payment request should arrive at the moment the customer has decided, not in a batch that evening.

Never card details in a thread

Plainly: a card number typed into a conversation is a problem, and no volume of convenience justifies it.

Three separate objections, and any one of them is sufficient. The number now exists on two handsets and in whatever backs them up. Card scheme and acquirer rules govern how card data may be captured and stored, and a conversation thread satisfies none of them. And your staff can read it, which is a category of access nobody designed for.

The fourth objection is the one that should settle it. Every time a business collects a card number this way it demonstrates to that customer that it is a normal thing to do, which is precisely the belief an impersonator relies on later. Sending a link removes the number from the exchange, costs no additional effort, and demonstrates the opposite.

The same applies to anything that functions like a credential: card security codes, one-time passcodes, banking login details. An automated flow should never ask for any of them, and where a customer volunteers one the correct response is to tell them not to and to have them change it.

The message is not the source of truth

This is the design point that separates a payment integration that works from one that produces angry customers.

A customer saying "paid" is a claim. A confirmation screen they saw is a claim. Even a redirect back into the conversation is not proof, because the payment can fail after it. The only thing that tells you a payment succeeded is your payment provider, through whatever confirmation mechanism it offers.

So the flow has three separate states, and conflating any two of them causes trouble.

Requested. A link has been sent.

Reported. The customer says they have paid.

Confirmed. Your provider says the money is there.

Nothing should be marked paid on a customer's say-so, no job should close on it, and no receipt should be issued from it. Equally, a customer who reports paying and is then chased by an automated reminder has been treated badly, so a report should pause the reminders while a person looks.

The awkward middle case is real: payments that succeed while the confirmation is delayed. Design for the delay rather than assuming immediacy.

What a payment request should contain

Short, and a few specifics prevent most queries.

The amount, with VAT stated. Whether it includes it, and your VAT number if you are registered.

What it is for, in the same words used in the quote.

A reference that matches your own records.

When it is due.

Who is asking. Your business name in the message, because a payment link from an unsaved number is indistinguishable from a scam.

An alternative method. Some people will not pay by link, and losing them over that is unnecessary.

What to leave out: urgency the situation does not have, and any threat about what happens if they do not pay, which belongs in a later and more considered communication.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, 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, the automation builder: 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 customer disputing the 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, since the success path is the easy one and every complaint comes from the others.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Bank transfer and redirection fraud

Sending account details in a message carries a specific risk worth naming.

Payment redirection fraud works by getting a customer to send money to the wrong account, usually by intercepting or imitating the message that carries the details. The customer believes they have paid you, the money is gone, and the relationship is badly damaged regardless of who was at fault.

Two defences work. Establish a channel other than the thread for verifying account details, and tell customers at the outset that any change to your details will always be verified that way. Then, if your details ever genuinely change, follow that route rather than announcing it in the conversation, since an in-thread announcement is indistinguishable from the attack.

Say this to customers explicitly at the start. The businesses whose customers ring to check are the ones that told them to.

Reconciliation, which is where it goes wrong

Payments taken in a conversation are easy to collect and easy to lose track of, which is a bad combination.

Give every request a reference that appears on both sides.

Write confirmations back to one place, so the accounting system rather than the thread is the record.

Handle the payments that arrive by other routes. Somebody will pay by transfer against a link, or pay cash on the day, and the automation has to cope with a payment it did not observe.

Watch for duplicates. A customer who pays twice because the first confirmation was slow is a refund and an apology, and it is more common than expected.

Check the unmatched list weekly. Money received without a matching job, and jobs marked paid without matching money, are both worth ten minutes.

Refunds, chargebacks and disputes

The part that is always left out, and the part that turns up.

A refund should be initiated in the payment provider and reflected back into the conversation, not the other way round. Tell the customer it has been issued and roughly how long it takes to appear, because most refund complaints are about the wait rather than the refund.

A chargeback is different and needs a person. It arrives through your provider with a deadline and a request for evidence, and this is where a messaging channel genuinely helps: the thread holds the quote, the approval and the delivery confirmation, timestamped. Keep those where you can retrieve them rather than only on a handset.

A customer raising a genuine objection is in a different position from one simply not paying, and the automation cannot tell them apart. So any reply at all should halt the reminders until a person has read it. Nothing inflames a complaint faster than a scheduled nudge arriving in the middle of it.

Partial payments, deposits and the awkward cases

Deposits. Normal for anything with materials, and the request should say what it covers and what happens if the job is cancelled.

Part payments. Someone pays half. The system needs a balance concept rather than a paid flag, or it will treat them as unpaid and chase them.

Overpayments. Rarer and worse handled. Flag them rather than absorbing them.

Payments from somebody else. A parent, a landlord, an insurer. The name on the payment will not match the customer, and matching by name will fail.

Currency and fees. International cards cost more and the customer may see a different figure than you quoted.

Each of these is a normal occurrence rather than an exception, and a flow that only handles exact payment in full will generate manual work every week.

Making it survive

Never accept card details in a thread, and make that a rule nobody can override.

Only mark paid on provider confirmation.

Pause reminders on any report of payment, then verify.

Reconcile weekly, 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 what customers expect differs a great deal by country.

Provider fees are real, and small transactions are proportionally expensive.

Confirmation can be delayed, so immediacy is not something to assume.

A link does not make somebody able to pay, and a customer without funds is a conversation rather than a flow.

Faster collection does not fix underpricing, it only reveals it sooner.

What to build first

The three states, separated: requested, reported, confirmed. Before any messaging, make sure your system can tell the difference and that only the third one closes a job. Almost every payment problem in a conversational flow comes from collapsing those into one.

Two habits make the difference. Send a link rather than ever handling card details, because the habit you teach a customer is the one somebody else will exploit. And reconcile in both directions weekly, since 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 scheme and acquirer rules do not permit capture that way, the number persists on handsets and backups, staff can read it, and the practice normalises exactly the behaviour a later impersonator depends on.

What confirms that a payment has been made?

Your payment provider, and nothing else. A customer saying they have paid, a confirmation screen they saw, or a redirect are all claims rather than confirmation.

What should a payment request contain?

The amount with VAT stated, what it is for in the same words as the quote, a reference matching your records, when it is due, your business name, and an alternative payment method.

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

Pause the reminders immediately and have a person check. Chasing somebody who has genuinely paid does more damage than a few days' delay.

How do I reduce the risk of payment redirection fraud?

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

How should refunds be handled?

Initiated in the payment provider and reflected into the conversation, with a note of how long it takes to appear. Most refund complaints are about the wait.

What about chargebacks?

They need a person and they come with a deadline and an evidence request. A thread holding the quote, the approval and the delivery confirmation is genuinely useful here, provided it is retrievable.

How do partial payments work?

The system needs a balance rather than a paid flag, or someone who has paid half will be chased as though they paid nothing.

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

Expect it. Matching payments by name will fail for parents, landlords and insurers, which is why every request needs a reference.

What reconciliation is needed?

Weekly, in both directions: money received with no matching job, and jobs marked paid with no matching money. Ten minutes, and it catches duplicates and mismatches early.

Related reading

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