Collecting Payments Over WhatsApp in Israel: Building the Whole Flow

WhatsApp is an excellent collection channel in Israel for one reason: the message gets read. But a payment is not a message - it needs a payment link, identification of who actually paid, and automatic document issuing. Without those three you get collection that looks modern and produces manual work at month end.

The full flow, in seven steps

1. A debt is created in your system - an order, a bill, or a monthly charge.
2. A unique payment link is generated for that debt and that customer.
3. A message is sent with the amount, what it is for, and the link.
4. The customer pays on the payment provider's page, not in the conversation.
5. The provider reports a successful payment.
6. Your system closes the debt and issues a document automatically.
7. The customer receives confirmation on the same channel you asked on.

Step 6 is the one dropped in a quick build, and it is also the step that decides whether you have collection or only payment requests. A link that takes a payment without closing the debt leaves that debt open in the report - and then somebody calls a customer who has already paid.

What may be sent, and when?

Meta's Cloud API documentation defines a customer service window: after a customer messages you, there is a period in which you can reply with free-form messages. Outside that period, business-initiated outreach requires a pre-approved template.

What that means for collection:

• A customer who just messaged you - reply freely, including sending a payment link.
• Business-initiated outreach about a debt - needs an approved template. Plan templates in advance, because approval is not instant.
• Second and third reminders - also business-initiated. One template that fits a reminder beats three different ones.
• Payment confirmation - triggered by the customer's action, and worth having a ready template for too.

The approval process itself, including what gets rejected and why, is covered in the WhatsApp template approval guide, and the technical connection is documented in the WhatsApp Cloud API guide for Israel.

What already exists in the systems you run

Before building anything, check what you already have. Several Israeli invoicing and payment systems present capabilities on this channel:

That table is why it is worth starting with an audit rather than with development. A sizeable part of the flow already exists in systems you are paying for.

How do you know who paid?

This is the question that separates collection from requests. Three ways, best to worst:

1. A unique link per debt. The provider returns an identifier with the payment, and your system closes exactly that debt. This is the only approach that works without intervention.
2. A link with a reference the customer cannot touch. Works, but depends on the field being non-editable.
3. A generic payment page matched by amount. Breaks the moment two customers owe the same amount, which happens more than you would think.

If you are on the third, that is the first thing to improve - before adding channels or templates.

What to do when the customer replies instead of paying

This happens a lot: instead of tapping, the customer writes "I will pay tomorrow", "I already paid", or asks what the charge is for. The three cases need different answers:

• "I will pay tomorrow" - acknowledge and set a date. Make sure the system does not fire an automatic reminder that same day, which turns an agreement into friction.
• "I already paid" - check before replying. If the payment did arrive, the debt was open because step 6 of the flow did not work, and that is your fault, not theirs.
• "What is this for?" - send the document, not an explanation. A document answers the question and closes it.

Note that a customer's reply reopens the service window, so that is precisely when you can continue in free-form conversation - including sending an updated link.

What not to do

• Do not ask for a card number, CVV or a photo of a card in a message. Even if the customer offers. Card details do not travel in chat.
• Do not send a generic link to a payment page. With no amount and no identifier, you are guessing who paid.
• Do not mix dunning and personal conversations on the same number without structure - debt and service on one thread create confusion.
• Do not rely on a screenshot of a transfer as payment confirmation. Confirmation comes from the provider, not the customer.
• Do not message the whole list in the same minute. Collection looks like spam when it arrives all at once.

The fourth point is the common one. A screenshot is not a receipt, and it does not match the bank report either. The receipt is recorded when the money arrives.

What to measure after a month

WhatsApp collection looks successful because messages get read. What counts is the money, so measure three things:

• Payment rate out of requests sent, not the read rate. A message read and not paid is not a success.
• Time from request to payment. If most payments arrive on day one, a third reminder is redundant.
• How many debts closed automatically versus manually. That gap is the work the channel creates for you, and it shows up in no other report.

Sources

• Meta - Cloud API, sending messages and the service window
• Morning by Green Invoice - business tools
• PayBox for business - reminder and one-tap payment