MakanPay is a complete implementation of the Partner Solutions Lab — Connect onboarding, online Checkout, and a server-driven Terminal integration — built as a reusable accelerator for the Singapore F&B vertical. Every flow below is live and runnable right now.
Three interfaces, one shared order ledger — so a dine-in ticket and an online order are priced identically and reconcile together.
Onboard outlets two ways, manage menus and readers, configure commercial terms, and reconcile revenue by outlet and channel.
A diner orders online and pays by card or PayNow. The receipt shows exactly where the money went.
Server-driven card-present payments with an on-screen S710, tip prompts, running tabs and refunds — plus a live trace of every API call.
The outlet is merchant of record — its licences, its brand, its name on the diner's statement.
Funds settle straight into the connected account and the platform fee is collected automatically. No transfer step, no platform treasury, nothing to reconcile between the two — and refunds reverse both sides together.
The Stripe primitives are documented. What isn't documented is the composition — the logic that repeats in every F&B engagement.
Hold the card at first order, let rounds accrue, capture the real total —
and off-session-charge any overage to the card the reader saved. Capturing
less than the hold releases the rest. setup_future_usage makes
the tap leave a reusable card behind; no Customer object is involved.
The fee is computed on the pre-tip total and fixed at PaymentIntent creation, so an on-reader tip raises the amount but never the fee. Verified live: S$20.00 + S$3.00 tip = S$23.00, fee unchanged at S$0.50.
With direct charges there is no transfer to reverse, so
refund_application_fee is the only lever — and whether the
platform forgoes its fee is a business decision, exposed at the call site
rather than buried in a default.
Service charge on the subtotal, then GST on the inclusive amount — GST applies to the service charge. Getting that order backwards under-collects tax on every transaction. Rates are per outlet.
Delivery aggregators and OTAs collect payment themselves and remit net proceeds separately. Those orders are recorded as their own channel with no PaymentIntent and no fee, so reconciliation stays honest about the boundary.
Stripe-hosted for an independent that self-serves; API-based for a chain that already holds its outlets' data and won't run 200 browser sessions. The same decision, configured rather than hard-coded.
Taken from the running application — the guest's screen, the receipt, and what the server actually did.
Every task implemented and verified against the live test API, including the optional one.
Track A patterns implemented, then documented as a Track B accelerator with the four Connect decisions reasoned through for the F&B vertical.
The artifacts the Partner Solutions Program asks for — architecture, runbook, collection, commercial terms. The whole implementation is open source under MIT — fork it, deploy it, use it with a client.