IdeafintechPakistan
Settlement reconciliation across Pakistan’s five payment rails
A mid-size Pakistani merchant now takes money five ways and reconciles it by hand. Sell them the software that does not exist.
FounderDuels Score
Nobody has rated this yet
out of 100
Log in to say what you think of this idea.
The problem
A shop or clinic of any size now accepts Raast QR, card terminals, JazzCash, Easypaisa and plain bank transfer. That is five settlement files, five timings, five formats and five sets of fees — reconciled in a spreadsheet by someone who should be doing something else, with errors nobody catches because nobody can see across all five.
The solution
Ingest every settlement feed a Pakistani merchant receives, normalise it, match payouts to transactions, surface the differences, and export something an accountant and the FBR both accept. Unglamorous, recurring, and painful enough to pay for.
Who it's for
Pakistani merchants above roughly 500 transactions a month: restaurant groups, pharmacy chains, clinics, retail with more than one branch.
The market
More than 2.6 million merchants are on Raast P2M and roughly 125,000 have card terminals. The overlap — merchants running both plus wallets — is the paying segment.
How it makes money
Monthly SaaS per location, priced against the salary cost of the person currently doing it in Excel.
More detail
Nobody will write a thread about this company. Every merchant over a certain size will pay for it. ## The problem, concretely A restaurant group with four branches in Lahore takes money over Raast QR, two card terminals per branch on different acquirers, JazzCash, Easypaisa, and direct bank transfer for corporate orders. Each produces its own settlement file, on its own schedule, with its own fee structure and its own identifiers. Nobody reconciles this properly. They reconcile the card terminals because the acquirer sends a statement, they eyeball the wallet balances, and they assume the Raast payments arrived because customers stopped complaining. Losses from mismatches, double-refunds and missing settlements are invisible because there is no view that would make them visible. ## What to build - **Ingestion** for each rail's settlement format, including the ones that arrive as a PDF emailed to the owner. - **Matching** between what the point of sale recorded and what actually settled, with a tolerance for timing differences. - **An exceptions queue** — the only screen that matters. Everything that did not match, ranked by money at risk. - **Exports** that a Pakistani accountant and the tax authority will both accept without rework. ## Why this is defensible Integrations are a moat when they are tedious. Every rail added is weeks of work that a competitor also has to do, and the value to the customer is superlinear: reconciling four rails is more than twice as useful as reconciling two. ## Why now The rails multiplied in the last three years. Raast P2M merchant onboarding passed 2.6 million by March 2026. The mess is new, it is growing, and the tooling did not arrive with it.
Discussion
Log in to join the discussion and like comments.
Log In to Comment