Raast, the instant payment system run by the State Bank of Pakistan, has changed how money moves in the country. Customers can send money from one bank or wallet to another in seconds, usually using a mobile number as a Raast ID instead of a long account number, and person to person transfers are free for users. For businesses, that creates an obvious opportunity: fewer cash on delivery headaches, faster settlement and lower costs than card payments.
It also creates a practical problem many businesses discover after launch. Receiving money is easy. Knowing which order or invoice a payment belongs to, automatically and reliably, is where the engineering work is.
How businesses can accept Raast payments
There are three broad approaches, from simplest to most integrated.
1. Share your Raast ID or account details
The customer pays manually and sends a screenshot. This costs nothing to set up and is what many small sellers already do. The downside is manual checking of every screenshot, easy fraud with edited images, and no automatic link to orders.
2. Static or dynamic QR codes
Raast supports QR based merchant payments. A static QR is the same code for every payment, printed at a counter, and the customer enters the amount. A dynamic QR is generated per transaction with the amount and a reference embedded, which makes automatic matching far easier. Dynamic QR on checkout pages and POS screens is where most integrated setups head.
3. Request to pay through an API
Your system sends a payment request to the customer’s bank app or wallet for a specific amount and reference. The customer approves, and your system is notified. This is the most seamless experience, and availability depends on your bank or payment service provider.
How integration actually works
Businesses do not connect directly to Raast. Access comes through your bank or a licensed payment service provider or electronic money institution that offers merchant services. They provide the API, the QR generation and the payment notifications. So the first step is not writing code. It is talking to your bank or PSP about:
- Whether they offer Raast merchant acceptance through an API, and which features: dynamic QR, request to pay, refunds.
- How you receive confirmation: a webhook call to your server, polling an API, or only a statement.
- Fees for merchant transactions, settlement timing and any limits.
- Sandbox or test environment availability.
- Documentation quality and technical support responsiveness.
Terms and features differ between providers and change over time, so compare current offers directly. Our broader guide to payment gateway integration in Pakistan covers how to evaluate providers.
The hard part: reconciliation
Reconciliation means matching every incoming payment to what it was for. Done badly, staff spend hours comparing bank statements with orders, customers get “we have not received your payment” messages for payments that arrived, and some orders ship unpaid.
Design principles that avoid the mess
- Always use a unique reference per payment. Dynamic QR and request to pay carry it automatically. For manual transfers, show the customer a short order code to include.
- Trust confirmations from the provider, never screenshots. Mark an order paid only when your system receives a verified notification or finds the transaction through the provider’s API.
- Handle partial and duplicate payments. Customers pay less, pay twice, or pay two orders in one transfer. Your system needs clear states for each.
- Make webhooks idempotent. Providers may send the same notification more than once. Processing it twice must not credit the order twice.
- Run a daily automated reconciliation against the provider’s settlement report to catch anything the real time flow missed.
- Plan for unmatched payments. A queue where finance staff can match leftovers manually, with an audit trail.
Refunds
Refunds are frequently an afterthought. Confirm how your provider supports them, whether through API or only manually, and how long they take. Record refunds against the original order and payment so accounts stay clean.
Security considerations
- Verify webhook signatures so nobody can fake a “payment received” call to your server.
- Never store banking credentials in your application code. Use secure secret storage.
- Rate limit payment request creation to prevent abuse.
- Log every payment event with timestamps for dispute handling.
Where Raast fits alongside other payment methods
Raast works best for customers already comfortable with mobile banking apps and wallets, and for higher value transactions where card fees hurt margins. Cards still matter for customers who prefer them, and cash on delivery will not disappear overnight in many categories. Most stores and service businesses will offer a mix. For online stores, reducing COD dependence also reduces refused parcels, discussed in AI for ecommerce stores.
Use cases where instant payments shine
- Online stores offering a prepay discount instead of COD.
- Schools and institutes collecting fees with a unique reference per student and month. See school management system features.
- Property and instalment businesses matching monthly payments to plots and files. See property management software.
- Clinics and labs taking advance payment for appointments.
- B2B distributors collecting from retailers against invoices. See distribution software.
A realistic project plan
- Choose a bank or PSP and obtain sandbox access and documentation.
- Design payment states and reconciliation rules before writing code.
- Build QR or request to pay flows and webhook handling in sandbox.
- Test edge cases: duplicates, partial payments, timeouts, refunds.
- Pilot with a small share of customers and reconcile daily by hand alongside the automated process.
- Roll out fully once the numbers match consistently.
Bank or payment service provider: how to choose
Both routes can give you Raast acceptance, and neither is automatically better. The right choice depends on your volume, your technical team and how much you want to depend on one partner.
- Going through your own bank can mean settlement straight into the account you already use, fewer intermediaries and a relationship manager you can call. Bank APIs can also be slower to onboard, with more paperwork and documentation that assumes a large technical team.
- Going through a payment service provider often means faster onboarding, cleaner developer documentation, a single integration that also covers cards and wallets, and ready dashboards. In exchange you add a partner between you and your money, with their own fees, settlement schedule and support quality.
A practical test: ask each candidate for sandbox access and have your developer build a dynamic QR payment and a webhook handler in a day or two. How easily that goes tells you more about the next two years than any sales presentation.
A worked example: one order, start to finish
It helps to see the states an order moves through in a well designed system.
- Order created. The customer checks out. Your system creates order 10482 with status awaiting payment and an expiry time, for example 30 minutes.
- Payment request issued. Your server asks the provider for a dynamic QR or request to pay for the exact amount, tagged with a unique reference tied to order 10482. The response is stored.
- Customer pays. The customer approves in their banking or wallet app. Your checkout page shows “waiting for confirmation” and checks status every few seconds.
- Confirmation received. The provider calls your webhook. Your server verifies the signature, looks up the reference, confirms the amount matches, and marks the order paid. If the same webhook arrives again, nothing changes.
- Fulfilment starts. Only now does the warehouse or service team see the order as ready to process.
- Expiry. If no confirmation arrives before the expiry time, the order becomes payment expired, stock is released, and the customer gets a message with a link to pay again.
- Late payment. If a payment arrives after expiry, it lands in an exceptions queue for staff to either reinstate the order or refund, never silently ignored.
- Daily reconciliation. Each morning the system compares yesterday’s paid orders with the provider’s settlement report and flags any difference.
Every state has a clear owner and a clear next step. That is what removes the “I paid but you say I did not” conversations.
Customer experience details that cut support calls
- Show the exact amount and a countdown on the payment screen so customers do not pay stale amounts.
- Confirm instantly on screen and by SMS or WhatsApp once payment is verified.
- Explain what to do if the app shows success but your site does not: wait two minutes, then use a “check payment status” button rather than paying again.
- Keep a payment history page for logged in customers with references they can quote to support.
- Offer a fallback, such as card or cash on delivery, if a customer’s bank app is having trouble.
Reports your finance team will ask for
- Payments received per day, with settlement status.
- Unmatched and partially matched payments, with ageing.
- Refunds issued, pending and failed.
- Fees charged by the provider compared against the agreed rate.
- Payment method mix over time: Raast, cards, wallets, cash on delivery.
Build these from the start. Finance teams that can see the numbers trust the system, and fewer manual spreadsheets get kept on the side. If your payments feed an ERP, see what an ERP really costs for how accounting integration fits in.
Frequently asked questions
Can a small business accept Raast without development?
Yes, by sharing a Raast ID or static QR, with manual confirmation. Integration becomes worthwhile once order volume makes manual checking slow or error prone.
Do customers pay a fee?
Person to person Raast transfers are free for users. Merchant fees and terms depend on your bank or provider, so ask them directly.
How long does integration take?
With good provider documentation, a basic dynamic QR flow with webhooks and reconciliation is usually a matter of weeks rather than months. Provider onboarding and approvals often take longer than the coding.
Can we use Raast for recurring payments like monthly fees?
Request to pay can be sent each month for fees, instalments or subscriptions, depending on what your provider supports. Customers still approve each payment, so reminders and an easy payment link matter.
What should we do with payments that have no reference?
Put them in an exceptions queue, match them using amount, time and payer details where available, and record who matched each one. Then improve the checkout flow so references are always included.
The bottom line
Raast lowers the cost and friction of getting paid. The businesses that benefit most treat reconciliation as the core of the project, use unique references for every payment and trust only verified confirmations.
Our fintech development team builds payment integrations and reconciliation systems for Pakistani businesses. Talk to us before you choose a provider.