SMS PaySearch documentation
Search pages in the SMS Pay documentation.
SMS PaySearch pages in the SMS Pay documentation.
Matching is how SMS Pay decides whether a provider SMS proves that a payment intent was paid. The rules are deterministic. SMS Pay does not mark payments paid from amount-only, sender-only, receiver-only, or time-proximity guesses.
The one amount-based rule is IBBL Bangla QR, where there is no reference to match. That is not a guess: each checkout reserves a payable amount that no other open checkout on the same receiver account can hold, so the amount identifies exactly one intent.
Merchant admins use Reconciliation when evidence is incomplete, risky, duplicated, expired, or needs manual review.
When a provider SMS contains a reference, SMS Pay compares that reference with pending payment intents in the same merchant environment.
Automatic PAID requires:
| Check | Requirement |
|---|---|
| Reference | SMS reference equals the short customerReference. |
| Amount | SMS amount equals the payment intent amount exactly. |
| Environment | SMS and intent are both sandbox or both live. |
| Payment method | SMS method matches the selected intent method. |
| Receiver | SMS receiver wallet matches the intent receiver. |
| Expiry | Intent is still active. |
| Reuse | SMS event and transaction ID have not confirmed another intent. |
If the reference matches but amount differs, SMS Pay routes the payment to REVIEW_REQUIRED. Do not fulfill until it is resolved.
IBBL Bangla QR SMS messages carry no reference. Instead, each checkout gets a unique payableAmount on its receiver account (the order amount, plus up to 99 paisa if that amount is already held). Automatic PAID requires the SMS amount to equal payableAmount exactly, the same environment, method, and receiver, an active intent, unused evidence, and exactly one pending intent holding that amount. If more than one intent holds it, the SMS stays unmatched for review. See IBBL Bangla QR.
If the customer paid without the correct reference, checkout can ask for the provider transaction ID. SMS Pay can match that TrxID against stored SMS events.
TrxID recovery still requires exact amount, matching receiver, matching method, same environment, active intent, and unused evidence.
| Status | Merchant action |
|---|---|
PENDING | Wait for SMS evidence, customer TrxID fallback, or expiry. |
PAID | Fulfillment can proceed after webhook verification or server-side status check. |
REVIEW_REQUIRED | Inspect evidence in dashboard. Do not fulfill automatically. |
EXPIRED | Payment window ended. Ask the customer to retry with a new intent if needed. |
REJECTED | Evidence was rejected after review. Do not fulfill. |
Use the Reconciliation and SMS Events pages to inspect:
Manual review is for resolving exceptions. It should not be used to bypass exact amount, expiry, duplicate transaction ID, or environment rules.
| Case | Expected handling |
|---|---|
| Correct reference, wrong amount | Moves to REVIEW_REQUIRED; merchant admin reviews evidence. |
| Correct TrxID, wrong amount | Moves to REVIEW_REQUIRED; merchant admin reviews evidence. |
| Missing or wrong reference | Remains pending unless TrxID recovery succeeds. |
| Duplicate transaction ID | Evidence is rejected or ignored as duplicate. |
| Bangla QR SMS with no pending intent at that amount | Remains unmatched; check the customer paid the exact payable amount before the intent expired. |
| Expired intent | Cannot auto-confirm; create a new intent if customer must pay again. |
Before going live, test these cases in sandbox:
PAID.REVIEW_REQUIRED.