A Pix Automático integration needs separate records for the customer’s authorisation, each collection, and the subscription’s service entitlement. An active payment permission does not prove that this month’s charge settled. A cancelled permission does not, by itself, decide what your commercial contract says about access already paid for.
Banco Central do Brasil’s Pix Automático rules describe recurring payment instructions subject to prior, specific payer authorisation. For a subscription business, that creates a useful payment option and a software lifecycle to manage. This article focuses on that lifecycle rather than treating a checkout button as the complete integration.
Begin with three independent questions
Can the business request a collection under the relevant authorisation? What happened to a particular payment instruction? What service should this customer currently receive? Store answers separately, even if the customer interface presents a simple summary.
In an illustrative training membership, a customer authorises recurring payments, a collection is scheduled, and access remains available under a defined paid period. If the permission later changes, the application should review future collection behaviour without silently rewriting the history of an earlier settled payment.
The names of provider statuses vary. Map them into your internal model, retaining the original provider value and reference for investigation. Do not invent a supposedly universal Pix status list and force every integration to match it.
Choose a provider by the lifecycle it exposes
Ask prospective payment providers to demonstrate creation and consultation of authorisations, supported collection journeys, cancellation information, event delivery, and reconciliation. Confirm which functions your merchant account can actually use and which require additional onboarding.
The official Banco Central Pix API repository publishes functional OpenAPI specifications and explicitly points elsewhere for security requirements. It is an important reference, but it does not mean every merchant-facing provider exposes an identical API or that implementing the schema completes security work.
Compare the contracted provider’s documentation with the business journey you intend to offer. Keep authentication requirements, callback verification, testing access, and operational support in the evaluation. A convenient checkout can still leave a difficult recovery process.
Build a timeline that customer support can explain
Suppose a customer contacts support after cancelling in their banking application. Support needs to distinguish a cancellation of future authorisation from an earlier collection, a refund request, or cancellation of the commercial subscription itself.
Create a timeline that joins those events without merging their meaning. Each entry should show the source, provider reference, related subscription, relevant collection, recorded time, and the application’s resulting action. Show pending or unknown outcomes honestly.
Let support follow an approved procedure instead of editing database flags. If an operator grants a temporary access extension, record who authorised it and why. A manual commercial decision should remain visible as such, rather than appearing to be a successful payment.
Make repeated and delayed events harmless
Payment integrations must cope with event delivery that does not match a perfect demonstration. Design your application to recognise events it has already processed and to reconcile contradictory or incomplete information with the provider’s supported consultation facilities.
Use stable references for the subscription, authorisation, collection, and internal action. Before issuing a consequential action such as granting a paid period, verify that the same business action has not already occurred. A repeated notification should not extend access twice.
For ambiguous request outcomes, consult the provider before starting another charge. Whether a retry is permitted, and how it must be identified, depends on the provider contract and interface. Our guide to repeatable data processing explains the broader design principle.
Decide the commercial rules outside the connector
The integration team should not silently choose how long a customer keeps access after a failed collection. Product, finance, and customer support need to agree on grace periods, reminders, suspension, restoration, and cancellation communications.
Keep these policies configurable and versioned where practical. Record which policy governed an action so that a later change does not make historical decisions inexplicable. Any retry timetable must respect the applicable payment arrangement and provider capabilities; do not substitute a generic subscription schedule.
Prepare language for uncertain situations. “We are checking the payment result” is materially different from “payment failed.” Avoid sending conflicting reminders while the collection’s outcome is unresolved.
Reconcile money and service, then launch narrowly
Reconciliation should identify payments with no matching subscription, subscriptions whose expected collection is missing, and access changes that lack an authorised reason. Assign those exceptions to an operational owner with enough evidence to resolve them.
Test a successful enrolment, refusal, cancellation, delayed notification, repeated event, unknown request outcome, and an operator-approved exception. Use the provider’s authorised testing arrangements. Agree the expected account and service state for each scenario before reviewing the implementation.
Start with one subscription product and a clearly defined customer journey. A detailed integration statement of work can keep the payment connector, internal billing rules, and support tools within a reviewable scope.
TuniCyberLabs offers custom software development for integrations and business workflows. Tell us your billing platform, payment provider, and the subscription events you need to connect to discuss a Pix Automático integration with clear operational responsibilities.