🏪 Marketplaces and collecting payments on behalf of third parties

Collecting payments on behalf of a third party

Collecting on behalf of third parties means that a platform receives the price a buyer pays for the benefit of a seller outside the platform. The platform holds the funds in its own accounts, keeps its commission, and pays the balance out to the seller. The money sits there for anywhere from a few hours to a few weeks, depending on the payout schedule. During that window, the platform holds money it does not own. Every jurisdiction that has legislated on payments treats this as a regulated activity, separate from running an online store.

• Who is the buyer's creditor? If it is the platform, the platform sells in its own name and an entirely different regime applies. If it is the seller, the platform is collecting for someone else.
• Who has authority to give instructions on the account holding the funds? The answer is in the bank mandate, not the commercial contract.
• What happens if the platform files for bankruptcy on a Tuesday morning? In a sound structure, sellers' funds stay out of the bankruptcy estate, because they were never on the balance sheet.

Collecting on behalf of third parties without a license is not a paperwork lapse. It is the unauthorized conduct of a regulated activity, a criminal offense in most jurisdictions. Account-holding banks end the relationship as soon as they discover the arrangement. For a platform that is already live, getting compliant then costs twice: once to rebuild the collection flow, and again to migrate the sellers already onboarded.

Four possible structures, and what each one shifts

A platform's structure is the legal position it takes between the third-party seller and the buyer when a payment is collected. Four structures are in use. The platform can sell in its own name, rely on an agency exemption, partner with a licensed platform payments provider, or apply for its own license. Most platforms use just one of them: partnering with a licensed provider. The options differ in time to launch, in cost, and in the exposure they create. They also shift different things: the payment license, tax liability, chargeback risk, and the customer relationship.

Safeguarding: one goal, six mechanisms

Safeguarding is how an institution ring-fences third-party funds from its own assets. It differs from regulatory capital, which absorbs operating losses but does not protect sellers' money. The goal is the same everywhere: if the institution fails, sellers' funds remain available to be returned to their owners. The rules, however, vary from country to country, and they dictate the treasury architecture of any group operating in several markets.

• Daily reconciliation: total seller balances must equal the safeguarded balance, every day. An unexplained difference is a compliance incident, not an accounting glitch.
• Deposit deadline: most regimes require funds to reach the protected account no later than the end of the business day after receipt. Delays are measured, documented, and penalized.
• Platform commission: it cannot stay commingled with safeguarded funds. The deduction must be identifiable, dated, and moved out of the account.
• Account-holding bank: safeguarding protects against the failure of the payment institution, not the failure of the bank holding the account. Splitting funds across two banks is a treasury decision, not a compliance one.

ORD-2026-84512   cart EUR 120.00   platform commission 12.5%

D+0  card payment collected       +120.00   safeguarded account
     - seller A (sneakers)         +72.00   seller A balance
     - seller B (accessories)      +33.00   seller B balance
     - platform commission         +15.00   platform balance
     check: 72 + 33 + 15 = 120.00  -> OK

D+2  seller A delivery confirmed
D+3  payout to seller A            -72.00   to verified IBAN
D+9  partial refund, seller B      -12.00   seller B balance: 33 -> 21
     commission reversed            -1.50   platform balance: 15 -> 13.50
D+10 payout to seller B            -21.00   to verified IBAN

D+70 chargeback, seller A share    -72.00   seller A balance: 0 -> -72.00
     -> amount owed by the seller, to recover from future sales
     -> if the seller stops selling: loss borne by the platform
        or the provider, depending on liability settings

Stripe Connect and Adyen for Platforms: two ways to scale platform payments

Stripe Connect and Adyen for Platforms are infrastructure products for platforms that collect payments on behalf of third-party sellers. Their data models differ. Stripe exposes connected accounts and charge types, while Adyen exposes a balance platform made up of account holders and balance accounts. The choice determines which entity holds a seller's balance, where a negative balance is charged, and how much development has to be redone if the platform switches providers.

Stripe Connect

A connected account is the object Stripe uses to represent a seller on a platform, and the platform creates one for each seller. Three settings then shape the rest of the integration: how the seller is onboarded, which dashboard the seller can access, and who is liable for negative balances. New integrations use the Accounts v2 API. Stripe offers three charge types, and the choice among them depends more on what is being sold than on the accounting treatment.

• Direct charges: the payment is collected directly on the connected account, and the platform takes an application fee. The customer transacts with the seller, often without knowing the platform exists. This is the model for commerce software.
• Destination charges: the payment is created on the platform's account, then immediately transferred to the designated connected account. The customer transacts with the platform. This is the model for services marketplaces.
• Separate charges and transfers: the charge is decoupled from the transfers, so a payment can be split among several sellers, or collected before the recipient is known. It is more flexible but heavier to operate: the platform has to monitor its own available balance.
• Negative balance liability: either the platform, which then handles risk monitoring and remediation flows, or Stripe, which handles risk signals and recovery. The second option requires integrating the embedded components for onboarding, account management, and notification banners.
• Regional constraint: unless the account is eligible for cross-border payouts, the platform and the connected account must be in the same region for destination charges or separate transfers. Any attempt outside that scope returns an error.

Adyen for Platforms

Adyen exposes a balance platform populated by account holders. Each account holder has one or more balance accounts and transfer instruments for moving money out. Payments are divided using splits, and business lines describe what the seller sells. Adyen onboards and verifies users, notifies the platform of the result, and blocks payouts until verification is complete. The platform remains the seller's point of contact. Because Adyen is licensed as a bank in the Netherlands, it holds seller balances without relying on a third-party bank.

Seller KYB: three overlapping obligations

Seller KYB is the verification of a business seller by the marketplace and by the institution holding the funds. It serves three distinct obligations, which come from three branches of law and are rarely handled by the same team. Anti-money laundering rules require identifying whoever receives the funds. Digital platform law requires tracing business sellers who sell remotely. Tax law requires collecting a national tax ID before any income is reported. The data these three regimes require overlaps by 80%. Their compliance deadlines, however, do not line up.

• Payout account changed just before a large payout: a sign that the seller account has been taken over. Apply a cooling-off period.
• Self-purchasing: the seller buys its own listings with stolen cards to turn fraud into a clean bank transfer. Matching buyer and seller data (address, device, card fingerprint) catches it.
• Triangulation fraud: the seller takes a legitimate order and fulfills it with a fraudulent purchase elsewhere. The chargeback lands on the third party, and the reputational damage on the platform.
• Reactivated dormant seller: an account verified three years ago that went inactive and suddenly shows heavy activity in a different category. Due diligence doesn't stop at onboarding.
• Pre-verification build-up: balances grow in the name of sellers who never finished onboarding. Capping collections before full verification prevents orphaned balances that can't be returned.

The platform as an arm of the tax authority

Tax law imposes two separate obligations on platforms. They are often confused, and they draw on different data and different teams. The first is a reporting obligation: the platform must tell the tax authority how much each seller earned. The second is substantive: the platform itself becomes liable for sales tax in place of the seller. The reporting obligation produces an annual filing. The substantive obligation changes the invoice issued, the price shown to the buyer, and the amount paid out to the seller.

• Collect the tax ID at onboarding, not in December. A seller chased 11 months later won't respond.
• Reconcile reported amounts with payouts: the tax authority compares the reported amount with the seller's bank flows. An unexplained gap triggers an audit, and the seller turns to the platform.
• Separate gross amounts, commissions, and refunds: regimes don't all use the same basis, and a single aggregate for all of them produces an incorrect return in half the countries.
• Plan for blocking: the account of a seller who refuses to provide information must be freezable, with a reminder sequence and a timestamped audit trail.

Paying out in 20 countries is a separate discipline

A payout is the transfer of a seller's sales proceeds, net of commission, from the platform to the seller. It runs on a different chain from collection, with its own rails, licenses, and cost structure. A platform that sells in one country and pays sellers in 15 others therefore faces a distribution problem, not a payment problem. The payout rail is almost always domestic, addressed by a local identifier, and bound by local operating hours. Currency conversion happens before the payment enters the rail, not while the transfer executes.

• Instant rails have no chargebacks. On Pix, UPI, PromptPay, DuitNow, BI-FAST, or PayNow, the transfer is final. Paying out too early means giving up any chance of recovery.
• The FX decision is made before the rail, and its cost shows in the spread over the reference rate, not in the posted fee. Paying out in local currency is almost always cheaper for sellers than leaving them to convert.
• Local operating hours drive treasury: a 24/7 rail on the seller's side is useless if the funding account is topped up on a business-day calendar.
• Paying a seller in a country where you hold no license is a licensing question, not an engineering one. The payout provider has to prove it holds its own license, country by country.
• Trigger thresholds are local: amounts, frequency, and recipient categories can tip a flow from a simple regime into a money transmission regime.

What breaks in day-to-day operations

Marketplace operating incidents follow the same pattern from one country to the next. They stem from the gap between the moment funds go out to the seller and the moment the risk attached to the order expires. The chosen regulatory structure doesn't close that gap. It only determines who ultimately bears the loss. Three situations come up in nearly every operating review, and the most expensive is a chargeback received after the payout.

• Orphaned balances: funds held for sellers who were never verified, which can neither be paid out nor kept indefinitely. Unclaimed property has its own rules, which differ by jurisdiction, and they apply even when individual amounts are trivial.
• Refund after payout: the commission has been taken, the seller has been paid, and the buyer is entitled to a refund. The marketplace agreement must specify, before any incident, who advances the funds.
• A broken link in the chain: the licensed provider loses its license, its account-holding bank ends the relationship, or its own partner stops providing service. The funds are protected; the service is not. A backup collection chain tested twice a year is worth more than a written continuity plan.
• Out-of-sync ledgers: the platform's internal balance diverges from the provider's. This symptom precedes almost every serious incident, and it is caught by automated daily reconciliation, not by an annual audit.
• Multi-account sellers: the same beneficial owner behind several seller accounts, to get around a limit, a freeze, or a ban. Matching by beneficial owner and by payout account exposes it.