platform workflow

Vault + marketplace / Merchant of Record

Atlas of Payments · Draft prepared November 12, 2026

The short answer

Keep credential storage separate from seller-of-record responsibilities. A vault can sit upstream of the parent account or in merchant-scoped tenant environments, where the provider supports the flow. Neither placement automatically makes the platform or child the Merchant of Record.

Marketplace is the business model. Merchant of Record is a role.

A marketplace can connect buyers and sellers without being the Merchant of Record for every transaction. Identify the contractual seller, the charge owner and the responsible party for refunds, disputes, tax and customer terms. Those roles must be agreed with the payment provider; vault placement does not assign them.

Seller-MoR model: each seller is the Merchant of Record where the approved arrangement supports it. The platform may receive an agreed fee.

Platform-MoR model: the platform is the Merchant of Record only under an appropriate commercial and payment arrangement, with the corresponding obligations. Routing funds through a parent account is not enough.

The two vault illustrations below show account and credential placement. Child-MoR labels are conditional, not a universal marketplace structure.

Two ways to place the vault

The difference is where the vault connects: upstream of the parent account, or directly to each child through a separate tenant. These diagrams follow the two account structures below, not a settlement or payment-processing sequence.

Option 1: Vault → parent account → child accounts

Vault upstream of the parent accountA vault on the left connects to a parent platform account in the middle. Three branches extend from that parent to child merchant accounts 1, 2 and 3. The vault supplies permitted credentials; the provider processes transactions under the configured account model.VaultShared entry pointParent accountPlatform connectionChild merchant 1Connected accountChild merchant 2Connected accountChild merchant 3Connected account
  1. Vault → parent account: one upstream vault connection supplies permitted credentials.
  2. Parent → child merchant 1: configured connected-account relationship.
  3. Parent → child merchant 2: configured connected-account relationship.
  4. Parent → child merchant 3: configured connected-account relationship.
Green arrows: vault-to-account and parent-to-child connection structure. They do not mean that money passes through the vault or that tokens automatically work across child accounts. The processor executes the payment using the intended account and supported permissions.

Option 2: Vault tenant → child account → parent fee

Child-specific vault tenants and a parent fee recipientVault tenant 1 connects to child merchant 1, tenant 2 to child merchant 2 and tenant 3 to child merchant 3. Distinct dashed arrows indicate configured percentage or flat platform-fee allocations toward the parent account. These fee allocations are executed by the processor, not by the vault.VaultTenant 1Tenant 2Tenant 3Child merchant 1Merchant accountChild merchant 2Merchant accountChild merchant 3Merchant account% / flat feeParent platformaccountFee recipientSeparate tenants. Direct child connections. Processor-executed fee allocations.
  1. Tenant 1 → child merchant 1 → parent fee.
  2. Tenant 2 → child merchant 2 → parent fee.
  3. Tenant 3 → child merchant 3 → parent fee.

Each child has its own vault tenant connection. The parent receives the configured percentage-calculated or flat platform fee through the processor’s supported mechanism.

Green arrows: each tenant’s direct connection to its child account. Dashed arrows: configured percentage-calculated or flat platform-fee allocation to the parent. The vault does not move or split funds. Fees may be supplied as calculated amounts depending on the processor API; this is not a promise of universal percentage-field support.

Child merchant-of-record status depends on the actual legal and processing setup. The parent’s role as fee recipient does not make it merchant of record for the same sale. Cross-tenant payment-method sharing is not shown and is not automatic: it requires supported capability, configuration, permission and consent. Account ownership, refunds, disputes, settlement and PCI duties remain governed by the provider setup and agreements.

Explore vault placement details

Vault upstream of the parent account

Vault upstream of each child account

Where does the vault sit?

Upstream of the parent platform account: a platform-managed token layer with explicit per-merchant permissions.

Upstream of each child merchant account: merchant-scoped storage and forwarding boundaries.

Neither design makes tokens interchangeable or changes merchant-of-record and settlement responsibilities.

What your team needs to do

  1. Map who owns the merchant account, payment method, charge, refund and dispute.
  2. Confirm the gateway-supported collection or migration path and assess PCI responsibilities.
  3. Test tenant-scoped token use, permitted forwarding, downstream account references, reversals and reconciliation.

Before you build

  • Independent vault tokens and gateway-specific tokens are not interchangeable. A forward proxy cannot bypass account scope, gateway underwriting or restricted-business policies.
  • This is a research draft, not legal advice or a claim of provider availability. Validate current rules and the exact business model before implementation.

Measure the right outcome

Eligible completed orders, net cost and reconciled outcomes by approved route.

Questions operators ask

Will a vault guarantee payment acceptance?

No. A vault changes storage and data delivery. It does not change underwriting, law, provider terms or issuer decisions.

What should the team prepare next?

A one-page map of the business, jurisdictions, account ownership, consent, required operations and failure handling.

Integration considerations

A forward proxy can resolve token references for permitted outbound requests; inbound capture typically uses a separate collection or reverse-proxy flow. Validate exact behavior, endpoint contracts and permission. Some workflows need asynchronous batch transfer rather than HTTP forwarding. Industry eligibility depends on jurisdiction and provider underwriting.

Make the next decision concrete

Write down the business model, account owner, required operation, permitted data and proof of completion. Resolve those five points before comparing providers.

Explore another path (optional)