The
Company A
Shop
R$ 600
Payment Split
One sale, multiple recipients? Gain efficiency, visibility and control without double taxation.
Set up the distribution of sales by percentage or fixed value, automate settlement between participants and maintain the link between payment, participants and settlement.
The following is the list of the products:
R$ 1.000
Transaction
#84217
Card
IO
IOPAY
Split engine
Rule automatically applied
3 participants
B. Other
Company B
The following is the list of the following:
R$ 250
C. Other
Company C
Commission
R$ 150
Define how much each participant receives in relation to the value of the sale.
Set specific amounts for each participant in accordance with the financial rules of the operation.
Reduce manual calculation routines and financial distribution after the sale.
Maintain the relationship between transaction, participants and financial distribution.
Tax efficiency
Split can reorganize the operation and create efficiency from the start.
When the sale is already made distributed among the right participants, the transaction reduces the intermediate stages. In many models, this eliminates layers where an enterprise would receive the integer value only to redistribute it later — which can improve accounting and generate tax efficiency, according to the legal and tax model of the enterprise.
Less internal traffic of resources.
The sale does not necessarily have to go through a central layer in its entirety to follow the economic participants of the transaction only later.
Less parallel reconciliation.
Payment, distribution rule and settlement remain connected on the same operational track.
More adherence to the real economic design.
Each participant follows their share according to the logic of the sale, with less financial improvement at closing.
What's important is:
the taxable profit depends on the legal framework, accounting and contractual structure of the operation. The split organises the financial infrastructure for a potentially more efficient design, but does not replace accounting or legal validation.
No split at the origin.
The platform centralizes 100% of the sale and then carries out the financial distribution among the participants
approved sale
R$ 1.000
receives first
Platform centralizes
R$ 1.000
Distribute it later
Company A
R$ 700
Company B
R$ 220
Company C
R$ 80
Operational effect
More internal traffic, more later steps and an additional layer of financial reading before the final economic destination
Split from the beginning.
The financial rule already accompanies the sale, allowing the distribution to be organised in the context of the transaction itself.
approved sale
R$ 1.000
the rule applied to the sale
Company A
R$ 700
Company B
R$ 220
Company C
R$ 80
Operational effect
The distribution is born tied to the sale, reduces manual routines and can eliminate layers that, in certain structures, would generate bi-taxation or fiscal inefficiency.
How it works
The split follows the sale from the beginning.
Instead of getting everything in one account and then distributing it, your operation sets the financial rule for payment and follows the distribution within the same ecosystem.
With Payment Split you optimize and control every sale, automate distribution to partners, track and audit the entire transaction, and reduce intermediate financial layers that can lead to tax inefficiency
01
The sale is made.
Your system starts charging by the integration or channel enabled in the operation.
02
The rule defines the recipients.
Participants and distribution logic are associated with the financial context of the sale.
03
The distribution is processed.
Percentage or defined values follow the set rule, reducing the need for further manual calculation.
04
Conciliation and events remain connected.
Transactions, participants, Payment Split and other transaction events continue to be monitored by IOPAY, including by webhooks delivered to its system
Rules of Distribution and Split
Estruture the financial flow of your business model since the transaction and potentialize your company's results
Use the split to represent the actual economic relationship between companies, partners and other participants in the sale.
Proportional distribution.
Define percentage holdings where the amount allocated to each recipient is equal to the total sales.
Defined values.
Use defined values when each participant needs to receive a specific amount per transaction.
Multiple participants.
Associate distribution with the recipients who are part of the operation and preserve the context of each sale.
Sell and Payment Split on the same track.
Less parallel sheets and more clarity to keep track of what was sold, distributed and liquidated.
Financial automation
From sale to settlement, no parallel sheets
IOPAY connects split, transaction and settlement rule on a single operational track. This reduces manual calculation at closing and improves the financial traceability of the platform.
10:42:11
Approved payment
R$ 1.000
10:42:12
The split rule applied
3 receivers
10:42:12
Registered distribution
60% · 25% · 15%
10:42:13
Webhook sent to the customer
200 OK
settlement
Value linked to participants
Traceable
API and automation
Integrate the split into the flow you already have.
Your integration continues to be centralized in IOPAY. To each relevant change in the transaction — transaction creation, approval, update, implementation of the Payment Split rule and other financial events — your system continues to receive webhooks from IOPAY, maintaining a single layer of integration, traceability and transaction cycle monitoring
Operation credentials include the IO_Seller_ID, and webhooks can be configured so that your backend receives events and updates automatically, without having to rebuild your communication layer to keep up with Payment Split
IOPAY integration
REST · sellers · webhooks
Identification of the product
IO_Seller_ID
Identifier used in seller account credentials and integrations.
API
Customized integration
Connect your backend to the payment infrastructure without altering your product experience.
Events
Webhooks IOPAY
Continue receiving transactions events and updates from IOPAY, including when there is a Payment Split
Platforms & marketplaces
When there are multiple participants, the split becomes part of the infrastructure.
Combine financial distribution with onboarding of participants, sub-accounts, Payment Split rules and consolidated view of the operation Split takes care of financial logic; the marketplace layer organizes participants and their flows
Company A (spoiler)
R$ 600
Company B (logistics)
R$ 250
Company C (commission for sale)
R$ 150
The consolidated view of the transaction connects participants, Payment Split rules, webhooks, and financial tracking in one ecosystem
Frequent Questions
Payment Split, no complications.
The essential points for understanding where the appeal comes into play.
Can the split be done as a percentage?
Yes IOPAY allows you to structure distribution rules by percentage or by fixed value, depending on the configuration of the operation.
Is it necessary to distribute manually?
The proposal for the appeal is to automate the distribution and settlement associated with the split rule by reducing the need for manual spreadsheets and calculations
Does the split have traceability?
Yes The solution maintains the link between sale, recipients, rule applied and financial distribution, supporting conciliation and operational audit
Do I still get the webhooks from IOPAY?
Yes Customer integration continues to be centralized in IOPAY. Relevant transaction events and updates continue to be delivered to the client-configured backend via IOPAY webhooks
Can I integrate it into my system?
- I know. IOPAY provides API REST for custom integration and credential documentation and webhooks for automating communication with its backend.
Content of the IOPAY
To deepen the split, marketplaces and financial operations.
We selected IOPAY Blog readings that complement this page with themes of distribution, sellers, settlement, ledger, receivables and payment architecture.
15 selected readings
Payment split: how marketplaces and platforms divide value without losing balance
Sellers, split rules, returns, chargebacks, receivables and the importance of connecting split, ledger and financial policy.
Read the articleFinancial Conciliation for Sellers: How Marketplaces Close Sales, Fees, and payouts
How to relate each participant's request, split, receivable, adjustment and distribution without losing the financial context
Read the articleCheckout for marketplaces: sellers, split, freight and payment in a single day
How to preserve the buyer's experience while the transaction maintains multiple seller financial rules.
Read the articleFinancial Ledger: Why payment platforms need unchanging releases
Debt, credit, derivative balances, returns and adjustments as a basis for explanatory and auditable financial operations.
Read the articleHow it works in practice and why selling is not enough
From the sale approved to the fee conference, installment, refunds, chargebacks and settlement.
Read the articleFinancial reconciliation of payments: how to close sales and settlements without spreadsheets
A daily, auditable routine to reconcile card, Pix, settings, fees and receivables schedules.
Read the articleReconciliation job: why even webhook-oriented architectures need to check status
Events can delay, duplicate, or go out of order; see how to spot discrepancies before you see financial problems.
Read the articleAPI payments: how to build a reliable integration
Idempotence, webhooks, states and modeling required when the operation includes receivers, sellers and split.
Read the articleHow to integrate payments into your system via API
Architecture, security, retreats, and the like. webhooks and production checklist for resilient financial integrations.
Read the articlePayment gateway: what it is, how it works and why architecture matters
APIs, tokenization, observability, reconciliation and features for marketplaces within a modern infrastructure.
Read the articlePayment Operations: what a Payments team does and what indicators to follow
Product, engineering, risk and finance connected from approval to reconciliation and economic outcome.
Read the articleCash outstanding with payments: from receivables to treasury forecast
How to connect future sales, settlements, adjustments and accounts payable to see the actual liquidity of the transaction.
Read the articleRolling stock and risk holdings: available balance against economic balance
As contractual reserves affect cash, reporting, settlement and financial reading of a payment transaction.
Read the articleReceivables schedule: how to organize future sales and cash flow
Plants, settlements and upfront transactions turn a sale into a financial calendar that needs to be followed.
Read the articleCard receivables: how they work and why they need to be reconciled
From the approved payment to settlement: deadlines, installments, remittances and the checks necessary to see the actual cash.
Read the article
IOPAY
Automate the financial distribution of your platform.
Participating structure and distribution rules without turning financial closure into a manual operation.