To run subscriptions with Pix Automático, separate the commercial relationship from the payment authorization and each charge. The payer grants authorization through their payment service provider’s flow; the business sends the instructions that permission allows. The subscription determines access and service terms. Confirmed receipt determines whether the cycle has been paid. Canceling one of these entities must not silently erase or change the others.
This separation lets you explain to customers why a monthly payment failed, whether a scheduled payment still exists, and what cancellation actually stopped. It also prevents a valid authorization from becoming a guarantee of available funds, or an incomplete charge from automatically ending the commercial relationship.
The rules cited were verified on October 22, 2026. This guide’s data model and subscription scenario are educational proposals and do not correspond to real customers. Explaining the concept does not assert that AZPay offers Pix Automático: availability of this payment option and its contract must be confirmed in the documentation for the intended service.
Do Pix Automático, scheduled Pix, and recurring card payments solve the same problem?
All can support an ongoing relationship, but they work differently. According to the Central Bank FAQ on Pix Automático and scheduled Pix (opens in a new tab ↗), with scheduled Pix, the payer schedules future payments; with Pix Automático, they authorize a business, a legal entity, to submit charges with agreed amounts and dates. Not every repeated Pix payment is Pix Automático.
With recurring card payments, a stored credential and card ecosystem rules underpin subsequent charges. Pix Automático authorization is not a card token and cannot be treated as one. Nor is it enough to move the cron job that previously initiated card charges over to Pix.
The guide to recurring payments and card-on-file explains the commercial architecture shared by subscriptions. Here, the focus is the relationship between Pix permission, instructions, scheduling, and receipts. Sharing the subscription domain is useful; erasing differences between methods undermines operations.
For product teams, the choice should consider what customers understand they are authorizing and how they will exercise their controls. For engineering, it requires an adapter that preserves the meaning of states. For finance, it requires knowing which billing period was paid, regardless of how many messages or attempts appeared along the way.
Who authorizes payments, and what can the business consider confirmed?
The Central Bank’s Pix Automático page (opens in a new tab ↗) describes the payer’s advance authorization and control parameters, such as a maximum amount and use of a credit line. The payer’s institution executes payments in accordance with the authorization. A business must not turn the selection of an option on its own screen into proof of completed bank authorization.
In this article’s proposed integration, first record the intent to enroll. Then track the permission request through the provider and confirm the outcome through an authenticated channel. Customers may abandon the journey, decline the proposal, or complete the action on another device. A return screen does not replace server-side verification.
Store the external recurrence reference, the corresponding subscription, the confirmed parameters, and the date when confirmation became known. Also preserve the change history. If the commercial request specified monthly billing and the confirmed record shows a different context, resolve the discrepancy before enabling the cycle.
An authorization does not prove that any future charge will be paid. Funds, limits, instruction compliance, and possible cancellations still matter. The interface can show confirmed enrollment and the expected next cycle without presenting that cycle as money received. This reduces support questions and prevents premature financial recognition.
Which entities must a subscription integration represent?
A conceptual model can include a subscription, external authorization, billing cycle, instruction, attempt, and receipt. These names are internal and illustrative, not AZPay endpoints. The subscription represents the service; the authorization records the permitted context; the cycle states what is due for that period.
The instruction represents a charge that the participant will forward. The attempt tracks execution permitted by the flow. The receipt records the Pix payment actually confirmed. This last entity must preserve its financial identity, including the appropriate external reference, and must not be confused with the cycle identifier.
A stable cycle identity can combine the subscription and billing period. It should survive retries of your job, state changes, and changes in notification channel. If the same cycle appears in two billing batches, the application must recognize that it is still the same obligation.
Also consider versioning the commercial terms. The amount due may have been calculated before a plan change or credit. Persisting that version lets you demonstrate why a particular instruction was issued. Recalculating the past using only the current plan makes it harder to investigate charges and discuss discrepancies with customers.
The Pix objects exposed in Pix API 2.10.0 (opens in a new tab ↗) provide technical references for recurrences, charges, attempts, and receipts. A PSP may offer a different commercial abstraction. Validate its contract instead of assuming all names and transitions will be available in the same way.
How do you prepare and track a billing cycle?
Start with commercial eligibility. Does the subscription allow billing for this period? Is there a credit that changes the amount? Is there a cancellation request that has not yet been applied? Is the authorization confirmed and compatible with the instruction? These checks must precede submission, not arise only when someone complains about the debit.
The BCB implementation guidance, item 2.7 (opens in a new tab ↗) establishes, as a general rule, that instructions must be sent between two and ten calendar days before expected settlement, with exceptions and conditions in Article 5. The commercial scheduler must respect this timing contract and the interfaces the participant actually offers.
Persisting intent before the external call lets you recover from a lost response. Associate the command with the cycle identity and the content sent. A new job run should find the same intent instead of generating another monthly charge merely because the previous process took too long.
After submission, distinguish between an accepted instruction, a known scheduled payment, and a confirmed payment. Success at one stage does not guarantee success at the next. If the integration receives a rejection, record the reason and the stage at which it occurred. This helps distinguish an incompatible instruction from a charge that reached execution but was not settled.
When funds are received, allocate the receipt to the cycle once and publish the corresponding commercial event in a recoverable way. Service access should follow product policy, which may include a grace period or termination at the end of the contracted period. The architecture must support the policy without inventing regulatory rules to justify it.
What should you do when a charge is not completed?
First identify the proven situation. A rejected instruction, unavailable funds, an insufficient limit, an operational error, and an unknown outcome require different actions. Do not mark everything as a final decline or try to recover payment by creating a parallel charge without assessing the flow still in progress.
Article 7 of BCB Normative Instruction 513/2024 (opens in a new tab ↗) explains intraday retries and subsequent attempts. In applicable cases, there is at least one additional attempt between 6 p.m. and 9 p.m. on the same day. Attempts after the due date depend on their inclusion in the recurrence: up to three different dates within seven calendar days, bounded by the next cycle or the end of the recurrence, at the same original amount.
This rule does not authorize merchants to repeat calls indiscriminately. The participant and payment method coordinate part of execution. Your system must determine which attempts already exist, which may still occur, and which action is actually initiated by the business. Avoid running your own retry alongside one already scheduled in the contracted flow.
If you offer an alternative method to settle the monthly charge, associate it with the same obligation and handle concurrent payments. An alternative receipt does not magically cancel an external instruction. Confirm the necessary actions and track any excess if both paths are paid. Commercial recovery is only complete when the financial effects are accounted for.
While the outcome remains unknown, restrict commands that could duplicate payment. Query the resource where supported, correlate events, and route the exception with an owner and next action. Messaging to the subscriber should reflect this uncertainty, without claiming that the customer is late when the integration has not yet verified the outcome.
Does canceling the subscription cancel authorization and all debits?
These are related decisions that must be coordinated. Article 11-Q of the Pix Regulation (opens in a new tab ↗) allows payers to cancel authorization at any time and provides for cancellation when the payee requests termination of the corresponding permission. Commercial cancellation must trigger the relevant financial actions, with confirmation and handling of outstanding items.
Under Articles 8 and 9 of BCB Normative Instruction 513/2024 (opens in a new tab ↗), the payer can request cancellation of a scheduled payment until 11:59 p.m. the previous day; for requests from the payee’s PSP, the cutoff is 10 p.m. Authorization cancellation affects future scheduled payments according to the source and time of the communication; a specific rule applies when information from the payee arrives between 10 p.m. and 11:59 p.m. In that late window, the rule requires cancellation of scheduled payments for days after the day following receipt of the information.
For this reason, do not promise that any commercial cancellation request will stop a debit close to execution. Record the time, confirm what was sent to the provider, and verify which scheduled payments were actually canceled. Times follow Brasília time, according to the participant FAQ. Regulatory times do not eliminate the need to understand your own system’s processing and operational contract.
The BCB participant FAQ, cancellation section (opens in a new tab ↗), clarifies that canceling a specific scheduled payment does not cancel the entire authorization. Retries also have particular characteristics that prevent treating every instruction as a standard scheduled payment that can be canceled individually. The interface should distinguish canceling a charge from ending permission for future charges.
A payment that has already occurred requires a refund assessment, not deletion of its history. Service cancellation may also leave earlier commercial obligations in dispute. Preserve the distinction between collecting an outstanding balance, ending authorization, and refunding an amount: one action must not be used as a shortcut to resolve the others without evidence.
Fictional scenario: a R$79 monthly charge, failure, and cancellation before the next cycle
Imagine a R$79 monthly subscription, with no proration, interest, or credit in this example. Authorization was confirmed and the first cycle was paid. In the next cycle, the participant reports that the charge was not completed due to insufficient funds. The subscription may remain within the commercially defined grace period while finance records R$79 still due for that cycle.
Operations checks the attempts and verifies whether future executions are permitted by the flow. It does not create another R$79 monthly charge to represent each attempt. They all belong to the same obligation. The goal is to recover R$79, not add the amounts of three instructions and conclude that the customer now owes R$237.
Before the following cycle, the customer requests cancellation of the service. The team records the request and its access termination policy, blocks new commercial cycles, and submits actions concerning the permission and existing scheduled payments. It then confirms the external results. Dates in this scenario are relative and do not replace the regulatory cutoffs described above.
If an attempt for the outstanding cycle is paid, the event must be linked to that billing period. It does not automatically reactivate the canceled subscription. If the commercial contract requires that payment to be refunded, the refund will have its own identity and confirmation. If the amount remains legitimately allocated to the previous period, that allocation must be communicated and traceable.
At closure, support should be able to report the access state, external authorization, settled charges, and any amount still being handled. A single canceled label does not answer these questions. The scenario shows why the subscription and Pix infrastructure need to communicate without indiscriminately sharing the same status.
How do you handle changes in plan, amount, and payment method?
A plan change requires comparing the new terms with the confirmed authorization. Do not assume a price increase fits within the permitted limit or that a commercial change replaces external parameters. When the new context requires another action from the payer, guide them through the corresponding journey and wait for confirmation before issuing incompatible instructions.
Credits and prorated billing belong to the commercial calculation. Record the calculation breakdown and its billing period. If the cycle instruction has already been submitted, determine what can still be changed or canceled in the available flow. Creating an additional instruction to compensate for an error without coordinating the original can charge twice for the same adjustment.
When switching from Pix to card or another method, preserve the identity of the outstanding balance and terminate or track earlier commands as appropriate. The new method must not automatically initiate a charge while an earlier execution could still produce a result. History must show which route satisfied the obligation and how any excess was resolved.
How do webhooks and reconciliation keep history consistent?
Each message needs a validated origin, resource identification, and idempotent processing. An event received later may describe an earlier stage. Check versions or external state when arrival order does not allow a safe transition. The payment webhooks guide develops this mechanism.
Maintain the association between authorization, cycle, and received transaction. An authorization change must not overwrite the previous cycle’s receipt; a refund must not erase the original Pix payment. The Pix charge and refund model helps preserve these boundaries.
The payment reconciliation routine should identify cycles paid externally but pending internally, canceled authorizations still marked active, and completed refunds not reflected in financial records. Correcting a lost event must not repeat delivery or renew access for another period.
For each discrepancy, record the observed fact, the sources consulted, the adjustment applied, and evidence of closure. This allows an investigation to resume without depending on the person who received the ticket. It also reveals whether the problem originates in the scheduler, event processing, or the mapping of participant states.
What should you measure and test before running recurring payments?
Measure confirmed enrollment separately from first-cycle payment. Then track success on the due date, recovery by billing period, resolution time for unknown outcomes, and cancellations with outstanding financial actions. Define the denominators: created authorizations, confirmed authorizations, due cycles, and attempts are not the same population.
Test abandoned authorization requests, declines, delayed confirmations, and cancellations reported externally. Simulate rejected instructions, insufficient limits, lost responses, and out-of-order events. Include plan changes with a cycle already prepared, concurrent alternative payments, and cancellation close to the applicable cutoff. Check amounts and commands as well as the final status shown on screen.
Operational acceptance means reconstructing a subscription from enrollment through the last financial movement, explaining who authorized each stage, and preventing a new cycle when conditions no longer permit billing. Consult AZPay Dev Central to assess the intended integration contract. Confirming capabilities and availability of the payment option is part of that assessment, before making any promise to the subscriber.