Adding a pay button is only one part of accepting money. A software product also needs to know which order was paid, what happens after a delayed confirmation, and how staff resolve a dispute. In Pakistan, start with the payment provider’s actual capabilities and build the accounting workflow around them.
Understand the rail and your provider separately
SBP describes Raast as Pakistan’s national instant payment system supporting real-time digital payments. That does not imply every software business can directly integrate every capability. Your bank or payment provider determines the available merchant service, technical interface, onboarding process, and commercial terms.
Before choosing an integration, obtain the current documentation and ask how payment confirmation, transaction queries, refunds, settlement, and support work. Confirm whether the proposed merchant category is supported. A feature seen in a consumer banking application may not be exposed through the merchant API you can access.
Model orders and payments as separate records
An order can exist before payment, and one order may receive several payment attempts. Store a unique order reference and the provider’s transaction identifiers. Keep amount and currency explicit. Do not infer a successful payment from a user returning to a success page.
Use authenticated provider confirmation or a verified transaction query according to the integration’s documentation. Handle repeated notifications without applying the payment twice. Record state transitions so an operator can see whether a record is pending, confirmed, failed, or reversed.
Treat uncertainty as a visible state
A timeout does not prove that a payment failed. The provider may have accepted it before the connection dropped. Show a pending state and follow the provider’s approved reconciliation procedure. Retrying a charge blindly can create duplicate-payment disputes.
For example, if an order remains pending after a network error, check its referenced transaction before asking the buyer to pay again. Keep that procedure in the support interface. A screenshot can help investigate a complaint, but it should not automatically grant service without verification.
Design refunds and daily reconciliation
Clarify who may initiate a refund, what evidence is needed, and how the result returns to the order ledger. A refund request and a completed refund should be distinguishable. Restrict consequential actions and preserve an audit record.
At a defined cadence, compare provider records with the application’s ledger. Flag unmatched transactions, amount differences, reversals, and pending items beyond the expected window. Give each exception an owner. A successful checkout demonstration does not verify this operational loop.
Test the awkward cases before launch
Test duplicate notifications, delayed confirmation, interrupted checkout, incorrect amounts, rejected signatures, and concurrent requests. Use the provider’s sandbox and approved test mechanisms. Confirm what happens when support staff cannot immediately obtain a provider response.
Document recurring fees and settlement expectations using the provider’s current agreement. Avoid hardcoding a generic percentage found in an old article. The engineering objective is a payment record that staff and customers can trust, even when the happy path fails.
Put this into practice
- Verify merchant capabilities and terms with the provider.
- Keep order and payment identifiers separate.
- Authenticate confirmation and handle duplicates.
- Provide a pending state and a reconciliation procedure.
- Test refunds, delays, reversals, and mismatched amounts.
Frequently asked questions
Does Raast mean every app has direct API access?
No. Confirm the integration, onboarding, and capabilities available through your participating bank or provider.
Can a success redirect prove an order was paid?
No. Verify payment through the provider’s supported server-side confirmation or transaction-query mechanism.