Conversational · WhatsApp
The miaPOS WhatsApp Business bot lets a registered seller issue instant-payment links from a WhatsApp chat at +373 690 02 773. Same backend broker as Telegram; channel mechanics differ.
Overview
WhatsApp acceptance is a sibling channel of Telegram acceptance — same product family, same cap-svc broker contract, same payment rail. They differ in what the underlying chat API allows: WhatsApp Cloud API has no inline mode, no general group surface, and imposes a 24-hour customer-service window on free-form replies. Architecture reflects that — common stays common at the platform layer, channel-specific stays channel-specific.
For sellers — getting set up
The seller's WhatsApp phone is the identity. There is no /start, no contact-sharing handshake.
- The merchant has an account at one of the miaPOS partner banks (see For Banks) and the seller's WhatsApp phone is registered against that merchant in CAP.
- The seller opens WhatsApp on their phone and sends any message to +373 690 02 773 — or taps
wa.me/37369002773. - The bot resolves the seller's phone through the partner bank and confirms in chat in the seller's CAP-configured locale. An unknown phone gets a polite refusal.
- The seller is ready. No further setup required.
Command grammar
Short and forgiving. Five equivalent ways to issue a 100 MDL payment link:
pay 100 pay 100 "Cafea + croissant" pay 100 "Cafea + croissant" #cafea /pay 100 #cafea 100
| Command | What it does |
|---|---|
pay <amount> [<desc>] [#<tag>] | Issue a payment link for <amount> in the merchant's currency. Description and tag are optional and surface in the merchant portal for reconciliation. |
/pay <amount> … | Slash-prefixed alias of pay — equivalent. |
<amount> [<desc>] [#<tag>] | Implicit shorthand. A leading number is rewritten as pay <amount> …. Safe on WhatsApp — the Cloud API surfaces no group context to a business number, so a bare number cannot leak into a group. |
/rtp <amount> … | Request-to-Pay. Available where the underlying instant-payment rail supports it. |
/lang | Opens an interactive list with five language rows — Română, Русский, English, Français, Deutsch. The chosen locale persists per phone for all subsequent messages. |
Locales
Five locales out of the box: RO · RU · EN · FR · DE. The locale is stored per WhatsApp phone (the seller's), defaults from the partner bank's CAP record, and is changed at any time via /lang. All chat copy — confirmation, error states, paid/failed notifications, retry prompts — is locale-aware.
The 24-hour customer-service window
What this means in practice for the miaPOS bot:
- Inside the window (≤ 24 hours since the seller's last message): the bot delivers paid / failed / declined / expired updates as ordinary chat messages, in real time.
- Outside the window: the payment link itself keeps working — the customer still pays, the merchant's account is still credited. Late status updates require a Meta-approved Utility template; that rollout is in progress.
- The window is per seller, not per merchant. A seller who chats with the bot every day stays inside the window continuously.
vs Telegram
The product surface is the same. The chat-API affordances differ:
| Aspect | Telegram | |
|---|---|---|
| Address | @miaposbot | +373 690 02 773 |
| Where the bot lives | 1:1 chats, group threads, channels, inline mode | 1:1 chats only |
| Onboarding | /start + Share-phone tap | First inbound message; phone is intrinsic |
| Free-form replies | Anytime | Within 24-hour customer-service window |
| Late status updates | Anytime | Require Meta-approved Utility templates (rollout in progress) |
| Identity surface | Telegram user_id + phone (via Share-phone) | E.164 phone (intrinsic to every payload) |
| Locales | RO · RU · EN · FR · DE | RO · RU · EN · FR · DE |
| Broker contract | cap-svc Rev 2 | cap-svc Rev 2 (identical) |
| Payment rail | Same IPS rail | Same IPS rail |
Architecture (integrator view)
The WhatsApp bot is a thin channel adapter over the same broker contract used by Telegram. Phone-based seller resolution, ecomm token issuance, AES-GCM secret handling, audit trail, and merchant configuration live in cap-svc (Rev 2). The Rev 2 contract is channel-agnostic by design — it accepts a phone, returns a posUserId, and brokers ecomm tokens. The WhatsApp channel consumes it as-is with zero contract changes.
- Inbound: Meta Cloud API webhook → bot ingests
messages.from(E.164 phone) andmessages.text.body→ command parser →cap-svcresolution by phone. - Outbound: payment link delivery and status notifications via the Cloud API
POST /{phone-number-id}/messagesendpoint, with interactive list messages for the/langpicker. - Identity: production WABA + permanent System User token managed under the Finergy Tech Business Portfolio (operational facts kept out of this guide; contact
[email protected]).
Security model
- Seller resolution is gated by the partner bank's CAP record. A blocked seller's
payis refused in chat. - The payment-link page is the same hosted-checkout surface used by the e-commerce flow.
- Webhook signature verification on the Meta side uses the App Secret; the bot rejects unsigned or invalid-signature webhooks.
Roadmap
- Utility templates — Meta-approved templates per locale to deliver late status updates outside the 24-hour window.
- Multi-bank picker — interactive list to choose the merchant if a seller's phone is bound to more than one merchant (Telegram has this in production; WhatsApp parity in progress).
- Broader geo coverage — additional WhatsApp Business numbers for non-MD operations as new partner banks come online.