Building Orderflow's payment layer. One interface for every provider, settlement from the ledger, and hard lines between pending and paid, and between unknown and failed.

2 min readOrderflow case study

Orderflow runs food orders, event tickets and utility payments through one shared engine on WhatsApp, and real money moves through it every day. The difficult part of the payment layer was not taking a payment. It was knowing, at every moment, what state the money was actually in.

One interface, several providers

Payment providers plug in behind clean interfaces. Rubies and Squad sit behind the same contract, with dedicated virtual accounts and instant bank transfer reconciliation, so food orders, tickets and vending all share one payment path.

Pending is not paid

A missing provider confirmation is not a completed transaction. Until a payment is confirmed and reconciled, the order stays pending and nothing is fulfilled. A ticket is not issued and electricity is not vended on the strength of a payment screen.

The merchant needs an order they can rely on, not just a successful payment screen.

Unknown is not failed

Payouts get the same rule in the other direction. A payout status checker follows each payout and never marks an unknown payout as failed. An unknown payout stays open until the provider confirms what happened, because one marked failed by mistake could be paid twice.

Trust the signature

One bug came down to one word. A payment Rubies had confirmed did not register as successful, because one side of the integration said “SUCCESS” and the other said “Successful”. I fixed the match, then added HMAC signature verification, so a webhook only changes an order when its signature shows it came from Rubies.

Settle from the ledger

Settlement is calculated from ledger entries, grouped by day cycle, with audit trails and a capped processing fee. When a merchant asks why a payout is what it is, the answer is the list of entries behind it.

Change without stopping

A payment platform does not get a quiet hour for maintenance. Database migrations ship without downtime, the develop branch deploys to staging and main deploys to production, and every change is verified before it moves.

Most of the work in a payment system is deciding what you are allowed to believe. The rest follows from that.

Keep reading

The reliability work nobody asks for

Orderflow case study