Home

About

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.

SessionHome · Group cart · Cover this orderThe V2 surfaces of the multi-party checkout.

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. V2 is in development.
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.

02The price of a six-week ship: we knowingly cut definition

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.

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 August 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.

Part two

States before screens

The question is no longer which screen broke, but which state went unadmitted. What follows is how the rebuild compressed the complexity.

04A strategic bet, sequenced by risk

Solo backbone first. Every group state clones from it.
Group pickup and delivery first, dine-in last. Pickup and delivery share a lifecycle, so they were designed as a pair; dine-in, the mode with the most edge cases and the most differentiation, is designed last, on what the simpler two teach.
Each stage earns the next with real multi-payer sessions and real cancel and refund cases. The criteria are not yet quantified; the order is.

Ramp-up, in the order the risk allowsGroup payment stayed the bet the company was founded on, with nine in ten payments still solo. The data changed how much risk to take, and in what order.

Swipe sideways to see the whole diagram

Own teardown of 12 delivery-category apps, July 2026, after the incident and before the rebuildAmong the 12 apps I reviewed, none settled per person on the order itself, so settlement had to be designed from first principles. The rest did not: we took DoorDash’s cancellation wording almost verbatim, and the undo patterns of the better delivery apps as the reference for our own 15-second free-cancel window.

Swipe sideways to see the whole diagram

Three modes, two lifecyclesV1’s blur had one source: a single payment model serving two different things. Each lifecycle got a state machine correct for it. Who can join also differs: anyone at the table mid-meal, versus only before the funding deadline.

Swipe sideways to see the whole diagram

Then the backbone: the single-user checkout rebuilt state by state, each frame named for its state, so a wrong solo state would not be copied down every group lane. Dozens of screen permutations collapsed into one backbone plus two group-only states.

“The checkout was rebuilt for single user first, because every checkout state clones from it.”Handoff-readiness report, 2026-07-28

Order status screen: Order received, estimated ready 6:35 PM, progress Received, Preparing, Ready, Picked up, with a note that you could back out until we sent this to the kitchen. — The solo state stripFour of the eleven states, chosen for the judgment they carry; the matrix in section 07 holds the full set. It carries the ladder the incident exposed: free cancellation inside fifteen seconds, a handoff to the store once the kitchen starts, then a different word, because once food exists “cancel” is no longer honest.

Order status screen in the Late state with a new estimated ready time. — The solo state stripFour of the eleven states, chosen for the judgment they carry; the matrix in section 07 holds the full set. It carries the ladder the incident exposed: free cancellation inside fifteen seconds, a handoff to the store once the kitchen starts, then a different word, because once food exists “cancel” is no longer honest.

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.

Lanes A, B and CThree promises about money, locks and fallbacks, drawn in full rather than branched from one sheet.

Swipe to see all three lanes

Group cart, each pays their own: six items, $62.34; You not checked out, Tom Davis the group lead paid, Carl Motta waiting for payment, Raja Kunal paid; your share $18.71; button Check out your cart.

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.
Your share stays honest. $18.71 with tax shown before tip, so nobody is surprised at the end.

Payer assignment sheet over the Sakura Garden group pickup: Cover this order? Tom picked you. One bill is on. Order so far $68.79, 6 items, 4 people. Buttons Cover for the group and Not this time; if you pass, the host stays the payer.

One bill is a transfer of responsibility

Consent, not assignment. Being picked as the payer is a question you can decline.
The stakes are on the sheet. Order so far, item count, head count and your card, before you accept.
The fallback is one line of microcopy. “If you pass, the host stays the payer.” No dead end either way.

SessionHome for a group pickup: 3 of 4 ready, roster with role tags Group lead, Payer and Waiting, a section titled Raja has not checked out, and a Waiting for Raja pill.

Complex state, translated into plain language

The system says GW-WAITING. The screen says “Waiting for Raja.” Same state, human words.
Role tags answer who can do what. Group lead, payer, waiting: visible on the roster, not buried in settings.
The blocker is named. “Raja has not checked out” tells the table exactly what has to happen next.

Before and after, at the same scale.

Top of the V1 checkout sheet: a Dine in, Table 12 header above delivery details and the split method block, all in one modal. — Dine-in header, delivery details and the split control in one modal.

Top of the V2 solo checkout: Your order, pick-up time, who is picking up, before-tip amount and tip chips. No group vocabulary anywhere. — The solo path shows no group vocabulary at all.

Roster detail: Dyners, 3 of 4 ready, avatars with status dots and role tags Group lead, Payer, Waiting. — Status on peopleA dot and a role tag per person, so state reads at a glance.

Cart detail: Carl Motta waiting for payment, Raja Kunal paid, then group totals. — Money next to namesEach person’s items and state sit together, so the bill explains itself.

Sheet detail: Cover for the group, Not this time, and the line If you pass, the host stays the payer. — The fallback in one lineDeclining is safe, and the sheet says who pays if you do.

06One bill, four audiences

The same state should not look the same to everyone. Permissions here are a cell-by-cell decision, not a settings page, and the board annotates them frame by frame: “the payer sees this,” “the assignee sees this.”

One bill

Payer sees

full checkout · funding progress · deadline

Guest sees

own items · what they owe

Restaurant sees

funded or not · fire time · cancel status

Courier sees

a real, funded, ready pickup

One bill, read four waysSame state, four different views.

One bill, read four ways

Swipe sideways to see the whole diagram

Not every rule rests on the same kind of evidence.

Decision	Rests on
Cancel lives in the POS status field	Merchant evidenceThe July incident
15-second free-cancel window, then the ladder	Design decision · team policyWritten on the frames for the PM to overrule
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

Two consumer decisions run deeper than the table.

Privacy is a default, not a toggle: carts and totals are hidden from everyone else. The host is deliberately weak, because “host” carries a responsibility nobody volunteered for; the first to arrive is told “You’re the first one here.”

On the merchant side the important fix was semantic: a cancellation belongs in the order’s status field, where the back office reads it, not in a note.

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.

07The second handoff: what the complexity was compressed into

Swipe sideways to see the whole diagram

The board carries an engineering-legible notation, readable without me in the room:

GAPfor what is not built

MODIFYfor solo screens awaiting group treatment

PARKEDfor retired designs kept with their dates

SAME-SCREENfor pointer stubs

builtfor what is done

Its entry frame is titled HOW TO READ THIS PAGE.

State matrix, post-payment, group: thirteen state keys from S1 Received through S11 Rest cancelled plus GW Waiting and GB Blocked, each mapped to a SessionHome screen, an order status screen and a note with the governing policy. — STATE MATRIX · post-payment · GROUP“Same 11 keys as single user, plus two the group needs on its own.” Blocked once the deadline passes, the host can extend, cover, drop or cancel.

One section of the design board: SessionHome post-payment states for a group, thirteen phone frames in a row each titled by its state, a second row of pre-payment states, and the state matrix table beside them. — One section of the board: SessionHome, thirteen post-payment states, each frame named for its stateThe whole board today: 311 frames, 47 built, 40 to modify for groups, 47 gaps, 61 retired designs kept with their dates, 91 wired prototype links, and a 47-event tracking plan.

AI helped organize the evidence, surface unresolved questions, and challenge selected flows. I verified its findings against primary sources, and the team either resolved each question or explicitly left it open.

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

Results · to follow

V2 is in development. Production results will be added after release.

08Cut for speed, write it down, repay it fast

Know exactly what you sacrifice for speed and write it down while you remember why. Repay it in the very next iteration, and let production evidence replace the assumptions a team cannot argue itself out of.

The ledger, end to endWhat was cut, where it was written down, and how the second version paid it back.

Swipe sideways to see the whole diagram

•

Made in Seattle with ❤️