Stripe Connect:
Assessing & Executing
Platform Payments

Determine all of the required platform fund flows, and who acts as merchant of record (whose name is on the transaction) for each distinct one: the platform, or the connected account. Because Connect allows for multiple fund flow patterns in a single Connect instance, a marketplace can be MoR for its booking fee while the sub-merchant is MoR for the service itself.

Refund and chargeback liability follows the merchant of record, and this decision also sets the customer-facing identity: statement descriptors, receipts, and dispute paperwork all carry the MoR's name. Because MoR constrains charge pattern, fee strategy, and regulatory posture, getting this right from the start is critically important.

• The team answers "who is merchant of record" with the platform's brand name and no mention of fund flows
• Requirements docs say disputes "will be handled by Stripe" with no liability assignment
• Statement descriptors appear nowhere in the requirements

For each fund flow, pick one of the three Connect charge patterns: direct charges (created on the connected account), destination charges (created on the platform, routed via transfer_data.destination), or separate charges and transfers (charge and payout fully decoupled). This is a per-flow decision, not a per-platform one, and mature platforms often run two or three patterns simultaneously.

The pattern determines fee mechanics, settlement timing, and who eats a loss. With direct charges, Stripe fees and dispute liability sit with the connected account by default; with destination and separate charges, the platform fronts the charge, owns refunds and disputes, and settles to sub-merchants on its own schedule. Settlement timing diverges too: destination charges move funds with the payment, while separate transfers can lag by days, which changes sub-merchant cash flow and your reconciliation model. Pick wrong and you either carry liability you never priced in, or you rebuild the fund flow mid-project.

• The architecture diagram shows one charge pattern with no per-flow analysis behind it
• Someone proposes "we'll just move money with transfers later" without modeling settlement lag
• Refund handling is absent from the flow diagrams entirely

Choose how platform revenue is taken: application fees attached to each charge, a negotiated revenue share, a markup on payment pricing where the platform pays Stripe and charges sub-merchants its own rate, or some blend. Then confirm the chosen mechanism is actually supported by the charge pattern selected for each flow.

Fee strategy and charge pattern are coupled. An application_fee_amount rides along on direct and destination charges, while separate charges and transfers express the platform's cut as the difference between charge and transfer amounts, which means reconciliation looks completely different in each case. Get this wrong and finance teams spend month-end manually tying platform revenue back to thousands of transactions. Fee opacity also burns trust: sub-merchants who cannot see what they are paying churn, and in some markets fee disclosure is not optional.

• The business model deck shows a take rate but no one can say which API parameter produces it
• Reconciliation is described as "we'll export from the Dashboard"
• Fee changes are assumed to be "just a config update" with no merchant communication plan

Determine where the platform sits on the spectrum from marketplace to payment facilitator, and how much money transmission exposure its fund flows create. Then define the KYC/KYB split: with Accounts v2, controller.requirement_collection decides whether Stripe or the platform collects onboarding requirements, while Stripe performs verification either way.

Holding or directing other people's money is regulated activity in essentially every market, and the licensing question is decided by what the fund flows actually do, not by what the pitch deck calls the company. Connect shifts settlement and verification onto Stripe's regulated infrastructure, which is exactly why fund flows must be designed so the platform never takes possession of funds outside it. A platform that batches payouts through its own bank account "temporarily" may have become an unlicensed money transmitter. Requirements also vary by region, so a posture that works in the launch market needs rechecking for every expansion market before, not after, the rollout.

• Requirements docs say compliance "will be solved by Stripe" with no specifics
• The payout design routes funds through a platform-owned bank account "for flexibility"
• Nobody on the client side owns sub-merchant offboarding or risk review

Connect no longer asks you to pick a bundled account type. With Accounts v2, controller properties split that old bundle into explicit choices: who gets dashboard access (controller.stripe_dashboard.type), who pays Stripe fees (controller.fees.payer), who carries liability for negative balances (controller.losses.payments), and who collects onboarding requirements (controller.requirement_collection). Alongside that sits the onboarding surface itself: Stripe-hosted onboarding, embedded components inside your own UI, or a fully API-driven flow you build and maintain.

These properties determine who eats the loss when a sub-merchant goes negative and who fields their support tickets, which is a commercial decision as much as a technical one. The onboarding choice swings build effort by an order of magnitude. Hosted onboarding ships in days; fully API-driven onboarding means you own KYC requirement changes across every region you operate in, forever. Embedded components sit in the middle: your branding and page, Stripe's compliance logic.

• The design doc still says "Express accounts" with no mention of controller properties, which usually means it was copied from a 2021 tutorial
• Nobody can answer "who pays when a sub-merchant disputes their way to a negative balance" without a meeting
• Onboarding is specced as fully API-driven "for control" but there is no plan for handling requirement changes per region

Build a Stripe-native payments service that no single front-end application owns. Web, mobile, internal admin tools, and whatever ships next all consume the same payment APIs from this one service. Inside it, keep two layers honest: the Stripe object is the immutable record of what actually happened to money, and an internal ledger tracks how your business allocates it.

A PaymentIntent never changes meaning, but your business's view of it does. A single payment can fragment across multiple purposes after the fact: part refunded, part reallocated to a different order line, part held back against a dispute. If you mutate your own payment records to reflect that, you lose the audit trail and reconciliation becomes more difficult and time consuming for every team that touches it. And if payment logic lives inside one app, the second app reimplements it slightly differently, and now finance reconciles two behaviors.

• The mobile app and the web app each create PaymentIntents with their own logic and their own metadata conventions
• Refunds are modeled by updating the original payment row instead of writing a new ledger entry
• "We'll add the ledger later" appears anywhere in the plan, because retrofitting one under live fund flows is a dual-system project of its own

Treat Stripe webhooks as the platform's source of truth for asynchronous state, and architect them as a pipeline, not an endpoint. The receiving layer does exactly three things: verify the signature, persist the raw event, acknowledge. Processing happens afterward, from storage, by consumers that can be replayed.

Payouts, disputes, account requirement changes, and most Connect lifecycle events arrive only as webhooks. If a handler throws halfway through and the raw event was never stored, that state transition is gone until someone notices the discrepancy in a finance report weeks later. Stripe delivers at least once and does not guarantee order, so any handler that assumes exactly-once, in-order delivery is a latent incident.

• Webhook handling lives in a controller with no storage behind it, so a deploy mid-burst means permanent data loss
• Handlers branch on event payload fields instead of re-fetching the object, then break when events arrive out of order
• There is no answer to "how do we recover the six hours the queue was down"

On a multi-seller platform, a single cart can contain items from multiple sellers, and depending on the charge model, each may require its own payment. The design question is how to confirm several payments in one customer gesture: typically a sequential confirmation flow built on a saved payment method, with explicit card-on-file consent collected once.

This is where Connect architecture becomes visible to actual customers. Get it wrong and the customer sees four bank notifications for one checkout, calls their bank, and you collect a dispute instead of a sale. The hardest part is not the happy path. It is payment 2 of 4 failing after payments 1 and 2 succeeded: what the customer sees, what gets retried, what gets reversed, and what the seller is told.

• The failure path for payment 3 of 5 is described as "we'll show an error", with no decision on the four other payments
• Card-on-file consent is implied by a checkbox in the footer rather than collected as an explicit step
• Each front-end team has its own multi-charge flow, so the same cart behaves differently on web and mobile

How your platform models, monitors, and remediates the verification lifecycle of every connected account. That means treating the requirements object (currently due, eventually due, past due) and capability statuses as first-class application state, not a one-time onboarding step.

A sub-merchant who sailed through signup can lose the ability to accept payments or receive payouts months later when a verification threshold trips and new requirements appear. If your platform is not watching account update events, the first you hear of it is an angry call about a frozen payout. Verification stalls are also a support problem: the seller stuck on "entity document" does not know what that is, and Stripe's terminology will not reach them unless you translate it.

• Onboarding was built as a single happy-path flow with no plan for accounts that go backwards
• Nobody can answer "how many of our live accounts have requirements currently due"
• Support tickets about frozen payouts are the monitoring system

How refunds and disputes behave for your charge pattern, and who carries the loss when a connected account cannot cover them. This is partly set by your controller configuration (specifically who is liable for losses) and partly by operational policy you have to write yourself.

A refund on a destination charge needs the transfer reversed and a decision about whether the application fee comes back too. A sub-merchant who refunds more than their balance goes negative, and someone fronts that money. On direct charges the connected account owns the dispute; on destination charges and separate charges and transfers, the platform does, including the evidence work and the loss if it goes against you. Get this wrong and your platform becomes an unsecured lender to its worst sellers.

• Nobody can say who eats the loss on a charged-back transaction for a seller who has churned
• Refunds are tested but transfer reversals are not
• The reserves conversation is scheduled for "after launch"

How you sequence sub-merchants from the old stack to the new one: cohort definitions, ordering, rollback criteria, and how long the dual-system period is allowed to last.

Every sub-merchant carries open obligations at switchover: pending payouts, open disputes, saved payment methods, in-flight refunds. Move them without an inventory of those obligations and money gets stranded or double-handled. Business calendars constrain you too: no seller wants to be replatformed the week before their peak season, so sequencing is a negotiation, not just an engineering schedule.

• The plan says "cutover weekend" for a platform with thousands of active sellers
• Rollback is described as "we'll handle it if it happens"
• Nobody has listed what each account carries with it at switchover

What reporting and reconciliation tooling ships with launch, not after it: payout-to-transaction tracing, platform revenue reporting, and the exception process when numbers do not tie out.

Finance teams close books monthly whether or not engineering built them the tools. Balance transactions are the reconciliation primitive: every charge, refund, fee, transfer, and adjustment produces one, and every payout is a set of them. If that mapping is not surfaced, finance rebuilds it by hand in spreadsheets, badly, every month. Platform revenue (application fees, any markup on processing) needs its own clean line, separate from sub-merchant funds you are merely routing.

• Reconciliation is a launch-week afterthought assigned to whoever is free
• Month-end close requires an engineer to write ad hoc queries
• Finance keeps a shadow spreadsheet because they do not trust the numbers in the product

Choose payout schedules per merchant segment (automatic versus manual, daily versus weekly or monthly with an anchor day), decide whether to offer instant payouts as a product, and define exactly what happens when a payout fails.

A sub-merchant who can't see when their money arrives files a ticket, and a platform with ten thousand sub-merchants cannot answer ten thousand tickets. Payout failures are not rare: bank accounts get closed, names mismatch, details get fat-fingered at onboarding. Without a remediation path, failed payouts pile up as balances Stripe will eventually return or escheat, and as merchants who churn.

• Failed payouts sit in a queue nobody owns and get discovered when the merchant complains
• "Where is my money" is a top-three ticket category
• Ops can pause a payout but nobody wrote down when they should

Decide how the platform monitors fraud and merchant risk in production: how Radar is configured and tuned for your charge pattern, what platform-level rules apply across connected accounts, and which account-health signals trigger human review.

If the platform is liable for losses, a single sub-merchant going bad (or being taken over) can generate chargebacks that exceed months of platform revenue. Even where Stripe carries more of the risk, dispute rates and merchant behavior reflect on the platform's standing and its merchants' ability to keep processing. Risk monitoring is not a launch task; fraud patterns show up after launch, when volume is real.

• Dispute rate is only checked when Stripe sends a warning
• A dormant account reactivates with 50x its old volume and nobody notices for a week
• The only intervention anyone knows is "disable the account"

Define the support model across platform, partner, and Stripe (who answers what, with what tools, at what tier) and write runbooks for the incidents you already know will recur.

The sub-merchant's "where is my money" ticket lands on your platform, not on Stripe, and a support agent who has to escalate to an engineer to answer it costs you twenty times what the ticket should. Operations without runbooks means every incident is solved from scratch by whoever is on call, and the quality of the answer depends on who that is.

• Support answers payout questions by asking an engineer to query the API
• The same incident type gets solved differently each time it occurs
• Ops staff have full Stripe dashboard access because the admin tooling never got built

Decide how the platform enters new markets: cross-border payouts from your existing entity versus establishing local entities, which countries come first, and what the per-country onboarding and settlement model looks like.

Capabilities, payment methods, and payout behavior all vary by country, and an architecture that assumed one market breaks in the next one. KYC requirements differ by country and entity type, so an onboarding flow tuned for one market can stall verification in another. FX costs are real money: who absorbs conversion (platform or sub-merchant) changes your margin and their perception of fairness.

• The roadmap says "launch in 12 countries this quarter" with one onboarding flow
• Nobody can say what a payout costs in the newest market
• Verification completion rates per country aren't measured, so stalled merchants look like churn