DiscordStatus
Guias / Guides

Automatic Pix FAQ

See answers to common questions about implementing and managing Automatic Pix.

See answers to common questions about creating charges, payments, retries, Split, and eligibility in Automatic Pix.

1. What happens if the customer pays the charge before the due date?

If the charge is paid by another method up to the day before the due date, the automatic instruction for that cycle is canceled to prevent a new debit.

The authorization remains active for subsequent cycles.

For specific rules during a retry, see Automatic Pix retry process.

2. Can Asaas automatically generate the recurring charges?

Yes. The behavior depends on the paymentCreationMode defined when creating the authorization.

ModeHow charges are created
MANUALYour application creates each charge through the API
SUBSCRIPTIONCharges are generated automatically by a subscription

MANUAL is the default value.

When using SUBSCRIPTION, also provide value when creating the authorization.

In MANUAL mode, link each charge to the authorization using pixAutomaticAuthorizationId.

See the Automatic Pix implementation.

3. Can I use Payment Split?

Yes, in charges created in MANUAL mode. Split cannot be used in the initial QR Code.

  • Initial QR Code: do not send Split when creating the authorization.
  • Charges in MANUAL mode: send the split field when creating each charge linked to the authorization.

See the endpoint: Create new payment.

4. What happens if the payer does not have enough balance or limit on the due date?

The paying institution may make new attempts on the same day, according to the Automatic Pix rules.

If the payment is not completed, the instruction may be refused and the charge remains overdue.

When the authorization is configured with:

retryPolicy = ALLOW_THREE_IN_SEVEN_DAYS

your integration can also request retries on later dates.

See the retry process.

5. How do retries work?

There are two types:

  • intraday: executed automatically by the paying institution on the same day;
  • extra-day: requested by your integration for later dates.

To allow extra-day retries, configure the authorization with:

retryPolicy = ALLOW_THREE_IN_SEVEN_DAYS

This policy allows up to three retries within seven days after the due date, subject to the other rules of the flow.

The configuration must be done when creating the authorization.

See the retry rules and implementation.

6. Can I change the amount of recurring charges?

It depends on the authorization's configuration.

When value is provided, it defines a fixed amount for the charges linked to the authorization.

In MANUAL mode, when the authorization does not have a fixed amount, your application can define the amount when creating each charge, respecting the conditions authorized by the payer.

In SUBSCRIPTION mode, value is required.

See the endpoint: Create an authorization.

7. What are the requirements for using Automatic Pix?

The account must be eligible to use the feature.

The criteria include:

  • having a legal entity (business) account;
  • being approved;
  • having no pending registration issues;
  • having an active CNPJ with the Federal Revenue Service (Receita Federal);
  • having a CNPJ that has been active for at least six months;
  • having no Pix-related restrictions.

Eligibility may change over time.

8. How do I identify a change in eligibility?

Track the event:

PIX_AUTOMATIC_RECURRING_ELIGIBILITY_UPDATED

The eligibility.status field can return:

ELIGIBLE

or:

INELIGIBLE

When the account becomes INELIGIBLE, also use eligibility.ineligibleReasons to identify the returned reasons.

Ineligibility may cancel linked authorizations and instructions, preventing Automatic Pix charges from continuing.

See the Automatic Pix events.

9. Does a refused charge cancel the authorization?

Not necessarily.

A failure in a payment instruction does not automatically end the authorization. While it remains active, subsequent cycles can continue normally.

To identify the cause of the failure, see Refusal Reasons.

10. Do I need to track the Webhooks?

Yes.

Use Webhooks to track:

  • activation, cancellation, and expiration of the authorization;
  • creation and scheduling of instructions;
  • refusals and cancellations;
  • eligibility changes;
  • the result of the charges.

Since delivery follows the at least once model, process events idempotently using the event id.

See the Automatic Pix Webhook Flows.

11. I received PAYMENT_RECEIVED and then PIX_AUTOMATIC_RECURRING_AUTHORIZATION_REFUSED. Why did this happen?

The initial payment was completed, but the payer's institution did not send Asaas the authorization confirmation.

In Journey 3, the payer scans a single QR Code that combines the payment of the initial charge and the authorization of recurring payments. This flow is processed in two steps:

  1. The payer's institution sends the initial payment and Asaas confirms receipt. At this point, the PAYMENT_RECEIVED event is sent.
  2. Next, the payer's institution must send the authorization confirmation. When it is received, the PIX_AUTOMATIC_RECURRING_AUTHORIZATION_ACTIVATED event is sent.

If the payer's institution does not send the confirmation in step 2, the authorization is not activated and you receive the PIX_AUTOMATIC_RECURRING_AUTHORIZATION_REFUSED event.

📘

The initial payment remains valid

The initial charge amount was received normally. Only the automatic debit of subsequent charges was not activated.

Sending this confirmation depends on the payer's institution. Without it, Asaas cannot activate the authorization.

What to do

Refunding the initial payment is not mandatory. You can choose between two options:

  1. Refund the payment and redo Journey 3. Refund the initial charge and create a new authorization. By paying the new QR Code, the payer grants the authorization again.
  2. Keep the payment and create a new authorization in the next cycle. In the next cycle, create a new authorization with immediateQrCode and provide the cycle's charge amount in immediateQrCode.originalValue. By paying the QR Code, the payer grants the authorization again.

Do not link new charges to the refused authorization. The pixAutomaticAuthorizationId field only accepts authorizations with ACTIVE status.

See the endpoint: Refund payment, the endpoint Create an authorization, and the Automatic Pix Webhook Flows.

Next steps

Updated 5 days ago

Did this page help you?