Raast Merchant Payments Integration Kit with Dynamic QR, Request to Pay and Reconciliation
Pakistan's Raast instant payment system supports merchant payments by QR code, alias and request to pay, but small businesses and developers struggle to connect it to their shops and invoices. Build an open integration kit: a simulated payment service provider API modelled on Raast's person-to-merchant flows, a merchant dashboard, dynamic QR generation per order, request-to-pay links and automatic reconciliation of payments to orders. Design it so a real provider's API could replace the simulator later.
Intermediate
A small team, or one strong student willing to learn something new.1 semester · 2 students
7 to ship
4 optional extrasSuggested stack
What you should ship
- A study of the State Bank's published Raast P2M material and a written model of the flows the kit supports
- A simulated provider API with payment status changes, signed webhooks and realistic failures (timeouts, duplicates, late confirmations)
- Dynamic QR generation with the order amount and reference, plus static QR for walk-in payments
- Request-to-pay links sent by SMS or email for invoices
- Idempotent webhook handling and a reconciliation job that matches every payment to an order or flags it
- A merchant dashboard: orders, payments, unmatched payments and daily settlement summary
- An adapter interface so a real provider can replace the simulator, with contract tests
If you have time left
- A plug-in for a common online store platform
- Refund and partial payment handling
- Urdu interface for small shopkeepers
- A load test of webhook handling at peak hours
The problem: instant payments, manual bookkeeping
Raast, the instant payment system run by the State Bank of Pakistan, lets people send money between banks and wallets in seconds. In December 2023 the State Bank launched Raast person-to-merchant (P2M) payments, which let businesses accept payments through static and dynamic QR codes, Raast aliases, IBANs and request to pay. For many small online sellers and service businesses, though, the hard part is not receiving money. It is knowing which order a payment belongs to, handling customers who pay twice or pay the wrong amount, and closing the day's books.
Most small businesses end up checking bank notifications by hand and matching them to WhatsApp orders.
What already exists and the gap
- Banks and payment service providers offer Raast P2M acceptance to merchants through their own apps and portals.
- Payment gateways for cards and wallets provide checkout pages and plug-ins for online stores.
- India's UPI ecosystem has mature developer tools for collect requests, QR and reconciliation, which show where Pakistan's tools could go.
The gap is open, well-tested integration code that small developers can learn from: order-linked dynamic QR, request to pay, idempotent webhooks and reconciliation, with the real provider behind a clean interface.
Inspiration
The State Bank's own Raast pages and circulars describe the P2M modes and the timeline for banks to support them. Stripe's public engineering writing on idempotency keys and webhook design is a good guide to doing payment integrations safely. Your project applies those lessons to Raast-style flows.
What you build
- Shop owners create an order, show a QR or send a payment link, and see it marked paid automatically.
- Developers get an integration kit and simulator they can run locally.
- Accountants get a daily settlement summary with every unmatched payment listed.
The technically interesting part
- Simulating reality. Real payment networks deliver webhooks late, twice or out of order. Your simulator should too, so your code is tested against it.
- Idempotency. A payment confirmation processed twice must not mark two orders paid or double count revenue.
- Reconciliation. Match payments by reference, amount and time, and handle partial payments and mismatches.
- Security. Verify webhook signatures, protect merchant credentials and log every state change.
How to evaluate it
- Correctness under chaos: run 10,000 simulated payments with duplicates, delays and failures and show zero double counting and zero lost payments.
- Reconciliation rate: share of payments matched automatically.
- Contract tests that any real provider adapter must pass.
- Merchant usability: time to set up and take a first payment.
Suggested plan
- Weeks 1 to 3: study the Raast P2M material and design flows and data model.
- Weeks 4 to 6: simulator and webhook design.
- Weeks 7 to 10: QR, request to pay, reconciliation and dashboard.
- Weeks 11 to 13: chaos testing and contract tests.
- Weeks 14 to 15: report and demo.
Path to a product
Many Pakistani small businesses want low-cost digital payments without heavy integration work. A team that partners with a licensed provider could turn the kit into a payment plug-in or reconciliation service. The project is strong evidence for backend and fintech engineering roles.
Scope warning
You are not connecting to Raast directly: only regulated entities can do that. Build against your simulator and describe how a licensed provider's API would plug in. Never store card data or real customer credentials, and do not handle real money.
Learn what you need on Sefism
- Backend roadmap: APIs, webhooks, queues and idempotency.
- Full-stack roadmap: the merchant dashboard.
- Stripe documentation: a model of well-designed payment APIs and webhooks.
- Stripe engineering blog: writing on idempotency and reliable payments.
- OWASP API Security Top 10: securing the integration.
Get help with this idea
Payment code fails at the edges: duplicates, delays and partial payments. Tauseef can help you design the simulator and the tests that prove the kit is safe. If you are new here, create a free account first.
Ideas and guidance, not finished projects
These are project ideas and scoping guidance, published free for students to use as a starting point. I do not build, write, or sell final-year projects, and I do not complete coursework for anyone. Take an idea, make it yours, and build it.
Not sure this one fits you?
I help students pick an idea that matches their skills and their deadline, then scope it down until it is finishable. Guidance only, never done for you.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
Follow along
New writing, resources and project ideas land here first.