Sellers & distribution

Split API

Internal hub to organize the integration of distribution among participants, from seller registration to reconciliation of the result.

PrerequisiteIdentified sellers
UseMulti-participant distribution
StatusDocumentation migration

Overview

Use Split when an operation needs to direct amounts to multiple participants within the same payment context. The implementation must start from previously identified sellers and distribution rules compatible with the operation's contract.

Participants

Identified sellers.

Each destination must be correctly represented on the platform.

Rule

Explicit distribution.

Build the split composition according to the commercial model and the current contract.

Reconciliation

Reference preserved.

Keep internal IDs to reconcile order, transaction and participants.

Flow

01 · RegistrationIdentify sellers.

Make sure each participant is eligible for the operation.

02 · RuleBuild the distribution.

Define participants and amounts/percentages according to the contract.

03 · PaymentCreate the transaction.

Bring the split rule into the flow compatible with the API.

04 · FinanceReconcile.

Use references and events to track the operation's result.

Modeling

Logical fieldWhat it's forBest practice
reference_idCorrelate the payment with your order/operation.Use a stable, unique value.
seller_idIdentify the participant who will receive part of the operation.Validate the seller before building the split.
amount / percentageRepresent the distribution rule when supported by the contract.Avoid ambiguous rounding.
metadataAdditional internal context when available.Don't store secrets or unnecessary sensitive data.
Route contract. The exact field and endpoint names must be migrated from the official collection to this page before permanently removing the external reference.

Checklist

  • Sellers registered and eligible for the operation.
  • Distribution rule validated with finance/sales.
  • Validation of the sum of amounts/percentages.
  • Internal order reference preserved.
  • Webhooks connected to the transaction lifecycle.
  • Reconciliation and handling of cancellations/refunds defined.

Temporary external reference

Until the endpoint migration is complete, use the Postman collection to check the technical contract.

Open technical collection ↗