Crypto Marketplace Payments: Multi-Merchant Splits & Webhooks

Crypto marketplace payments route a single buyer payment to a platform and one or more vendors without a custodial middleman holding funds. Settlematic does this by binding each checkout deposit address to vendor settlement wallets at issuance, applying platform-fee splits you configure, and firing webhooks per sub-merchant so your ledger updates automatically. There is no percentage of volume, no pooled balance, and no payout delay.

What makes crypto marketplace payments different from single-merchant checkout

A single-merchant checkout has one settlement destination: the seller's wallet. A marketplace checkout has at least two, often many. The buyer pays once, but the funds must be divided between the platform (commission) and each vendor (sale proceeds), and every vendor needs proof of payment to release goods or services. That routing problem is what separates a marketplace payment rail from a standard gateway.

Two architectural choices make this hard. First, on-chain payments are final, so a wrong split cannot be reversed by the processor. Second, most blockchains do not let a third party pull funds from a buyer wallet, so splits must be computed and bound before the buyer sends. Settlematic solves both by deriving each checkout address with the split baked in at issuance, described in detail on our platforms industry page.

How platform-fee splits work without a custodial middleman

Custodial marketplace processors solve splits by collecting every payment into their own balance, computing commissions in a ledger, and paying vendors out on a schedule. That works, but it puts vendor funds in the processor's custody for hours or days, exposes them to freezes and reserves, and adds a percentage take-rate on top. Non-custodial settlement removes the pooled balance entirely.

With Settlematic, you configure settlement destinations per chain and asset with percentage weights that sum to 100%. When a checkout session is created, the deposit address is cryptographically bound to those destinations at issuance. The buyer's payment settles on-chain directly to the configured wallets, the platform fee lands in your wallet, and vendor proceeds land in theirs. Settlematic watches the chain for confirmation and reconciles, but never holds keys that could redirect an address once issued.

• Splits are bound at issuance, not computed after receipt, so the on-chain payment is the settlement.
• Platform fee is an amount you set and receive, not a Settlematic commission taken from volume.
• No pooled vendor balance means no reserve, no freeze, and no payout schedule to wait on.
• Per-vendor settlement destinations can be cold storage, multisig, or an exchange deposit address.

Multi-merchant routing: address-bound settlement per vendor

Each vendor on a marketplace gets its own settlement configuration, and each checkout session generates a fresh deposit address bound to the relevant vendor destinations. Fresh addresses per session improve privacy and reconciliation: the marketplace does not need to share one vendor address across buyers and untangle who paid what. The address itself encodes the routing.

This is the same BIP-84 / CREATE2-style binding Settlematic uses for single-merchant invoicing, extended to multi-destination splits. Watch-only workers detect payments on-chain without ever holding signing keys, so compromise of Settlematic infrastructure cannot redirect issued-address funds. The blast radius of a platform breach stays small even as the vendor count grows.

Webhooks: reconciling marketplace payments across sub-merchants

Routing the funds is half the problem. The other half is telling your marketplace backend which vendor order to fulfil, which commission to record, and which escrow release to trigger. That is what webhooks are for. The reconciliation patterns are documented in our crypto payment webhooks reconciliation guide.

Settlematic fires signed HTTP webhooks on `payment.detected` and `payment.confirmed` events. Each payload carries the invoice ID, sub-merchant ID, deposit address, transaction hash, asset, network, and settled fiat-quoted amount. Your backend uses the event to mark the vendor order paid, update the commission ledger, and release fulfilment without polling the chain.

• Per-event delivery log with HTTP status and timestamp so you can debug failed deliveries.
• Retry failed deliveries from the dashboard without re-running the checkout.
• Fiat-quoted amount in the payload keeps your ledger in USD/EUR/GBP regardless of which asset the buyer used.
• Sub-merchant ID in every event lets one webhook endpoint route to the correct vendor record.

Custodial marketplace processors vs non-custodial settlement

Where a custodial processor is the better fit

Non-custodial settlement is not the right answer for every marketplace. There are three cases where a custodial processor is the more practical choice, and we say so plainly:

• Automatic fiat off-ramp to vendor bank accounts. Settlematic settles in stablecoins to vendor wallets; converting to local currency and wiring to a bank is each vendor's responsibility. If your vendors cannot hold USDC, a custodial processor with built-in fiat payout removes that operational burden.
• Broad coin coverage. If your buyers pay in assets beyond USDC, USDT, EURC, ETH, and BTC, a multi-coin custodial gateway serves them better than Settlematic's stablecoin-plus-Bitcoin focus.
• Refund and dispute machinery. On-chain payments are final, so refunds are a manual outbound transfer. Marketplaces with high return rates may prefer a processor with built-in dispute handling.

Getting started with non-custodial marketplace checkout

Multi-merchant crypto checkout does not require a custom smart contract or a pooled escrow. With Gateway, you configure vendor settlement destinations, set platform-fee splits, embed the checkout, and subscribe to webhooks. The free sandbox lets you run the full multi-merchant flow on testnet before going live.

Review flat-rate plans on pricing, or book a live multi-merchant walkthrough at /demo to see address-bound splits and webhook reconciliation in action.