07.01 · Concept · Free
When the Money Is Not Yours
Describe how a platform's architecture differs from a shop's, and say who the merchant legally is once a third party is being paid.
Curated for this lesson1/3
Platforms, Payouts & the Agentic Money Path
Planning to build and monetize a creator platform with Stripe Connect
Directly targets creator-platform monetization with Stripe Connect, matching third-party payouts and platform architecture.
Platform payments are built around who legally sells and receives the money, not who owns the checkout UI. Once a third party provides the product or service, the system needs seller onboarding, verification, payout controls, liability allocation, and separate money movement instead of treating every payment as shop revenue.
What this lesson answers
- who is the merchant in platform payments
- shop payment architecture versus platform payments
- why platforms need connected seller accounts
Notes
A normal online shop is simple: the business selling the goods is also the merchant of record, so it takes the card payment, owes the customer the product, handles refunds, pays taxes where applicable, and receives the money. A platform is different because the software helps other people sell, earn, or provide services. The platform may control the user experience, but the money is economically going to a third party: a driver, creator, marketplace seller, contractor, or connected business.
The key mental model is that payment architecture follows legal responsibility, not just UI ownership. In a shop, there is one merchant account and one ledger: customer pays the shop, the shop keeps the proceeds. In a platform, there are at least three roles: the customer, the platform, and the connected seller or service provider. The system must decide who is the merchant for the transaction, who is being onboarded and verified, who receives settlement, who pays platform fees, and who is responsible for disputes, refunds, chargebacks, tax reporting, and prohibited-business checks.
The common misconception is: “If the customer pays through my website, then my company is the merchant.” That is often wrong. Hosting the checkout page, creating the payment intent, or taking an application fee does not automatically make the platform the legal seller. If a third party is providing the good or service and receiving the funds, the architecture usually needs connected accounts, seller onboarding, payout controls, and clear allocation of liability. Treating platform money like shop revenue can create accounting, compliance, and regulatory problems.
After this lesson, you should be able to look at a product idea and classify it as a shop or a platform. You should be able to say whether there is one seller or many, whether funds belong to your company or to third parties, and why payout systems need identity, compliance, balances, transfers, and dispute handling rather than just a checkout form and a database column called balance.
References
Common questions
- Does owning the checkout page make my company the merchant?
- No. The merchant is determined by the commercial and legal reality of the transaction, not just the page where payment happens. If another party provides the goods or service and is entitled to the proceeds, that party may need to be treated as the seller, with onboarding, verification, settlement, and liability handled accordingly.
- How is a platform payment system different from a shop?
- A shop normally sells on its own behalf and receives its own revenue. A platform coordinates payments between a customer and third-party sellers or service providers. That means the architecture must model multiple parties, route funds correctly, track fees separately, and handle disputes, refunds, compliance checks, and payouts for people outside the platform company.
- Why is a database balance not enough for platform payouts?
- A balance column can record an amount, but it does not solve the legal and operational work behind moving money owed to third parties. Platform payouts need verified recipients, controlled settlement timing, compliance screening, fee accounting, dispute handling, refund paths, and auditable transfers between the platform and connected sellers.