How to Automate M-Pesa Payment Confirmations Using WhatsApp

The problem

Customers pay via M-Pesa and immediately ask: "Did it go through?" Manual WhatsApp replies do not scale when you have dozens of payments per hour.

For a full Laravel walkthrough (Daraja callback, queued job, and one send per receipt), see M-Pesa payment confirmations on WhatsApp with Laravel.

The pattern

1. Receive the payment webhook from Safaricom Daraja or your payment aggregator.
2. Verify amount, account reference, and idempotency key in your backend.
3. Call FlareSend's payment confirmation flow via /send-message.
4. Include amount, reference, and the next step (receipt link, order status, or support contact).

Sample message

Payment received: KES 2,500.
Ref: QH12XYZ.
Thank you — your order is confirmed.

API shape

curl -X POST https://api.flaresend.com/send-message \
  -H "Authorization: Bearer YOUR_INSTANCE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "recipients": ["2547xxxxxxx"],
    "type": "text",
    "text": "Payment received: KES 2,500. Ref QH12XYZ. Thank you."
  }'

Implementation notes

• Idempotency: store payment_id to whatsapp_sent_at so retries do not double-message.
• Failures: send a different message when payment fails or is pending.
• Media: optional document URL or caption with a PDF receipt when your plan supports media.
• Support: log the WhatsApp attempt next to the ledger row for dispute handling.

Why WhatsApp in Kenya

WhatsApp open rates often beat email for transactional alerts. Pair payment receipts with notifications for shipping and renewals so customers get a coherent journey instead of random pings.

Mapping Daraja fields to WhatsApp copy

Take Amount, MpesaReceiptNumber, and BillRefNumber (or your aggregator equivalents) and render a single short paragraph. Avoid dumping raw JSON into WhatsApp. Customers need certainty, not developer fields.

Failure playbook

Reconciliation

Nightly, compare successful ledger rows without WhatsApp send markers. Those gaps are either API failures or skipped jobs — both are support risks. Fixing reconciliation early prevents "I paid but got nothing" threads.

Customer trust language

Use "we received KES X" only after your ledger commits. Soft language like "we are confirming your payment" belongs to pending states. Precision here prevents chargeback-like social pressure on WhatsApp.

Practical scenarios

Here are concrete situations teams solve with this topic.

Scenario A — early-stage product

You need to prove WhatsApp automation this week. Connect a QR-linked number, send a transactional message, and measure whether customers understand and act. Keep the copy short. Log every API response. Expand only after the first path is reliable.

Scenario B — growing SME

Volume is rising and manual WhatsApp replies are failing. Automate the top one or two events first (usually payment or OTP). Train support on what the system already sends. Add scheduling and webhooks after the basics are stable.

Scenario C — developer platform

You are embedding WhatsApp into your own SaaS. Wrap FlareSend behind your service layer so product code never hard-codes HTTP details. Use queues, idempotency keys, and environment-specific API keys. Document the contract for your teammates.

Quality bar before you go live

1. Happy-path send works on a real phone.
2. Failure path shows a clear customer message or retry.
3. Disconnects are visible to an operator.
4. Consent or transactional justification is written down.
5. Someone owns monitoring for the next 30 days.

Common mistakes

• Treating WhatsApp like email blast infrastructure
• Mixing marketing copy into OTP or payment messages
• Ignoring quiet hours across African timezones
• Skipping idempotency on payment webhooks
• Leaving staging keys pointed at production numbers

Fix those five and most production incidents disappear before they start.

What to read next on FlareSend

Browse related solution pages from the footer Solutions menu, skim the FAQ for safety and pricing questions, and keep the API docs open while you implement. When you are ready, start the free trial and ship one real customer workflow end to end.

Field notes from production teams

Teams that succeed with WhatsApp automation treat it like payments infrastructure: monitored, idempotent, and owned by a named engineer. They write runbooks for disconnects, keep a staging number for tests, and review failed sends in the same standup as failed transactions. They also refuse to use the channel for unsolicited cold outreach, because reputation damage is expensive to reverse.

If you are mid-implementation, pick one customer journey, instrument it, and only then expand. Breadth without reliability creates noisy support queues. Depth with clear metrics creates a channel customers trust.

Finally, keep FlareSend docs and your internal README linked from the same place. On-call engineers should not hunt for curl examples during an incident.

Implementation checklist

• Confirm consent or transactional context before sending.
• Store API responses for support audits.
• Prefer background jobs so web requests stay fast.
• Respect quiet hours for your customers' timezones.
• Link every automation to a clear customer benefit.

Related FlareSend resources

• Features
• Pricing
• Compare vs Meta Cloud
• Blog hub
• API docs