Splitting a food order meant doing the math yourself, then chasing five people for money.
Pathao Pay already had a "Request Money" tool that let any user ask a friend for a specific amount. For a group food order, that meant the person who placed the order had to manually work out everyone's share - including how to fairly divide VAT, the delivery charge, and any discount across people who ordered different things - and then fire off individual, disconnected money requests with no link back to the order itself.
In practice this broke down in one of three ways: the initiator gave up on splitting and simply absorbed the full bill; they split it informally and roughly, quietly under- or over-charging whoever added the tax and delivery portion in their head; or the group stopped ordering together altogether and placed smaller, individual orders instead - which is worse for order value and worse for the group-ordering use case Pathao Food wants to encourage.
Group food ordering - offices, hostels, family dinners - is a normal and recurring behaviour on the platform. The gap wasn't that people didn't want to split bills; it was that the only tool for it lived in a different app, understood nothing about the order, and made the requester do all the arithmetic.
Why this needed order-grouping, not just a better calculator: A generic "split this amount N ways" tool can't apportion VAT, delivery charge, and discounts fairly when people order different items at different prices. Getting the math right required Split Pay to know the actual cart - which meant building it inside Pathao Food, not inside Pathao Pay alone.
My constraints: This wasn't a single-team feature. Pathao Food owns the cart, the order flow, and the UX; Pathao Pay owns the wallet, payment requests, and money movement. I was the PM authoring the PRD on the Food side, writing acceptance criteria that a separate Pay engineering team and a separate Pay PM stakeholder had to build against, with no shared backlog and no precedent inside Pathao for a feature that debits one wallet, holds funds in escrow, and pays out a rider - all while the underlying order still has to ship on time, regardless of what the initiator's friends decide to do.
Design a payment flow that touches two products and one non-negotiable constraint: the rider gets paid regardless of what friends do.
I needed to spec a feature that let a user tag cart items to themselves and their friends, calculate each person's fair share automatically, request payment from each friend through Pathao Pay, and surface the outcome clearly in order history - while never letting the social uncertainty of "will my friend actually pay" put the order, the merchant, or the rider's payout at risk.
The brief was "add split pay to food orders." The actual product problem was harder: how do you let N people jointly fund a single order, when acceptance from any one of them is optional and can arrive after the food is already being prepared?
"Let people split the bill in the app"
A UI layer on top of Pay's existing Request Money tool - tag items, fire off requests, done. Treated as a checkout feature, not a money-movement design problem.
A settlement model that never blocks delivery
An architecture where the order's fulfilment - and the rider's payout - can never depend on whether an initiator's friends respond in time. Split completion and order completion had to be two separate, decoupled outcomes.
Six decisions that shaped the feature before a single screen was built.
The obvious design treats "friend accepts payment request" as a step the order waits on before it can be confirmed as paid. I rejected that model outright.
My reasoning: A rider can't wait on three strangers to individually decide whether to pay before picking up food that's already cooked. So I specified that Split Pay can only be entered with Pathao Pay as the confirmed payment method, and the full order amount is captured against the initiator's Pathao Pay balance at checkout - the order is fully funded the moment it's confirmed, independent of anyone else's response. Friends' "payment requests" are not a precondition for the order; they're a parallel reimbursement flow into the initiator's wallet that succeeds or fails on its own timeline.
The trade-off: The initiator carries real short-term financial exposure the instant they confirm the order - not a small ask when a group order can run into several thousand taka. But it converts a multi-party, partially-completable payment problem into a single, always-resolved one: the order is paid, full stop, and everything after that is reimbursement bookkeeping.
The fastest thing to build is "divide the total by the number of people." I specified proportional, item-based splitting instead.
My reasoning: An equal split is unfair the moment two people order differently priced items - and it's the single most common complaint about informal, manual splitting today. If Split Pay reproduced that unfairness natively, it wouldn't be solving the actual problem, just moving it into the app. Item-level tagging lets each participant's share track exactly what they ordered, with VAT, delivery charge, and discounts apportioned by the same ratio (S-2, S-8) - not divided evenly regardless of who ordered the biryani.
The trade-off: Tagging every item to a person is more UI work for the initiator than tapping "split 4 ways." I accepted that friction deliberately - it's the cost of the split actually being correct - and offset it with sensible defaults (unassigned items default to the initiator, not to an even split across everyone).
A tempting "smarter" design lets a split partially succeed - two of three friends pay, the initiator only covers the third person's share. I specified the opposite: if any single friend fails to accept their payment request, the entire split is cancelled and the initiator becomes liable for the full bill.
My reasoning: Partial settlement sounds friendlier but multiplies the number of reconciliation states the system - and the initiator - has to track: which of N requests are pending, accepted, rejected, or expired, and what does "partially split" even mean in order history six months later? All-or-nothing collapses every outcome into two: split completed or split cancelled, initiator pays. Combined with Decision 1, this is also financially safe - the initiator already funded the order, so "cancelled" just means no reimbursement arrived, not a collections problem.
The trade-off: One unresponsive friend can sink an entire group's split. I mitigated this - not solved it outright - with two upstream guardrails: an invalid-account alert at the moment of tagging (Section 07) so obviously-doomed splits fail early, not after checkout, and a "recently added contacts" surface so initiators default to friends who've reliably paid before.
Split Pay could theoretically support other payment rails for the initiator. I restricted it to Pathao Pay only, for both the initiator and every tagged friend.
My reasoning: Every alternative - card-on-file transfers, mixed rails per participant - multiplies the settlement paths Pay's engine has to support and multiplies the ways a split can half-succeed. A single settlement rail keeps the money-movement contract between Food and Pay to one shape. Since this would otherwise exclude any user or friend without a Pay account, I specified that a Food user without Pay is redirected straight into Pay's registration flow rather than being told "not available" - and any tagged friend without a Pay account triggers an inline invalid-account alert at the moment of tagging, not a failure discovered later.
The trade-off: This adds a hard registration step for new users mid-checkout. I judged that acceptable because Split Pay is opt-in - a user who doesn't want to register can simply pay normally - and because it turns Split Pay into a genuine acquisition channel for Pathao Pay, not just a Food feature that happens to use it.
Once items are tagged and requests may already be in flight, the cart can still change - a customer adds an item, support (CX) adjusts an order, an out-of-stock item gets removed. I specified that any post-tagging cart change that increases a participant's payable amount cancels the split entirely and reverts liability to the initiator; a change that decreases it triggers an automatic partial-escrow release back through Pay - it never silently re-splits.
My reasoning: Silently recalculating and re-sending requests after a friend has already agreed to pay one amount is a consent problem, not just an engineering one - nobody should discover they owe more without being asked again. Cancelling and re-collecting from the initiator alone is the option that never bills a participant for something they didn't explicitly agree to.
The trade-off: A single cart edit - even a CX-initiated one the initiator didn't cause - kills a split that might already have three friends' agreement. I accepted this because the alternative (auto-adjusting live financial commitments between people) is a worse failure mode than "please redo the split."
Once a friend is tagged into a split, they have a legitimate reason to track the order. I specified that they see only delivery status in their timeline view - never the payment distribution, other participants' shares, or payment status details.
My reasoning: Being tagged into someone else's order shouldn't grant visibility into that order's full financial breakdown - who paid what, who's still pending, what the total bill was. That's the initiator's information to hold, not something every tagged friend inherits by being on the split. The initiator retains full visibility (Section 06); everyone else gets exactly what they need to know their food is coming.
One checkout, two systems of record - split cleanly along a single line: money math vs. money movement.
Customers experience Split Pay as one continuous flow inside Pathao Food. Underneath, it's built across two products that don't share a database or a release calendar, and I drew the boundary between them deliberately, so each side had exactly one job.
Why I insisted on this boundary: Food owns the bill math exactly once - Pay trusts the amount it's told to move, rather than re-deriving it. Pay owns money movement exactly once - Food never touches a wallet balance directly. The trade-off is that every state change (a cart edit, a rejected request, a cancellation) needs a precise, versioned contract between two backlogs I didn't fully control - which is why the acceptance criteria in the Appendix specify a system-of-record for each field, not just a UI behaviour.
The math has to be specified before the UI - because the UI is just a way of collecting inputs to this formula.
Every participant's payable amount is a function of the ratio of item prices tagged to them against the full order. I specified the exact sequence: tag items -> compute each person's raw item total -> compute the ratio across all participants -> apply that same ratio to the full bill (after VAT, delivery, and discounts) -> the payable amounts always sum back to the total, to the poisha.
Worked example, as specified in the PRD
Three friends split a food order. P1 is tagged to a pizza; P2 is tagged to a second pizza and a burger; P3 is tagged to a kacchi; P1 and P2 share a biryani between them.
| Participant | Items tagged | Item subtotal |
|---|---|---|
| P1 | Pizza (qty 1 @ 200) + half of shared Biryani (qty 1 @ 300, split with P2) | 200 + 150 = 350 |
| P2 | Pizza (qty 2 @ 200 = 400) + Burger (qty 3 @ 100 = 300) + half of shared Biryani = 150 | 400 + 300 + 150 = 850 |
| P3 | Kacchi (qty 2 @ 300 = 600) | 600 |
| Order total | Sum of all item lines | 1,800 |
| Step | Calculation | Running total |
|---|---|---|
| Item subtotal | 200 + 400 + 300 + 600 + 300 | 1,800 |
| + VAT, SD & delivery charge | + 300 | 2,100 |
| - MOV-based discount | - 100 | 2,000 |
| - Promo | - 100 | 1,900 (final bill) |
| Participant | Split ratio | Payable amount |
|---|---|---|
| P1 | 1 | (1 / 6) × 1,900 = ৳316.67 |
| P2 | 2 | (2 / 6) × 1,900 = ৳633.33 |
| P3 | 3 | (3 / 6) × 1,900 = ৳950.00 |
| Total | 1 : 2 : 3 | ৳1,900.00 - reconciles exactly |
Fidelity note: The 1:2:3 ratio above is the simplified working ratio used in the original spec's example (derived from each participant's item-price contribution, including their half-share of the shared Biryani). I've kept the worked numbers exactly as specified rather than "correcting" them - the discipline of getting a spec's own arithmetic right is part of the job.
Discount distribution follows the same ratio (S-8)
Discounts aren't a flat deduction applied once - they're distributed proportionally across participants using the same split ratio, so nobody's share of the savings is disconnected from their share of the bill.
| Participant | Ratio | Discount received (of ৳100 total) |
|---|---|---|
| P1 | 1 | (1 / 3) × 100 = ৳33.33 |
| P2 | 2 | (2 / 3) × 100 = ৳66.67 |
A gap I found and closed: rounding policy. The example above reconciles cleanly, but proportional division of real bills rarely lands on a whole poisha for every participant - the PRD didn't specify what happens to the fractional remainder. I specified that any leftover fraction after ratio-based division is added to the initiator's payable amount, never distributed silently across friends. That way the sum always reconciles exactly to the total bill, and the "extra poisha" always has one clearly accountable owner instead of being invisible rounding drift.
From "Split Pay" tap to rider payout - the full sequence I specified.
This is the order the feature actually runs in, stitched together from S-1 through S-6. The critical property, carried through from Decision 1: steps 6 and 7 never wait on step 5.
The cases that break a naive split - specified before they became support tickets.
A split that only handles the happy path isn't a fintech feature, it's a demo. I specified explicit behaviour for every way the underlying cart or the friend-response cycle can go sideways.
Unaccepted requests and recovery
If a friend doesn't accept their request, the split is cancelled and the initiator is notified with the specific reason - not a generic failure message. Because the initiator's payment method was already locked to Pathao Pay for the order, no separate "change payment method" step is needed to complete the order itself; that control exists for the narrower case where a customer needs to resolve a payment issue on an ongoing order outside the split flow (S-4).
A gap I found and closed: request expiry. The original spec described what happens when a friend "fails to accept" a request but didn't define a timeout - in theory, a request could sit open indefinitely. I specified an explicit expiry window tied to a defined SLA before the order's preparation timeline completes, so every split resolves to a definite state (completed or cancelled) within a bounded time, rather than staying ambiguous while the food is already on its way.
Deliberately out of scope for v1: multi-address group orders (splitting across more than one delivery drop-off), splitting across payment rails other than Pathao Pay, and re-splitting a cancelled split automatically after a cart edit. The original PRD left "Not Doing / Out of Scope" blank - these are the boundaries I set myself, to keep the settlement model to the single shape described in Decision 4.
Because the feature hasn't shipped, this is the plan I designed - not results I can report.
Every claim in Section 09 rests on two kinds of pre-launch validation I specified: usability testing of the tagging and split-outcome flows, and exhaustive test-case coverage of the calculation engine itself. Both are scoped and ready to run against the first working build.
Planned usability testing
| Scenario | Method & sample | Hypothesis / success criteria |
|---|---|---|
| First-time split, no prior exposure | Moderated task-based test, n=8 users who've never used Split Pay | ≥6/8 complete tagging and checkout without moderator prompting |
| Tagging a friend without a Pay account | Same moderated session, seeded scenario | Alert is understood and resolved (remove or ask friend to register) within one retry |
| All-or-nothing rejection consequence | Scenario-based interview, n=8, before confirming checkout | ≥7/8 can correctly state "I pay the full bill if any friend rejects" before submitting |
| Cart edit after tagging (cancellation) | Moderated test with a seeded mid-flow cart change | Cancellation reason is clear enough to generate <1 follow-up support question per session |
| Secondary participant timeline view | Moderated test with a second test account as the tagged friend | Friend confirms they can track delivery but correctly cannot see payment distribution |
Calculation model test coverage
| Edge case | Why it matters | Expected behaviour |
|---|---|---|
| Single participant (initiator only) | Split Pay entered but nothing tagged to anyone else | Initiator pays 100%; Split Pay behaves identically to a normal Pathao Pay order |
| Shared item split across >2 people | Fractional shares compound rounding risk | Each share computed to the poisha; remainder rule (Section 05) applies once at the end |
| Discount exceeds a participant's share | Proportional discount could theoretically push a payable amount negative | Payable amount floors at zero; any residual is re-absorbed by the initiator, never a negative charge |
| Friend cancels mid-tagging (before checkout) | Distinguish from a post-checkout rejection, which triggers the S-3 cancellation path | Their items simply revert to unassigned and default to the initiator - no order-level cancellation, since no request was ever sent |
| Maximum group size | UI and request-fan-out both need a sane upper bound | Capped group size defined explicitly rather than left unbounded, to keep the all-or-nothing failure surface manageable |
What I expect to happen once this ships - and exactly how I'll know if I'm right.
These are pre-launch targets, not measured outcomes. Each one is tied to a specific mechanism in the design (not a hope), and each is meant to be checked against real data within the first 90 days of a phased rollout.
| Metric | Target | Why I expect this |
|---|---|---|
| Split Pay adoption among group orders | 18-25% within 90 days | Proxy: existing manual "Request Money" usage tied to food-linked transfers, plus comparable split-bill adoption in peer delivery apps |
| Split completion (all-friends-accept) rate | ≥70% | Driven by the invalid-account pre-check removing the most common late failure, plus "recently added contacts" nudging toward reliable payers |
| Reduction in manual money-request flows for food orders | -60% | Native in-order requests replace the old two-app, manual-math workaround entirely for tagged users |
| New Pathao Pay accounts sourced from Food's registration gate | 10-15% of split initiators without prior Pay accounts | Benchmark from comparable mandatory-registration conversion funnels; Decision 4 turns a blocker into an acquisition moment |
| Rider payout delay caused by split status | 0% - by design, not by luck | Direct consequence of Decision 1 - payout is architecturally decoupled from split resolution, not merely "usually fast" |
| CX escalation rate on split orders | <2% of split orders | Explicit cancellation reasons, scoped timeline visibility, and a bounded request-expiry window remove the most common sources of "why did this happen" tickets |
How I'd actually validate these: a phased rollout - internal dogfooding, then a capped-percentage cohort, then general availability - with each stage's real numbers checked against the targets above before proceeding to the next. Targets that miss by a wide margin (particularly split completion rate) would trigger a UX review of tagging and the invalid-account flow before scaling further, not a quiet redefinition of "success."