I build payment infrastructure for businesses: gateway integrations (UPI, cards, netbanking, wallets), payout systems, webhook reliability and the reconciliation layer that keeps your books agreeing with the gateway and the bank — for India, UAE and UK stacks.
Why do payments look solved and break anyway?
Because the demo works in an afternoon. The aggregators have polished SDKs, the sandbox behaves, the first transaction sails through — and the team moves on, believing payments are done. Then production arrives with its actual personality: webhooks that come twice, or late, or never. Statuses that sit in “pending” past every timeout you assumed. Refunds that succeed at the gateway and fail in your database. Settlement files whose totals drift from your dashboard by amounts too small to escalate and too large to ignore.
At India’s volumes the edges are the road: UPI runs past fifteen billion transactions a month (NPCI publishes the data — npci.org.in), and at that scale “rare” webhook behaviour is a Tuesday. The businesses that suffer aren’t the careless ones — they’re the ones who treated payment state as a boolean and the gateway’s callback as gospel. Payments have more than two moods, and the callback is a rumour until the settlement file agrees with it.
What does payment infrastructure include?
- Integration architecture done right. Idempotent webhook handling — the discipline in full — so replays become no-ops instead of double payouts. State machines per payment: created, pending, authorised, captured, failed, refunded, disputed — with timeouts and reconciliation-driven correction, not booleans and hope.
- Multi-gateway routing and failover. Two gateways with health-based routing beat one gateway with an apology page. Built so adding a rail is configuration, not a quarter.
- Payouts with controls. Vendor and customer payouts with maker-checker on manual runs, idempotency on every instruction, and the payout-file reconciliation that catches the bank’s version of events disagreeing with yours.
- The reconciliation layer — the actual product. Daily three-way matching: your ledger against gateway settlement files against bank statements. Exact matches auto-clear; exceptions queue with reason codes; write-offs need names and sign-offs. The full method is public, and the engagement that proves it is on the work page.
- Dispute and chargeback trails. Evidence assembled from the transaction’s own history — the timeline the schemes ask for, produced instead of reconstructed.
What’s the one rule that does most of the work?
The gateway’s webhook is a rumour until reconciled. Record it, act on it provisionally, but let the daily reconciliation against settlement files be the truth that closes the loop. That single discipline — plus idempotency at every write — eliminates the class of bug that generates the 4 PM “gateway says X, we say Y” meeting. It’s the fintech engineering architecture pointed at payments: events immutable, balances as projections, external truth reconciled daily. Khalas — the meeting dissolves because the numbers agree by construction.
The regulatory layer rides on the same rails. India’s PA/PG regime, DFSA and FSRA expectations in the UAE free zones, the FCA’s PSRs 2017 in the UK — different vocabularies, one underlying demand: prove what happened to the money. A payment stack built on reconciled, immutable history answers that demand as a by-product of operating. One built on booleans answers it with a documentation sprint and a prayer.
What does fixing an existing stack look like?
Most engagements here aren’t greenfield — they’re two-week diagnostics that become four-week retrofits. Trace ten real payments end to end. Read the webhook handlers. Count the orders stuck in pending. Run the recon the team says exists. The findings rank themselves, and the sequence is nearly always: idempotency keys first, daily reconciliation second, state-machine cleanup third, the full ledger core when the bleeding has stopped. Each step pays for itself before the next begins — the “payment succeeded but order didn’t” ticket count is the metric, and it should be zero. Not near zero — zero, because every ticket in that category is a customer who paid and got nothing, which is the one experience no refund fully repairs.
Related reading
/blog/idempotency-done-right · /blog/reconciliation-at-scale · /work/reconciliation — the proof · /industries/marketplaces — where payments meet splits
The ticket-count test
Count last month’s “payment succeeded but order didn’t” tickets. More than zero? /contact — that number has a known cure, and it starts with a two-week diagnostic, seedhi baat.
Questions I actually get
Which gateways and aggregators do you work with?
Razorpay, PayU, Cashfree, Stripe, Checkout, Network International and their peers — the discipline transfers, and the quirks I have usually met before. Multi-gateway setups are normal rather than exotic; half the reconciliation pain in the market comes from running two gateways with one set of assumptions.
Can you fix our existing integration without a full rebuild?
Usually, yes — idempotent webhook handling and daily reconciliation can be retrofitted onto a live integration, and that two-to-four-week engagement is often what saves the quarter. The full ledger core can follow when the bleeding has stopped; sequencing the fix is part of the fix.
Do you support Payment Aggregator licence applications?
The systems evidence, yes: transaction trails, settlement reconciliation, merchant fund segregation, the operational controls the application must demonstrate. Counsel owns the filing itself. The build is designed so the evidence exists as a by-product of operating, not as a documentation sprint before the deadline.
What about UAE and UK payment stacks?
Yes — DFSA and FSRA-shadowed builds in the UAE free zones, FCA-regulated clients under the Payment Services Regulations 2017 in the UK. The regulatory vocabulary changes; the architecture question — can your systems prove what happened to every dirham or pound — is identical in all three markets.
How do you handle refunds and chargebacks?
As first-class flows with their own state machines and evidence trails — a refund that succeeded at the gateway and failed in your database is the classic drift seed, so both legs post as ledger events and reconcile daily. Chargebacks get the dispute timeline and document trail the card schemes actually ask for.
What does the first engagement usually look like?
A two-week diagnostic: trace ten real payments end to end, read the webhook handling, run the reconciliation you currently do, and count the pending-state orphans. The findings rank themselves — and the first fix is almost always idempotency keys and a daily recon job, whatever else the roadmap says.