Get to know Payment Split

Payment Split automatically distributes part of the amount received in a charge among other Asaas accounts.

The charge remains in the account responsible for the sale or service, while the configured amounts are transferred to the wallets specified in the Split.

Choose the flow

The Split configuration varies according to the type of charge:

You can also create automations with Split using Make.

Before you start

To configure a Split:

• each recipient must have an Asaas account;
• obtain the walletId of the accounts that will receive the amounts;
• define whether each transfer will be fixed or percentage-based;
• do not provide the walletId of the account creating the charge itself.

The walletId is returned when creating a subaccount and can also be retrieved via API when you have access to the destination account.

How it works

Consider a sale made by João's account in which Marcelo should receive 20%:

1. João creates the charge in his own account;
2. the Split specifies Marcelo's walletId and the 20% percentage;
3. after the payment is received, Asaas calculates the Split on the charge's net amount;
4. the corresponding amount is transferred to Marcelo;
5. the undistributed net balance remains with João.

Define the Split amount

The transfer can be configured in two ways:

You can combine fixed and percentage amounts in the same charge.

There is no priority between Split types. All of them are validated against the available net amount.

For example, for a charge with a netValue of R$ 98.00:

fixedValue = R$ 50.00
percentualValue = 50%

50% of R$ 98.00 = R$ 49.00

R$ 50.00 + R$ 49.00 = R$ 99.00

In this scenario, the configuration exceeds the netValue and cannot be processed.

For percentage-only Splits, the sum cannot exceed 100%.

Specific installment rules, such as totalFixedValue, are detailed in Split into installments.

Track the Split

Use Webhooks to track settlement without making recurring API queries.

The event:

PAYMENT_SPLIT_DONE

is sent individually when a Split is settled.

When a charge has more than one Split, each settlement may generate a different event.

Identify the corresponding Split by:

{
  "additionalInfo": {
    "splitId": "064a4957-1eee-4d06-9c96-deaf8a17534d"
  }
}

See Payment events.

Block due to divergence

If, upon receipt or anticipation, the amount configured for the Splits exceeds the available net amount, the amount and the Split are blocked for adjustment.

The integration receives:

PAYMENT_SPLIT_DIVERGENCE_BLOCK

The deadline for correction is 2 business days.

If the configuration is corrected within the deadline and starts respecting the available amount, the Split is processed.

If there is no correction, the block expires, the Splits are canceled and the application receives:

PAYMENT_SPLIT_DIVERGENCE_BLOCK_FINISHED

Refunds

When a charge with Split is refunded, the related transfers are also refunded.

Take this behavior into account when reconciling the accounts that received amounts from the charge.

Split status

The available statuses are:

When the status is REFUSED, the refusalReason field may indicate the reason for the refusal.

The reason RECEIVABLE_UNIT_AFFECTED_BY_EXTERNAL_CONTRACTUAL_EFFECT indicates that the Split was not executed due to the existence of contract effects.

Next steps

• Configure Split in single payments
• Configure Split into installments
• Configure Split on subscriptions
• See the rules for anticipated payments
• Track Splits through the interface
• See the Split FAQ