Design review
A fixed-scope read of the intended money model and the current implementation, ending in a written design with the failure cases enumerated. Cheapest before you build; still worth it after.
Stripe Connect architecture for platforms that pay other people.
Moving money between three parties is a different problem from charging a card, and it is usually discovered late — when the first payout is wrong, the first refund splits badly, or the first onboarding review stalls. We design that layer before it becomes a rewrite.
- Engagement model
- Design review, build sprint, or retainer
- Service area
- United States
- Response time
- Two business days
When this is the right call
The payments code has become the part nobody wants to touch.
You are about to pick a Connect account type
It is the decision with the longest tail: it sets who owns onboarding, who carries liability, who handles disputes, and what the dashboard looks like. Changing it later means migrating live accounts.
Refunds and disputes split badly
A partial refund after the seller has been paid out is where most marketplace payment models first break, and where the manual reconciliation starts.
Onboarding is losing sellers
Verification requirements arrive mid-flow, the UI cannot explain them, and supply drops out at exactly the point it was hardest to acquire.
What the engagement covers
The money model first, then the code that implements it.
Split payouts
Who is charged, who is paid, who carries the fee, and what happens on refund, partial refund, dispute, and cancellation. Written down as a model with the edge cases named before any of it is built — because these are the cases that produce support tickets and accounting drift rather than clean failures.
Marketplace onboarding flows
Account type chosen against the liability and control you actually want, and a verification flow that tells a seller what is needed and why. Onboarding is a supply funnel, not a form, and it deserves the same care as a checkout.
Compliance-aware routing
Routing that respects where the parties are and what each leg of the transaction is permitted to do, rather than discovering the constraint when a payout is held.
Webhooks and state
Idempotent handling, replay tolerance, and a payment state machine your own system owns rather than inferring from the provider. Webhooks arrive twice, out of order, and occasionally not at all; a design that assumes otherwise fails quietly and in production.
How it runs
Build sprint
Implementation with your team — routing, onboarding, webhook handling, and the tests that cover the refund and dispute paths people usually leave until an incident.
Retainer
Ongoing review as you add geographies, payout methods, or a second seller type — each of which reopens the money model whether or not anyone reopens the design.
Why us
We operate a two-sided marketplace, not just advice about one.
In-house venture
Imerzn™
An experience marketplace built end to end — host onboarding through booking, payments, and payouts on both sides of the market. Every failure case on this page is one we carry ourselves rather than one we read about.
imerzn.com →Track record
Principal architect, payments
High-throughput payment systems and real-time transaction pipelines, plus lead and architect work on tax engines at Amazon spanning global, state, and federal jurisdictions — the adjacent problem most payment models discover second.
Full track record →Questions we get
We have already built on Connect. Too late?
No, and this is the common case. A review that names which parts are load-bearing and which can be changed without migrating accounts is usually worth more after a first implementation than before one.
Do you only work with Stripe?
It is where most of this work lands and where we run our own platform, so it is where we are fastest. The money model — who is charged, who is paid, what happens on reversal — is provider-independent.
Can you advise on our compliance obligations?
We design systems that respect the constraints, and we will flag where a decision has regulatory weight. We are engineers, not your counsel, and the line is worth keeping clear.
Who writes the code?
Your team, with us — in your repository, in your style, reviewed by your people. This is the layer you least want to be unable to maintain yourselves.
Describe who gets paid.
Tell us the parties, the direction the money moves, and what happens on a refund. That is usually enough for us to say whether this is a design conversation or a build. We reply within two business days.