Marketplaces
Connect marketplace checkout and payment operations while preserving seller, order, refund, dispute, and reconciliation context.
On this page
Marketplace payment flows involve more than the buyer and a single order. They can also depend on seller identity, provider onboarding, commercial ownership, split or payout behavior, partial fulfillment, refunds, disputes, reserves, and financial reconciliation.
Define the operating model first#
Before choosing an integration, confirm:
- which entity is the merchant of record for the buyer transaction;
- whether sellers use one shared processing account or separately onboarded accounts;
- which system calculates commissions, seller amounts, taxes, reserves, and payouts;
- which provider and account supports any required split, transfer, sub-merchant, or payout operation;
- who owns refunds, disputes, negative balances, and seller settlement reconciliation.
DEUNA's public order and payment contracts do not imply that every provider supports split processing or payouts. Your Technical Account Manager must confirm the supported connection, account model, operation, credentials, and settlement behavior.
Preserve marketplace context#
| Context | Implementation guidance |
|---|---|
| Buyer order | Use an immutable merchant order reference and the DEUNA order_token. |
| Seller | Use a stable, non-sensitive seller reference in supported merchant fields or namespaced metadata. |
| Items and fulfillment | Preserve the seller, shipment, cancellation, and refund relationship in your system of record. |
| Payment attempts | Keep every route, retry, capture, refund, and uncertain result connected to the original order. |
| Financial operations | Reconcile processor settlement, marketplace ledger, seller obligation, fee, reserve, refund, and dispute evidence. |
Design partial operations deliberately#
Test orders containing multiple sellers, shipments, capture times, cancellations, and refunds. A partial capture or refund must remain within the operation and provider capabilities enabled for the account. Do not create a second order merely to recover from an unknown payment result.
For risk integrations that accept seller context, use only the fields supported by the selected provider and anti-fraud connection. Do not send provider credentials or unnecessary seller personal data through metadata.
Continue with Provider capabilities, Capture and refunds, Dispute Management, and Payment Reconciliation.