Endpoint responsible for creating a new charge in Asaas.

This is the main request in the receivables flow and can be used to generate one-time charges with boleto, Pix, credit card, or an undefined payment method, allowing the payer to choose how they want to complete the payment.

A charge created through this endpoint can be used in simple flows, installment flows, flows with redirection to the invoice page, or flows linked to a Pix Automatic authorization.

Main request parameters

Some fields play a central role in the charge behavior:

• customer — Unique identifier of the customer in Asaas to whom the charge will be linked
• billingType — Defines the payment method for the charge. Possible values are:
  • BOLETO
  • PIX
  • CREDIT_CARD
  • UNDEFINED
• value — Charge amount. This must be used for one-time single-installment charges
• dueDate — Charge due date
• description — Charge description
• externalReference — Charge identifier in your system. Recommended to facilitate tracking, reconciliation, and future searches
• discount — Object containing the discount rules applied to the charge
• interest — Object containing the interest rules for payments made after the due date
• fine — Object containing the fine rules for payments made after the due date
• split — Object containing the configuration for splitting the received amount between accounts
• callback — Object containing the automatic redirection settings after the invoice is paid
• pixAutomaticAuthorizationId — Identifier of the Pix Automatic authorization when the charge is linked to this flow

Rule regarding the payment method

It is not possible to create a single charge with two different billingType values at the same time, such as PIX and CREDIT_CARD.

When the integration needs to allow the payer to choose the payment method, the correct behavior is to use UNDEFINED, as long as the desired payment methods are enabled on the account.

Important rule for one-time and installment charges

For one-time single-installment charges, only the value field must be sent.

The fields below must only be used for installment charges with two or more installments:

• installmentCount
• installmentValue
• totalValue

This distinction is important to avoid incorrectly creating installment plans in scenarios where the intention is to generate only a simple one-time charge.

Installment calculation

For installment charges, the integration can follow one of two approaches:

• send installmentCount and installmentValue to explicitly define the number of installments and the amount of each installment
• send installmentCount and totalValue so that Asaas automatically calculates the amount of each installment

When the total amount cannot be divided evenly across installments, the adjustment will be applied to the last installment.

Cancellation of boleto registration after the due date

The daysAfterDueDateToRegistrationCancellation attribute defines for how many days after the due date the boleto will remain eligible for payment.

This behavior applies only to boleto charges. For Pix and credit card charges, this attribute is not considered.

If the value sent is 0, the boleto registration will be automatically canceled when the charge reaches the OVERDUE status, preventing payment after the due date.

If the field is not sent, the account's default registration period will be used.

This attribute cannot be changed after the charge is created. If this rule needs to be changed, a new charge must be issued.

Globally configured fines and interest

If the account has global fine and interest settings, sending the interest and fine objects with null or empty values may overwrite that configuration for the newly created charge.

If the intention is to keep the default behavior configured on the account, the recommendation is not to send these objects in the request. Another option is to standardize the application to explicitly send the same values already configured in Asaas.

CONFIRMED status in Pix charges for individuals

In Pix charges for individual accounts, the CONFIRMED status may appear temporarily in cases of precautionary blocking for review by the prevention team.

In these scenarios, the review may take up to 72 hours. After that period, the charge may move to:

• RECEIVED, when the payment is confirmed
• REFUNDED, when the payment is denied

This behavior must be considered by the integration to avoid incorrectly treating the charge as definitively settled while the review is still in progress.