UPI Payment Verification in WhatsApp Automation

A payment begins before a QR image is sent and ends after a verified outcome is recorded. Represent created, pending, successful, failed, expired, and cancelled states explicitly. Allowed transitions prevent late callbacks, retries, or operator actions from rewriting a completed order incorrectly.

Store amount, currency, tenant, conversation, recipient, client transaction identifier, provider order identifier, and timestamps together. The AI may gather intent, but validated application code creates the order. Never let free-form model output become the amount or destination without deterministic checks.

Decode or retrieve the provider QR through a server-side media path, validate its type and size, then send it only to the recipient bound to the order. Do not accept a destination from a later callback or model response. Keep provider credentials and raw base64 data out of logs.

Persist the outbound intent transactionally with the order. If sending fails, a worker can retry the same intent without creating another payment. A stable idempotency key prevents duplicate QR messages while preserving a clear delivery history for support.

A customer message, uploaded screenshot, or AI reading of a receipt is not settlement evidence. Use the gateway callback when authenticated and confirm status through the provider API when needed. Validate tenant ownership, order identity, amount, currency, and permitted state transition before recording success.

Callbacks can be duplicated or delayed, so processing must be idempotent. Polling should use bounded backoff and a terminal timeout rather than an aggressive loop. Keep transport failures separate from genuine pending status so customers and operators receive accurate explanations.

Write the successful transition and a WhatsApp confirmation event in one database transaction. An outbox worker sends the message and records delivery attempts. This closes the crash window where payment is saved but confirmation disappears, or confirmation is sent before success is durable.

Include a safe order reference, confirmed amount, status, and provider reference such as UTR when available. Avoid exposing payer details unnecessarily. If a human agent owns the conversation, route the event according to an explicit policy rather than letting AI and staff reply simultaneously.

Provide operators with searchable order state, verification attempts, callback history, outbound status, and safe correlation identifiers. Alert on conflicting amounts, invalid callbacks, prolonged pending orders, repeated gateway failures, and success records without customer confirmation.

Run scheduled reconciliation against provider records and resolve differences through auditable actions. Test duplicate requests, delayed success, expired QR codes, worker restarts, and provider outages. Payment quality depends less on a happy-path demo than on predictable recovery from uncertainty.