Method runs the whole customer relationship — contacts, pipeline, estimates, invoices. But the moment money actually moved, the experience left the platform. Payments ran through a bolted-on third-party gateway with its own setup, its own dashboard, and its own support queue.

The invoice lived in Method. The payment lived somewhere else. The problem was never “we lack payments” — it was that we didn’t own them. Ten gateways in the picker, and per transaction exactly one margin earner: whichever one the merchant happened to choose. The software doing the work captured none of the money passing through it.

I studied two markets before designing anything: how vertical platforms embed payments into an existing base (HubSpot, Keap, Jobber, QuickBooks, Zoho) and how payment-native products design the payment layer itself (Stripe, Square, Adyen, Braintree, GoCardless). One taught adoption; the other set the craft bar. Alongside it: 14 merchant interviews across four situations, payments-tagged support tickets, and shadowed sales and CS calls.

The pipeline runs competitor research → flow options → heuristic scoring → diagrams → PRD and user stories, parameterised by industry, feature and source domains. The one thing I added was a verification pass — a second agent whose only job is to refute. Two independent sources or the claim doesn’t ship. It caught a wrong dispute fee in my own notes: $25, when Stripe charges $15 and Square charges nothing. That’s why I trust the rest of the report.

Three checkpoints stay mine — the competitor list, the axes of comparison, and the synthesis. Nothing moves to the next stage until I’ve signed it off.

Same product, five different entrances into five different lives. The largest and most reachable was the 84% — existing users invoicing in Method with no gateway at all. The revenue segment was the smallest: high-volume merchants doing $50K+ a month, who get direct outreach and a rate conversation rather than a prompt.

The launch-date argument was the wrong argument. I reframed it as an exposure sequence: five rungs, each opening only after the last one held, each with a different audience and a different enablement bar — so the launch of a money product never became a money incident.

Building processing from scratch meant owning PCI compliance, KYC, fraud and disputes — years of work that isn’t Method’s craft. Partnering meant choosing the platform whose embedded surface we’d live inside. We ran a structured bake-off between Stripe and a US-focused challenger on compliance coverage, embedded component maturity, pricing economics, and scale.

Where users act on regulated data, compliance should sit with the platform certified to hold it. Where users read, the experience must be unmistakably Method. Two embedded Stripe surfaces made the cut — KYC/KYB onboarding and card checkout — because both carry real liability and both could be themed to Method. Everything else is Method’s own UI over Stripe’s APIs.

The same principle settled the brand question. I pushed for white-label — Method Pay as Method’s product, not “Powered by Stripe” — with HubSpot’s adoption data as the evidence. The nuance that won it wasn’t binary, it was placement: disclose Stripe at the KYC and bank moments, where a name regulators recognise is the reassurance.

The tints are the argument: violet steps live inside Stripe’s certified components, blue steps are ours over the APIs. Note the “Needs information” loop in the application flow — it loops back, it never dead-ends.

A regulated identity check and the biggest drop-off in the funnel. The old world sent merchants to a gateway’s site and hoped they came back. I embedded Stripe’s onboarding component in Method, themed to our design system, and wrapped it in a status ladder the merchant can always see. The wait is the worst part of any application, so I made the wait legible: Processing → Needs information → In review → Approved, with Declined routed to a human team instead of a dead end.

Nothing switches off while they apply. The old gateway keeps running on parallel rails, and the approved screen still links back to it — merchants switch when they see it working. We went first, moving Method’s own billing across before asking anyone else.

Payments config lived in Settings — findable if you went looking, but nobody goes looking. Merchants don’t wake up wanting to configure payments; they wake up wanting to get paid. So usage has a home, setup doesn’t. Payments keeps its page for watching money move. Setup meets merchants in the work: on the Invoices hub beside what’s owed, and on the invoice itself, where Payment collection makes the rail a per-invoice choice. Graded later, the invoice-flow prompt converted about 3× the settings page.

A quick win alongside it: status pills weren’t a Method component, so teams had been improvising them. I audited the variants, standardised the states so invoices and payments share one vocabulary, and contributed the component back to the system.

Merchants don’t think in “charges” — they think “did the Hendersons pay, and what did it cost me?” The old gateway answered in processor-speak, in someone else’s dashboard. This is a custom Method surface: payments, refunds and disputes in one list with real-time status, filter and search by customer, and a detail view that shows the money honestly — gross → application fee → processing fee → net. Showing our own fee plainly is a trust decision, not an accident.

The most emotionally loaded question in payments is about the payout. With a bolt-on gateway, merchants logged into a processor’s site to find their own money. Here every payout opens up: the balance separates what’s spendable from what’s still settling, and any deposit traces back to the payments and refunds behind it. A merchant who can answer “why is this one short?” doesn’t need to open a ticket — and the itemised decomposition is what accountants actually need at month-end.

A refund carries information a processor never sees: why it happened, which lines came back, and whether the stock can be sold again. So the modal asks — partial or full, a business reason, and a stock outcome: returned to stock, written off, or not returned. A processor structurally can’t ask that question, because it doesn’t own the order. That’s the bundled-CRM argument made concrete.

Card refunds take days to reach a statement, so I designed the waiting too: a pending state, an arrival estimate the moment you hit refund, and email copy telling the customer it landed. The problem was never speed — it was uncertainty. “Where’s my refund” tickets became self-serve.

Miss the response window and the money is gone for good; once you’ve responded there’s nothing to do for weeks. So it lives in a strip that empties out, sorted by deadline, turning red three days out rather than when it’s already late. Skip is first-class — forcing a decision when you’re missing a document produces bad decisions. And Accept shows its price: “$230 debited” against “3 items ready.” Sometimes accepting is the cheaper call, and it should read like the business decision it is.

Three rungs, each de-risking the next: proof of life (does real money move end to end?), proof of adoption (do merchants choose it, use it, and stay?), then proof of impact. You don’t get to argue revenue until merchants have voted with usage.

It was measurable because it was instrumented before launch, not after. I co-authored the Amplitude tracking dictionary with the PM and analyst, and the rule was to instrument the state machine, not pageviews — every event mirrors a state I designed, carrying entry point, segment and current gateway as properties. Two of the secondary metrics were deliberate counter-metrics: switchback rate, and support contacts per 100 payments. Every headline number went up, so I wanted at least two that could have gone against me.

All three were invisible in aggregate. They surfaced because the events were named after the states, so each one pointed at something specific we could go change — two drop-offs sitting in a transition rather than on a screen, and one ceiling on the entry point I’d already called the winner. The screens tested fine in isolation.