Refusal reasons

During the processing of Automatic Pix payment instructions, a charge may be refused either by Asaas or by the payer's financial institution.

Refusals represent situations that prevent the scheduling or settlement of recurring charges and should be properly handled by the integration to provide an appropriate experience for the user.

This page presents the main refusal reasons and the expected behavior for each scenario.

When to use

Consult this page when:

a payment instruction returns a refusal status;
webhook events indicate a processing failure;
clearer messages need to be presented to the user;
the application needs to decide whether to retry or stop the recurrence;
it is necessary to diagnose failures returned by Asaas or by the payer's institution.

How refusals work

When attempting to process an Automatic Pix charge, Asaas sends a payment instruction to the payer's institution.

Depending on the validations performed by the bank or by Asaas itself, the instruction may be refused.

Refusals may occur due to:

insufficient balance or limit;
registration inconsistencies;
authorization restrictions;
operational errors at the financial institution;
attempts outside the allowed time window;
maximum retry attempts exceeded.

📘
Important
A refusal does not necessarily indicate an integration failure.
In many cases, refusals are the result of operational rules imposed by the payer's institution or restrictions associated with the Automatic Pix authorization itself.

Refusals returned by Asaas

Some scenarios are identified by Asaas before settlement.

Refusal reason	Description
PAYMENT_OVERDUE	Charge overdue due to insufficient balance or available limit at the time of the debit.

Refusals returned by the payer's institution

The following refusal reasons are returned by the financial institution responsible for the payer's account.

Refusal reason	Description
EXTERNAL_INSTITUTION_ERROR	Error at the customer's financial institution.
ACCOUNT_CLOSED	Customer's transactional account has been closed.
ACCOUNT_BLOCKED	Customer's transactional account is blocked.
SAME_INSTITUTION_ERROR	Scheduling cannot be requested for accounts that use the same SPI settlement participant.
MAXIMUM_AMOUNT_EXCEEDED	Charge amount exceeds the limit defined by the customer.
AMOUNT_MISMATCH	Charge amount differs from the amount defined in the recurrence.
RECEIVER_CPF_CNPJ_MISMATCH	Recipient's tax identifier differs from the recurrence data.
PAYER_CPF_CNPJ_MISMATCH	Payer's CPF/CNPJ differs from the authorization data.
PARTICIPANT_NOT_REGISTERED	Participant is not registered or unavailable in the SPI.
DUE_DATE_MISMATCH	Due date is incompatible with the recurrence rules.
POST_DUE_DATE_ATTEMPT_NOT_ALLOWED	Scheduling attempt was made outside the allowed window after the due date.
RECEIVED_TOO_EARLY	Request received more than 10 days before settlement.
RECEIVED_TOO_LATE	Request received less than 2 days before settlement.
OTHER	Unknown error returned by the external institution.
OUT_OF_TIME_FRAME_FOR_RETRY	The charge does not allow additional attempts after the due date.
INVALID_RECURRING_PAYMENT_ID	Recurrence identifier does not exist or is invalid.
RECURRING_PAYMENT_NOT_CONFIRMED	The recurrence authorization has not been confirmed by the payer.
PAYMENT_ALREADY_SCHEDULED	There is already a pending settlement request for the charge.
PAYMENT_ALREADY_DONE	The charge has already been settled.
PAYMENT_INSTRUCTION_WITHOUT_AUTHORIZATION	The instruction does not have a valid associated authorization.
EXCEEDED_MAXIMUM_RETRY_ATTEMPTS	Maximum retry attempts after the due date have been exceeded.
PARTICIPANT_ISPB_INVALID	Invalid or nonexistent financial institution ISPB.
INVALID_CUSTOMER_CPF_CNPJ	Invalid CPF/CNPJ.
INCORRECT_CUSTOMER_CPF_CNPJ	Incorrect CPF/CNPJ.

Important behaviors

⚠️
Important
Not every refusal is definitive.
Some scenarios allow new attempts, while others permanently prevent settlement.

For example:

insufficient balance or limit may allow a new attempt;
charges that have already been settled cannot be processed again;
cancellation or absence of authorization prevents new instructions from being created;
registration inconsistencies require data correction before retrying.

Example scenario

A recurring charge is created and the instruction is sent to the payer's institution.

If the customer does not have sufficient balance at settlement time, the following flow may occur:

PAYMENT_CREATED
↓
PIX_AUTOMATIC_RECURRING_PAYMENT_INSTRUCTION_CREATED
↓
PIX_AUTOMATIC_RECURRING_PAYMENT_INSTRUCTION_SCHEDULED
↓
PIX_AUTOMATIC_RECURRING_PAYMENT_INSTRUCTION_REFUSED

The refusal reason can be identified through the event payload or by retrieving the charge.

Best practices

📘
Recommended

Store the returned refusal code.

Avoid exposing raw codes to end users.

Convert refusal codes into user-friendly messages.

Use webhooks to detect refusals in real time.

Do not assume that every refusal is permanent.

Always verify whether the Automatic Pix authorization remains active.

Operational impacts

Refusals may directly impact the financial flow of the integration.

Depending on the returned reason:

the charge may remain pending;
new attempts may be possible;
user action may be required;
registration corrections may be necessary;
future charges may stop being processed if the authorization has been cancelled or expired.

For this reason, refusal codes should be handled individually.

Next steps

After implementing refusal handling, we recommend consulting:

Automatic Pix Webhook Flows.
Automatic Pix events.
Automatic Pix authorizations.
Automatic Pix recurring charges.
Webhook configuration.