A
Company A
Store
R$ 600
Payment split
One sale, but several recipients? Bring efficiency, visibility and control without double taxation.
Set up the sale's distribution by percentage or fixed amount, automate settlement among participants and keep the link between payment, participants and settlement.
SALE APPROVED
R$ 1,000
Transaction
#84217
Card
IO
IOPAY
Split engine
Rule applied automatically
3 participants
B
Company B
Logistics
R$ 250
C
Company C
Commission
R$ 150
Define how much each participant receives relative to the sale amount.
Define specific amounts for each participant according to the operation's financial rule.
Reduce manual calculation and financial distribution routines after the sale.
Keep the relationship between transaction, participants and financial distribution.
Tax efficiency
Split can reorganize the operation and create efficiency from the source.
When the sale is already born distributed among the right participants, the operation reduces intermediate steps. In many models, this eliminates layers in which a company would receive the full amount only to redistribute it later, which can improve the accounting view and generate tax efficiency, depending on the company's legal and tax structure.
Less internal transit of funds.
The sale does not necessarily need to pass in full through a central layer before going on to the operation's economic participants.
Less parallel reconciliation.
Payment, distribution rule and settlement remain connected in the same operational trail.
Closer alignment with the real economic design.
Each participant tracks their share according to the logic of the sale, with less financial improvisation at closing.
Important: the tax gain depends on the legal classification, the accounting and the contractual structure of the operation. Split organizes the financial infrastructure for a potentially more efficient design, but does not replace accounting or legal validation.
No split at the source.
The platform centralizes 100% of the sale and then distributes the funds among the participants.
Sale approved
R$ 1,000
receives first
Platform centralizes
R$ 1,000
distributes later
Company A
R$ 700
Company B
R$ 220
Company C
R$ 80
Operational effect
More internal transit, more later steps and an extra layer of financial interpretation before the final economic destination.
With split from the source.
The financial rule travels with the sale, allowing distribution to be organized within the transaction's own context.
Sale approved
R$ 1,000
rule applied at the sale
Company A
R$ 700
Company B
R$ 220
Company C
R$ 80
Operational effect
Distribution is born linked to the sale, reduces manual routines and can eliminate layers that, in certain structures, would generate double taxation or tax inefficiency.
How it works
The split travels with the sale from the source.
Instead of receiving everything in a single account and splitting it later, your operation defines the financial rule linked to the payment and tracks the distribution within the same ecosystem.
With Payment Split you optimize and control every sale, automate distribution to partners, track and audit the entire operation and reduce intermediate financial layers that can generate tax inefficiency.
01
The sale is created.
Your system starts the charge through the integration or channel enabled for the operation.
02
The rule defines the recipients.
Participants and the distribution logic are associated with the sale's financial context.
03
The distribution is processed.
Defined percentages or amounts follow the configured rule, reducing the need for later manual calculation.
04
Reconciliation and events stay connected.
Transactions, participants, Payment Split and other operation events continue to be tracked by IOPAY, including through webhooks delivered to your system.
Distribution and Split rules
Structure your business model's financial flow from the transaction and boost your company's results.
Use split to represent the real economic relationship between companies, partners and the other participants in the sale.
Proportional distribution.
Define percentage shares when the amount allocated to each recipient follows the sale total.
Defined amounts.
Use defined amounts when each participant needs to receive a specific sum per transaction.
Multiple participants.
Associate the distribution with the recipients that are part of the operation and preserve the context of each sale.
Sale and Payment Split on the same trail.
Fewer parallel spreadsheets and more clarity to track what was sold, distributed and settled.
Financial automation
From sale to settlement, without parallel spreadsheets.
IOPAY connects split rule, transaction and settlement in the same operational trail. This reduces manual calculation at closing and improves the platform's financial traceability.
10:42:11
Payment approved
R$ 1,000
10:42:12
Split rule applied
3 recipients
10:42:12
Distribution recorded
60% · 25% · 15%
10:42:13
Webhook sent to the customer
200 OK
Settlement
Amounts linked to the participants
traceable
API & automation
Integrate split into the flow you already have.
Your integration remains centralized at IOPAY. With every relevant change in the operation (transaction creation, approval, update, application of the Payment Split rule and other financial events), your system keeps receiving the webhooks through IOPAY, maintaining a single layer of integration, observability and tracking of the transaction lifecycle.
The operation's credentials include the IO_Seller_ID, and webhooks can be configured so your back end receives events and updates automatically, without having to rebuild your communication layer to track Payment Split.
IOPAY integration
REST · sellers · webhooks
Identification
IO_Seller_ID
Identifier used in the credentials and integrations of the seller account.
API
Custom integration
Connect your back end to the payments infrastructure without changing your product experience.
Events
Webhooks IOPAY
Keep receiving transaction events and updates through IOPAY, including when there is Payment Split.
Platforms & marketplaces
When there are multiple participants, split becomes part of the infrastructure.
Combine financial distribution with participant onboarding, subaccounts, Payment Split rules and a consolidated view of the operation. Split handles the financial logic; the marketplace layer organizes the participants and their flows.
Company A (merchant)
R$ 600
Company B (logistics)
R$ 250
Company C (commission per sale)
R$ 150
The consolidated view of the operation connects participants, Payment Split rules, webhooks and financial tracking in a single ecosystem.
Frequently asked questions
Payment split, without complication.
The essential points to understand where the feature fits into the operation.
Can the split be done by percentage?
Yes. IOPAY lets you structure distribution rules by percentage or fixed amount, according to the operation's setup.
Do I need to distribute funds manually?
The purpose of the feature is to automate distribution and the settlement associated with the split rule, reducing the need for spreadsheets and manual calculations.
Is the split traceable?
Yes. The solution keeps the link between sale, recipients, applied rule and financial distribution, supporting reconciliation and operational auditing.
Do I keep receiving webhooks through IOPAY?
Yes. The customer's integration remains centralized at IOPAY. Relevant transaction events and updates continue to be delivered to the back end configured by the customer through IOPAY webhooks.
Can I integrate it with my system?
Yes. IOPAY provides a REST API for custom integrations and documentation on credentials and webhooks to automate communication with your back end.
IOPAY Content
To go deeper into split, marketplaces and financial operations.
We selected reads from the IOPAY Blog that complement this page with topics on distribution, sellers, reconciliation, ledger, receivables and payments architecture.
15 selected reads
Payment split: how marketplaces and platforms divide amounts without losing reconciliation
Sellers, split rules, refunds, chargebacks, receivables and the importance of connecting split, ledger and financial policy.
Read article →Financial reconciliation for sellers: how marketplaces close sales, fees and payouts
How to relate order, split, receivable, adjustment and distribution for each participant without losing financial context.
Read article →Checkout for marketplaces: sellers, split, shipping and payment in a single journey
How to preserve the buyer experience while the operation maintains multi-seller financial rules.
Read article →Financial ledger: why payment platforms need immutable entries
Debits, credits, derived balances, refunds and adjustments as the foundation for explainable, auditable financial operations.
Read article →Card reconciliation: how it works in practice and why selling isn't enough
From the approved sale to checking fees, installments, refunds, chargebacks and settlement.
Read article →Payment reconciliation: how to close sales and settlements without spreadsheets
A daily, auditable routine to reconcile cards, Pix, adjustments, fees and receivables schedules.
Read article →Reconciliation job: why even webhook-driven architectures need to check state
Events can be delayed, duplicated or arrive out of order; see how to detect discrepancies before they become financial problems.
Read article →Payments API: how to build a reliable integration
Idempotency, webhooks, states and the modeling needed when the operation includes recipients, sellers and split.
Read article →How to integrate payments into your system via API
Architecture, security, retries, webhooks and a production checklist for resilient financial integrations.
Read article →Payment gateway: what it is, how it works and why architecture matters
APIs, tokenization, observability, reconciliation and marketplace features within a modern infrastructure.
Read article →Payment Operations: what a Payments team does and which indicators to track
Product, engineering, risk and finance connected from approval to reconciliation and the economic result.
Read article →Cash forecasting with payments: from the receivables schedule to the treasury forecast
How to connect future sales, settlements, adjustments and accounts payable to see the operation's real liquidity.
Read article →Rolling reserve and risk holds: available balance versus economic balance
How contractual reserves affect cash, reports, reconciliation and the financial reading of a payments operation.
Read article →Receivables schedule: how to organize future sales and cash flow
Installments, settlements and prepayments turn a sale into a financial calendar that needs to be tracked.
Read article →Card receivables: how they work and why they need to be reconciled
From approved payment to settlement: terms, installments, refunds and the controls needed to see real cash.
Read article →
IOPAY
Automate your platform's financial distribution.
Structure participants and distribution rules without turning financial closing into a manual operation.