Automatic Pix

Automatic Pix is an innovative feature of the Pix system, developed by the Central Bank of Brazil, that enables the automation of recurring payments and collections, such as subscriptions, monthly fees, or bills, in a practical and secure manner, ensuring full control for both the payer and the receiver. This solution was designed to address various use cases, such as subscription payments, school fees, gym memberships, condominiums, and more.

This document covers the payer and receiver journeys, detailing the available APIs for each context and the webhooks for event notifications.

Introduction

Automatic Pix supports different usage flows for both those making payments (payer) and those receiving payments (receiver). It enables the creation, modification, cancellation, and querying of recurring transactions, in addition to offering support for dynamic and static QR codes to simplify the payment and collection process.

Benefits for Clients

• Automation of recurring charges, contributing to reduced delinquency.
• Greater control and convenience for payers and receivers.
• Simplified integration through FitBank APIs, allowing efficient management of authorizations, payments, and collections.
• Secure and traceable transactions within the Pix ecosystem, ensuring reliability.

This guide is divided into two main sections:

• Payer Journey: Focused on the payer’s control and convenience, allowing pre-authorization of recurring payments with specific configurations related to the payment method.
• Receiver Journey: Aimed at businesses or receivers looking to automate their clients' recurring payments, simplifying charge management and reducing delinquency.

Important Rules

📌

The following rules are mandatory and must be understood for the best application of the functionality.

• Mandatory Consent: Without the payer's acceptance, there is no Automatic Pix.
• Advance Scheduling: Minimum of 2 days and maximum of 10 days before the desired date.
• 24/7 Operation: Operates continuously, respecting maintenance windows of the financial institution; the exact time of settlement cannot be predicted.
• Failed Attempts: If the debit fails (e.g., insufficient balance), the receiver must notify the payer with the reason and record the attempt for audit purposes.
• Retries: The system automatically performs retries in up to 2 windows on the same day (usually morning and afternoon, without a fixed time); if still unsuccessful, up to 3 attempts per transaction are allowed within 7 consecutive days from the first attempt. Each retry must be notified to the payer with a minimum of 24 hours' notice.
• Changes to Consent by the Payer: Possible changes include notifications, credit line, and/or maximum payment value.
• Changes to Consent by the Receiver: The changes that can be made by the receiver are the payer's name and the date of the first payment.
• Changes in the Scheduling Conditions: It is not possible to alter the parameters of a created scheduling; it is necessary to cancel and create a new one, always respecting the guidelines accepted in the consent.
• Consent Cancellation by the Payer: The payer can revoke consent at any time via the financial institution or the receiver's channel; the receiver must immediately stop future debits and confirm the cancellation to the payer.
• Scheduling Cancellation by the Payer: The payer can cancel a specific debit up to 24 hours before the scheduled date; the receiver must confirm the cancellation and not perform the debit on the scheduled date.
• Automatic Notifications: Confirmations, failures, changes, cancellations, and settlements are sent via webhook to the involved parties.
• Automatic Execution: After acceptance and valid scheduling, the settlement occurs automatically on the scheduled date without requiring new authorization.