Skip to main content
One decision shapes the rest of a Connect integration.
When a customer pays, do they pay you, or the account?
Three questions answer it, and each stands on its own: who is the merchant of record, who pays the processing fee, and who carries a refund or a lost dispute. On this API the merchant of record decides the other two, so answering any one of them is enough to land on a shape. Changing shape later means re-onboarding every account.

​
The two shapes

Most marketplaces should collect. Customers buy from the marketplace, not from each seller individually, so the marketplace is the merchant of record and its accounts are recipients: they receive money rather than take payments. They never need a payment-accepting capability, which is why their onboarding is short. Most SaaS platforms should have the account collect. Each business transacts directly with its own customers, who are often unaware your platform exists, so it is the merchant of record for those payments and needs a payment-accepting capability of its own. If you are unsure which you are, ask whose brand the customer thinks they are buying from.

​
You collect

The customer pays you. The charge settles into your balance, and you transfer each account its share. Your cut is whatever you do not transfer. See Split payments for the full flow.
  • Requirements are shorter, so fewer accounts abandon onboarding.
  • You control the checkout and the timing of every transfer.
  • A refund or a lost dispute debits your balance for the full amount owed. A lost dispute can drive it negative; see Disputes.
  • If you have already transferred the share, recovering it means a transfer back, and a transfer never goes below zero: recovery fails once the account has withdrawn.
Transfers draw on available_balance. A charge lands in pending_balance and moves across on settlement, so a transfer sent before settlement fails with INSUFFICIENT_BALANCE. Trigger transfers on settlement. See Balances.
Delaying the split reduces recovery risk: the longer you hold a share, the more likely a dispute arrives while the balance is still reachable.

​
The account collects

The customer pays the account. The charge lands in that account’s balance.
  • Refunds and disputes debit the account’s balance, not yours.
  • The account needs a payment-accepting capability, which lengthens its requirements. See Capabilities.
  • You cannot transfer a charge you never held. Paying the account means transferring from your own balance, funded separately.
See Platform fees.

​
Deciding

Any one of these, answered on its own, points to a shape. If they disagree, weigh them: the merchant-of-record question usually carries the most, since the other two follow from it by default.
  • Who should be the merchant of record? Whose brand does the customer think they are buying from. If they came to your marketplace and would recognise your name on the order, you collect. If each account transacts directly with customers it brought, who may not know your platform exists, the account collects.
  • Who should carry a refund or a lost dispute? If you cannot absorb that risk across every account, put it on the account.
  • Who should pay the processing fee by default? Whichever party you named merchant of record pays it unless you reassign it. See Processing fees.
One more factor outside the three questions: an account made up of individuals rather than registered businesses has shorter requirements as a recipient than as a merchant. If your accounts are individuals and none of the questions above forces the account to collect, let you collect instead.