Chapter 5 · Foundations

The platform's relationship to money

Whether the payment lands in your account or your tenant's decides your architecture, your liability and whether you need a licence. It is the earliest decision and the hardest to undo.

6 min read

A platform where tenants sell to their own customers has to answer one question before any code exists: when a customer pays, whose account does the money land in?

There are two answers and they are not variations on a theme.

The two shapes

Shape A is simpler to build and is the one most people draw first. You take the payment, you record what you owe, you pay out on a schedule. It is also, in most jurisdictions, receiving and transmitting other people's money — which is a regulated activity with licensing, capital and audit requirements attached.

Shape B never puts tenant funds under your control. The charge is created on the tenant's own account, settles to the tenant's own balance, and your fee is deducted from that transaction at the moment it is made.

If you cannot confidently say which of those two you are building, you are building the first one, because the first one is what happens by default when a charge is created with your own API key.

Why this is not a thing to decide later

The decision reaches into places that look unrelated:

	Platform collects	Tenant collects
Who appears on the cardholder's statement	You	The tenant
Who handles a chargeback	You	The tenant
Who owes the customer a refund	You	The tenant
Who is liable for a negative balance	You	The tenant
Who needs identity verification	You	Each tenant
What a tenant's payout schedule is	Your business decision	Their setting
Whether you hold a float	Yes	No
Whether you can be a money transmitter	Likely	No

Changing from A to B after launch is not a refactor. Every tenant has to complete identity verification before they can be paid, which means asking your entire existing customer base to submit documents, and the ones who do not comply cannot transact. Refund and dispute history does not transfer. The descriptor on every future statement changes, which generates its own disputes from confused cardholders.

What this means for the build

Shape B is what this series builds. The concrete consequences, each one a later section:

// The shape of every charge in this system. Note what is NOT here: no
// transfer, no payout, no ledger of what we owe the tenant — because we never
// owe them anything. The split happens inside the charge.
const paymentIntent = await stripe.paymentIntents.create(
  {
    amount: 49_900,                       // what the customer pays, in cents
    currency: 'cad',
    application_fee_amount: 2_495,        // our 5% — deducted at the source
    automatic_payment_methods: { enabled: true },
  },
  {
    stripeAccount: tenant.connectAccountId, // whose account this charge is on
  },
)

Two lines carry the whole architecture. stripeAccount says the charge belongs to the tenant. application_fee_amount says our fee comes out of it. No money moves through an account we own, so there is nothing to reconcile and nothing to hold.

The cost of that simplicity is paid at onboarding. A tenant cannot accept a single payment until they have completed identity verification, which is Section 5 — and the half-onboarded tenant who signed up, started verification and abandoned it is a real state your product must handle rather than an edge case.

The questions to answer before writing code

Does the platform ever need to hold funds? Escrow, delayed release, "we pay the tenant on the 15th" — all of these are shape A. Decide if you truly need them; usually the business reason evaporates when the licensing cost is named.
Whose name is on the statement? This decides your support volume more than any other single choice. A cardholder who does not recognise a descriptor files a dispute.
Who eats a chargeback? If the answer is "the tenant", the tenant must be the merchant of record, which means shape B.
Can a tenant go negative? Refunds issued after a payout can leave a tenant's balance below zero. Whoever is liable for that gap needs to be named now, in writing.
What happens when a tenant's verification is rejected? They exist as a tenant, they can use the product, and they cannot be paid. That is a product state and it needs a screen.

The honest limitation of shape B

It is not free of trade-offs, and it is worth stating them rather than selling the model:

You cannot see full card details or control the customer relationship. The tenant's customers are the tenant's customers. Building a cross-tenant customer profile is substantially harder.
Fees are the tenant's problem and your explanation. Processing fees come out of the tenant's settlement, so your support team will field questions about numbers set by someone else.
Reporting is split. Your revenue is the sum of application fees; the tenant's revenue is on their account. Any report mixing them needs care, which is Chapter 123.
Onboarding friction is real. Identity verification loses a measurable share of signups between "created an account" and "can take money". That is the price of not being a money transmitter.

Key points

One question first: when a customer pays, whose account receives it? The two answers are different businesses, not different implementations.
Creating a charge with your own key means you collected the money. That is the default, and in most jurisdictions it is a regulated activity.
Shape B creates the charge on the tenant's account and deducts the platform fee from that same transaction, so no tenant funds ever sit under your control.
Migrating A → B after launch means every existing tenant must complete identity verification before they can transact, and statement descriptors change for every future payment.
Two parameters carry the architecture: stripeAccount and application_fee_amount.
The cost is onboarding. A tenant who abandoned verification is a real, common product state, not an edge case.
Answer five questions in writing first: do you hold funds, whose name is on the statement, who eats a chargeback, who covers a negative balance, and what a rejected tenant sees.

Next: What you are building — Meridian specified precisely enough to implement.