The problem they solve
A UPI payment is between the customer's bank and yours. The web page the customer was on has no reliable way to know it happened. A gateway that trusts the customer's "I paid" button is trivially cheated.
Bank observers close that gap: they watch the payment alerts your bank already sends, and match them to open payments.
How they work
| Observer | Reads |
|---|---|
| SMS observer | Bank credit SMS on an operator-controlled Android phone, forwarded to the gateway |
| Gmail observer | Bank credit emails in an operator-controlled mailbox, over a read-only Google connection |
Each incoming notification is parsed for amount, timestamp and reference number, then attributed to a payment whose amount and time window it fits. A payment confirmed by two independent sources carries a higher verification level than one confirmed by a single source, and that level travels with the payment into your webhook.
Observers read the gateway operator's bank notification channels. They do not read a customer's or a merchant's messages or mail. The mailbox connection is authorised through Google's own consent screen with read-only scope, and its token is stored encrypted.
Resilience
- Polling is coordinated into a single loop with a cooldown, so observers cannot flood the gateway or contend on the database.
- Duplicate notifications are recognised and dropped.
- A late notification is still honoured inside a grace window, so a slow bank SMS does not cost you a sale.
- If a receiving UPI ID's bank is down, the admin can mark it down and payments fail over to the next account in the pool.
- Observer health is visible in the admin console, so a disconnected phone or an expired mailbox token is noticed rather than silently dropping verifications.
What this means for you as a merchant
Nothing to install. Observers are part of the gateway the operator runs. What
you get from them is the guarantee behind every SUCCESS: it was matched to an actual
bank credit, not assumed.
See Security for the full verification model.