Back

Dynery · DyneryPay · Split Method

From Split-Pay Screens to a Multi-Party Payment System

Six weeks to launch. One live incident exposed the missing state model behind a multi-party checkout.

Menu · Cart · Three split methods · Member supportExplore the shared order, payment responsibilities, and recovery states.

Three ways to settle one bill, designed twice in one summer.

Role: Lead & sole product designer, partnered with PM and engineering.
Attribution: Co-defined V1 with PM; led the V2 redesign end to end with PM and engineering.
Timeline: Three dining modes, designed and shipped in six weeks, design running parallel to engineering. V1 launched June 25, 2026. The V2 design was delivered to engineering in September 2026.
Scope: Split checkout across pickup, delivery and dine-in: the consumer app plus the Dynery Merchant Platform, the merchant-side SaaS the same bill passes through.

Part one

What the first launch exposed

One real order, six weeks of decisions behind it, and twelve defects that turned out to be one problem.

01The first live delivery order: three systems, three answers

The order was placed at 9:48 and accepted into a store that opens at noon. The app showed $68.27 while the button read Pay $45.33 for everyone. The cancel never reached the point of sale: two couriers arrived for an order that no longer existed, and the merchant’s report still counted the sale, tax and royalty on a meal nobody ate.

One order · 9:48 AM · July 24

App

Bill$68.27

ButtonPay $45.33 for everyone

two amounts disagree

Merchant POS

Payment statusPAID

Order noteCANCELED

a contradiction, in writing

Couriers

Courier 1, then courier 2arrive

Storeopens 12:00

the order no longer exists

Three systems, three answers, no error screen anywhere. Only humans noticed.

“I cancelled, or think I did.”Pilot customer

The next evening the pilot merchant, stopped by a greyed-out pay button with no reason given, asked the question that shows how far the product’s vocabulary had drifted from its users.

“What is the meaning of session here guys?”Pilot merchant

Split evenlySplit the total bill 1 ways

Shown to a solo user the same week. One line of copy gave the whole model away.

02Six weeks bought one checkout for four people

The three-way split existed from day one. What each mode should look like in each state did not: one sheet carried DINE IN · TABLE 12 above delivery details, the split control and the totals.

A fixed Seattle pilot date narrowed V1 to the core path:

happy path firstper-dish splitting deferredgroup states left undefined on purpose

The overnight handoff review produced thirty-one threads; the sharpest asked where the interface shows who has paid and who we are still waiting on. It was the first time anyone had asked the question this case turns on: who is waiting on whom, and who may do something about it.

V1 checkout sheet for Sakura Garden: a Dine in, Table 12 header and Group Chat pill above delivery details, a split method block with Each pays their own selected, Split evenly and One bill below it, an itemized bill for You at $46.25, totals of $200, and a Proceed to payment button. — V1 checkout, “3E · After · Bill · Each pays own”Three modes blurred into a single sheet.

May to September 2026Two decisions from the same night I would make again: per-dish splitting cut, and a role rule where the leader sees the split control and guests see only what they owe.

Swipe sideways to see the whole diagram

“…we have to wait until every dyner in the dining session pays their part… I think we might need a UI for that showing who has already paid their part and who we’re still waiting for.”Engineer · handoff review thread 515

03Twelve defects, one diagnosis: a missing state model

~9 in 10

of payments since launch came from a party of one.

Production analytics · since 2026-06-25

100%

of paying sessions to date had a single payer.

Production analytics · since 2026-06-25

The second number needs care: one bill legitimately has a single payer, so this is not evidence that splitting was rejected. Solo is today’s product. The incident and the weeks after it produced twelve defects; eight touched money, order state, or left a user stuck with no recovery.

Defects, grouped by what each one lackedListed as bugs they look unrelated. Grouped, they collapse into one sentence: the system knew a state the interface refused to admit.

Swipe sideways to see the whole diagram

“The order was accepted into a closed store and then fulfilled as if it were immediate.”Root-cause note, July 2026

Getting from symptoms to diagnosis was not a solo act. I handed the shipped flows and the incident record to AI and asked it to enumerate what was broken and which questions only the team could answer. Resolved questions became states, rules, or screens; unresolved ones stayed visible with an owner.

Open question	Why it mattered	Decision / design response	Status
◆ Which system is the source of truth for order state?	POS said “Paid” while the app said cancelled	Cancellation carried in the POS status field, never in a note (PM + engineering)	Decided · implementation in V2
◆ What does “cancel” mean once food is in production?	The button promised what the kitchen couldn’t deliver	Free within 15 seconds of ordering, a window modeled on the better delivery apps’ undo patterns, then an escalation ladder: call the store, then request a refund (PM + design)	Designed
◆ Can an order be accepted into a closed store?	Fulfilled as immediate at 9:48 for a noon opening	Scheduled state surfaced in the session pill; per-merchant hours configured (design + ops)	Designed · config with ops
◆ What does a disabled pay button tell the user?	The merchant was stuck with no instruction	The button states its missing prerequisite (design)	Designed
◆ Who hears about a cancellation when staff lack portal access?	“My employees don’t have access to the portal”	Owner: PM + ops	Still open

◆ Surfaced on the AI-generated defect and decision board of July 24 to 27, 2026, built from the incident record I supplied; every decision on it was made by the team.

Swipe sideways to see the whole table

Part two

One order, four people, and a clock

States say what the order is doing. A group order has to answer a second question at every state: who may act on it, and when. What follows is how that question was taken apart, one person at a time.

04Four people, eighteen moments, three ways to pay

Drawn naively, a group checkout is a grid: three ways to pay, five points of view, twenty states after checkout. About three hundred screens. That is why the first version drew one.

Mode

Invite

Join

Add items

Check out

Pay

Cover

Deadline

Address

Last payment

Order sent

Kitchen

Courier

Delivered

Refund

Sold out

Dropped

Leaving

Host, group lead

Guest

Assignee

Payer

Receiver

Restaurant

Courier

Roles by moment, group deliveryRows are the people who can touch the order; columns are its moments from invite to receipt. Every filled cell is a “may I?” that needed an answer. Three of the seven rows never see a screen: the receiver, the restaurant and the courier get states and pushes instead.

Swipe sideways to see the whole diagram

I did not attack the grid in the order the product would. Solo checkout came first, because every group state clones from it. Then group pickup and delivery as a pair, since they share one lifecycle up to the kitchen. Dine-in, with the most edge cases and the most to differentiate, was designed last on what the simpler two taught.

Among the 12 delivery apps I reviewed before the rebuild, none settled per person on the order itself, so the rights in this grid had no pattern to borrow.

05Three promises, one answer surface

Each pays their own, split evenly, one bill: three different promises about money, locks and fallbacks, so each was drawn in full instead of branched off a shared sheet. This section is the V2 surface up close.

Group delivery at Sakura Garden on the Menu tab: a roster of four with none ready yet, and recommended dishes such as spring rolls from $9.75 and avocado toast from $12.35. — The four screens on the cover, in fullMenu, cart, cover picker and payer consent: the surface a group lives in before the order is sent. The next three sections zoom into each.

Group cart: six items, group subtotal $62.34, Tom and Carl paid, Raja waiting for payment, you not checked out; your items $17.09. — The four screens on the cover, in fullMenu, cart, cover picker and payer consent: the surface a group lives in before the order is sent. The next three sections zoom into each.

How are you paying sheet: Each pays their own, itemized per person; Split evenly, equal shares set when the order closes; One Bill, one person pays the whole bill. Subtitle: locks when the first person checks out.

Same rules, different promises

The host picks how the group pays, and the choice locks the moment the first person checks out. Everyone still checks out their own items. What differs is when you pay, what you pay, and what finally sends the order to the kitchen.

	A · Each pays their own	B · Split evenly	C · One bill
Who sets the mode	The host, before anyone checks out. It locks when the first person checks out.
Checking out	Everyone checks out their own items, in every mode.
When you pay	Right after you check out	After everyone has checked out; the last checkout fixes the per-head	Never, unless you are the payer
What you pay	Your items, plus your share of tax, fee and tip: $21.71	The group total divided by heads: $20.20	$0.00; the payer pays $80.79
What sends the order	The last person’s payment	The last per-head payment	The payer’s single payment
If someone covers you	They take your items, tax and fee share; you pay $0	They take your per-head	Not needed: one card already
If the group falls apart	Money returns in the proportion it was collected.

Three promises, one rulebookThree of the seven rules are identical across modes. The other four are the promises each mode makes about money, and each promise is a decision about who waits for whom.

Swipe sideways to see the whole table

Payment successful sheet: your $21.71 share is paid and the order waits for the rest of the group before it is placed. — Lanes A, B and COne four-person delivery order under three promises.

Split evenly after everyone has checked out: your share $20.20, the $80.79 order divided by four people, fee and courier tip included. — Lanes A, B and COne four-person delivery order under three promises.

06Every row is a person

The roster and the cart show one word per person, and that word decides what everyone else may do to them. Taking each role apart meant writing, for every person, what they see, what they may do, and what they may not.

Group cart, each pays their own: six items, group subtotal $62.34, Tom and Carl paid, you not checked out, Raja waiting for payment; your items $17.09, with fees, tax and tip at checkout.

Funding state, made visible per person

One cart, two lenses. The You / Group toggle keeps your bill and the group’s bill from blurring into each other.
Status lives on people, not in copy. Paid, waiting, not checked out: each name carries its own state.
No number that will change. The cart shows your items, $17.09. Fees, tax and tip arrive at checkout, once the group and the address fix them.

Host, group lead

SEES: The whole group: every cart, every status, the deadline.
MAY: Pick how the group pays, invite, set the deadline, name who receives it, remove someone.
MAY NOT: Override another person’s address edit, or change the mode once anyone has checked out.

Guest

SEES: Their own cart and subtotal; other carts read-only.
MAY: Add their own items, check out, cover someone, volunteer to pay for everyone.
MAY NOT: Edit anyone else’s items, or switch how the group pays.

Assignee

SEES: A question: “Cover this order?” with the stakes on the sheet.
MAY: Accept, or pass; if they pass, the host stays the payer.
MAY NOT: Be made the payer without answering.

Payer

SEES: The only checkout in the group; the order sends the moment they pay.
MAY: Pay for everyone, or pass the role back.
MAY NOT: Pay before everyone has submitted.

Receiver

SEES: Two pushes: nearly there, and arrived.
MAY: Hand over at the door.
MAY NOT: Nothing to decide; the host named them.

The restaurant and the courier never see a screen of this flow. They get one funded order, states and pushes.

Same gesture, two menusThe lead’s profile sheet carries “Remove from session”; everyone else’s carries “View profile” only. The right to remove someone is drawn into the gesture, not into a settings page.

Swipe sideways to see both

Mode sheet as the host sees it: Each pays their own, set by the host, with a Switch the split method link. — Same sheet, one extra linkBoth copies read “Set by the host”. Only the host’s copy offers “Switch the split method”. Anyone may volunteer to pay for everyone; only the host may change the promise.

The same mode sheet as a guest sees it, without the switch link. — Same sheet, one extra linkBoth copies read “Set by the host”. Only the host’s copy offers “Switch the split method”. Anyone may volunteer to pay for everyone; only the host may change the promise.

Push notification: 3 of 4 have checked out. Waiting on Raja Kunal · $80.79 total. — Same order, a different message for each personFourteen pushes, each written for the one person who can act on it: the host hears who is missing, the person covered hears they owe nothing, and only the payer affected hears about a refund.

Push notification: Tom covered your share. Your $19.71 is on Tom · nothing to pay. — Same order, a different message for each personFourteen pushes, each written for the one person who can act on it: the host hears who is missing, the person covered hears they owe nothing, and only the payer affected hears about a refund.

07When one person stalls, everyone gets the tools

The deadline is the moment rights matter most. One person has not checked out; six are hungry. The first decision gave the host the tools. The second gave them to everyone.

FigJam decision card: override on a non-payer, extend for the lead, cover for anyone, drop for the lead. — The host decides. The recommendation that set it already carried the doubt: “without drop, one unresponsive person kills lunch for six.”

Per-person blocker sheet, waiting on Raja: nudge them to finish, give them more time, drop their items, or check out and pay for their cart. — Extend, cover their share, or drop their items: open to every member. The host had become the single point of failure the tools were meant to remove.

Group delivery Session Home after the deadline: Raja Kunal didn’t check out, with buttons Choose what to do and Contact Raja, and a roster of four with Raja marked waiting.

Complex state, translated into plain language

The system says GB-BLOCKED. The screen says “Raja Kunal didn’t check out.” Same state, human words.
Role tags answer who is who. Group lead and waiting sit on the roster, not in settings.
The blocker is named, and it is actionable. Choose what to do (extend, cover his share, or drop his items) or contact Raja. Anyone at the table can resolve it; nobody waits on the host.

Waiting has two reasons and two remedies. Not checked out gets a nudge and more time. Checked out but not paid can be covered. The choice was not which tools to offer; it was who may use them. A group that can only be unblocked by one person is a group that stalls when that person is busy.

Group delivery Session Home while the group waits: three of four ready, Raja Kunal marked Waiting on the roster, and a line reading Raja has not checked out. — The other side of waitingBefore the deadline, the same screen tells everyone who is late, and offers a nudge, not a threat.

08Help me, cover for others: consent runs both ways

Covering moves money from one person to another, in both directions: someone picks up your share, or the lead asks you to carry the whole order. Each direction needed its own answer to one question: who has to say yes?

Who are you covering sheet, tax and delivery included, tip at checkout: your own share, $19.71, greyed out; Raja Kunal available to cover, checked out but not paid, $12.36 selected; Carl Motta at $19.11 and Tom Davis at $25.61 unable to cover because they have paid; total covered $32.07.

Cover for others: the picker decides who is eligible

Your own share is already in. The picker opens with you selected and locked; covering someone is something you add to your own payment, not instead of it.
Only people who have checked out and not paid. Someone who has paid needs nothing; someone who has not checked out has no amount yet; someone already covered is spoken for.
The amount is exact. Items, tax share and fee share, never the tip. Covering Raja is $12.36.

Alert: Tom is covering your share. Your $19.71 is on Tom. You have nothing left to pay.

Alert: Tom is no longer covering your share. You now pay $19.71 instead of $0, with buttons Review the amount and Not now.

Being covered: told by default, free to refuse

The covered person is informed, not interrogated. A push and a notice, both ending the same way: nothing left to pay. Accepting is the default because refusing a gift is rare.
Refusing exists, quietly. It is there for the edge case and drawn to feel like one, so the common path stays one tap.
A cover can be taken back. Until the order is sent, the amount returns and the person authorises it again.

One bill, three screens

The board annotates every one-bill frame with who sees it. Three people, one order, three different questions on screen.

Cover this order sheet: Tom picked you, one bill is on, order so far $80.79, 6 items, 4 people, your card; buttons Cover for the group and Not this time. — Consent, not assignment. When the group lead picks you to pay for the whole order, it arrives as a question, and you can decline.

You’re the payer sheet: confirmed, the order sends as soon as you pay and everyone else only has to check out; order so far $80.79, 6 items, 4 people. — Consent, not assignment. When the group lead picks you to pay for the whole order, it arrives as a question, and you can decline.

09Money moves only with consent

Three rules about money were rewritten in one week of September, each time because a simpler rule had put one person in charge of everyone’s card.

Amount changed sheet: Tom dropped Raja and every share changed; split three ways, your share goes from $20.20 to $22.68, up $2.48, and the $20.20 hold is released. — **A higher share needs a new yes.** When the address changes or someone drops, anyone whose share goes up re-authorises the new amount, and the old hold is released.

Alert: delivery address changed. Tom moved the delivery back, the delivery fee is back to $1.00 per person, and your share is down from $22.71 to $21.71; no new payment authorization is needed. Buttons Got it and See delivery address. — **A higher share needs a new yes.** When the address changes or someone drops, anyone whose share goes up re-authorises the new amount, and the old hold is released.

SEP 2No address change once the order is placed.Simple, and a dead end: one host away from a stuck order.
SEP 4Anyone may edit the address until the order is sent; a higher share must be re-authorised, with no “not now”.A product decision, not the host’s: the team gave the host no veto.
SEP 8Only a share that goes up asks for a new yes; equal or lower is told, not asked.A capture can never exceed its hold. Asking for consent you do not need is noise.
SEP 9The address freezes for the fifteen seconds after the last payment starts; only that payer can stop it.Two people editing at once had to have one answer: the last write wins until the send begins.

Four rules in seven daysEach rewrite replaced a rule that was easier to build with one that was fairer to the person paying.

Not every rule rests on the same kind of evidence.

Decision	Rests on
Re-authorise when a share goes up; confirm when it doesn’t	Team policy · design decisionRe-authorisation set at the September product meeting; the confirm-only exception is a design call
Refunds proportional to collection	Team policy · sign-off pendingDesigner rule; final say with PM, ops and finance
Privacy by default · the weak host · SessionHome vocabulary	Design hypotheses · still to validateNo usability session on record

Swipe sideways to see the whole table

10Three hundred screens became twenty states and ten pointers

The grid in section 04 is real, but it was never drawn cell by cell. Five decisions collapsed it, and the board records each in its own words.

Group delivery, after checkoutEach screen is the solo order status with the group’s roster added, so every state is defined once. Only the status line and the actions change. Pickup shares every state up to the kitchen. A sold-out item is now removed and refunded to whoever paid for it: the refund is a fact about the order, not a state.

A solo backbone, cloned. Every group state starts as the solo state with the roster added.
Ten pointers instead of ten screens. “SAME SCREEN, NOT COPIED HERE”, with the mode difference written inline: A waits on payment, B on checkout, C has no blocker.
One view for host and guests. The courier tail, the map and the contact are identical for everyone; hiding is a later decision, not a second screen.
Once placed, a group order is a single order. Eleven of fifteen detail screens needed no group variant.
Every frame names its audience. “The payer sees this”, “the assignee sees this”: the right is written on the artboard, where engineering reads it.

The model’s first test

When delivery needed its own group flow, the model was reused rather than redrawn. Pickup and delivery are the same flow until the food is ready, so screens and state keys carried over unchanged up to the kitchen. Four things changed: the address became a session setting, “who receives” replaced “who collects,” a courier tail replaced the hold window, and the delivery fee and courier tip had to be split.

Group pickup Session Home for the same four people: status and roster, with the pickup address and a Pick-up chip. — Deliver-to row replaces the pickup address · Delivery replaces Pick-up

Group delivery Session Home for the same four people: status and roster, with a Deliver to row and a Delivery chip. — Deliver-to row replaces the pickup address · Delivery replaces Pick-up

Lane A of the delivery board, each pays their own: one row of screens for the host and one for everyone else, from choosing how to pay to paying, each group of frames titled on the board. — One lane of the delivery board: each pays their own, one row per roleEvery screen a role sees, from choosing how to pay to the receipt, with fee and tip rows on every frame that shows money.

Swipe sideways to see the whole diagram

Part three

The second handoff

The first handoff optimized for shipping; the second made the definitions explicit, and says plainly what is validated so far.

11The second handoff: what was compressed, and what is validated

AI worked in two roles here: a research assistant on the incident, and an executor on the board. In both, I checked its output against primary sources, and the decisions stayed with me and the team.

The conversion itself was AI-executed. I set the rule: reuse what exists, and flag anything that needs a redraw for me to decide. An agent working in Figma converted 110 text layers, built four frames from existing shells and added fee and tip rows to 57 more. It drafted six open decisions with recommendations; I overrode one, set one myself and accepted four. My review that afternoon caught its biggest mistake: session screens built on an outdated base, which we then rebuilt.

Money needed one more rule. The same pre-tax slip had appeared on four AI-built screens, each caught in review, one at a time. The fix was structural: one fixture that every figure on every screen derives from.

Canonical fixture

You: $17.09 + $1.62 tax
Tom Davis: $21.00 + $1.61
Carl Motta: $14.50 + $1.61
Raja Kunal: $9.75 + $1.61
Delivery fee: $4.00, $1.00 each
Courier tip: $2.00, at each payer’s checkout
Group: $80.79
Split evenly: $20.20 each

So far	Status
Order-state source of truth	Decided · implementation in V2
Cancellation policy and ladder	Designed · not yet implemented
Refund rules	Proportional refunds decided by design · fault-based refunds pending with PM, ops and finance
Prototype	Solo happy path walkable end to end; group lanes A/B/C wired for pickup and delivery; group scenarios not yet validated with users
Measurement	Tracking plan agreed: the definition of “how we’ll know”

Swipe sideways to see the whole table

Results · to follow

The V2 design is delivered to engineering. Production results will be added after release.

12Take every role apart before you draw

A group order looks like one screen with a split control. It is a table of rights: for every person, at every moment, what they see, what they may do, what they may not, and what everyone else expects of them. Write that table first, and the combinations that look infinite collapse on their own.

The rest is the habit the first launch taught me. Know exactly what you cut for speed and write it down while you remember why. Repay it in the very next version. And let production evidence replace the assumptions a team cannot argue itself out of.

Guest

Check outChecks out their own items

DeadlineMay nudge, cover, or drop

Last paymentSees the freeze; cannot edit

Payer

Check outSees the only checkout

DeadlineSame tools, plus pay for a cart

Last paymentThe only one who can stop the send

The table, in six cellsGuest and payer at checkout, deadline and the last payment. Each cell is one decision this case made.

MORE WORK

Dynery

•