What Brazil's Pix Automático Teaches Mexican Recurring-Billing Builders (2026)

The news: Brazil shipped a recurring-payments mandate rail

Pix Automático is Brazil’s central-bank recurring-payments mandate rail, built on top of Pix and live since June 16, 2025 (the go-live date PagBrasil cites). It lets a business set a recurring billing instruction that the payer authorizes once — a mandate, for a fixed or variable amount — after which charges run on that prior consent. If you’ve watched LATAM payments for the last few years, this is a big deal: it’s the first time a major market in the region has a native, instant-rail mandate for automated recurring charges, built and supervised by the central bank itself.

Here’s what it actually does for the user. No re-entering card details, no chasing a failed renewal, no surprise pull from an account they forgot about. The consent is given once, lives with the payer, and the charges follow it.

My thesis, and I’ll label it as opinion: this is the cleanest recurring-billing consent model in LATAM right now. Not because the rail is faster than a card network — it’s that the consent design is honest. The mandate lives with the payer, in their banking app, and they can kill it whenever they want.

I’m writing this as an engineer who ships recurring billing in Mexico, comparing two designs. I am not making a regulatory claim about Mexico, and — spoiler for the honest part below — you cannot use Pix in Mexico. What you can do is steal the UX. Sources here are PagBrasil’s Automatic Pix page and the Banco Central do Brasil.

How the mandate model actually works

The flow is the interesting part, because it’s the opposite of how most card subscriptions feel to a user.

The payee — the business — sets a recurring billing instruction. The payer authorizes it, and that authorization is the mandate. Operationally: the merchant requests authorization through a payment facilitator, the request goes to the Central Bank, then to the user’s bank or wallet, and the user is notified in their own banking app to approve or reject it. The consent is prior and authenticated. No recurring charge starts without it.

After that, the consumer keeps full control. They manage, pause, or cancel their authorizations in a dedicated section of their banking app — a single place that lists everything they’ve said yes to. And charges are scheduled 2–10 days before the due date, per Bacen regulation Instrução Normativa BCB nº 513, so the bank has a window to process and the user isn’t blindsided.

Compare that to the typical card subscription, where consent is a checkbox at the bottom of a checkout page and “cancel” is a support ticket. The difference is structural, and it’s exactly what reduces disputes.

Refunds: two paths, and the honest limit

A recurring system isn’t complete without a way to unwind a bad charge, and here Pix Automático actually has two different paths — which is exactly where most write-ups get sloppy.

Path one is the ordinary dispute. Per PagBrasil, once an amount is debited, a normal “I changed my mind” or “this charge was wrong” refund of a legitimately authorized charge must be negotiated directly with the receiving company. There is no automatic reversal of a completed Pix the way a card chargeback works. That’s a real difference from card networks, and you should know it before you tell customers Pix recurring is “safer.”

Path two is the regulated fraud-and-error rail: MED, the Pix Special Refund Mechanism (Mecanismo Especial de Devolução). MED is scoped to fraud, scams, and operational or system failures — not to general buyer’s-remorse disputes. PSPs are required to process refunds when authorization-management errors are found, and fraud cases are evaluated jointly by the institutions involved. So there’s a named, regulated path for the bad-actor and broken-system cases — not a shrug. Verify the current rules and timelines with the Banco Central do Brasil before you quote specifics.

The design lesson survives the caveat. A recurring system needs both: a clear merchant-side dispute path for ordinary disagreements, and a defined, named process for fraud and authorization errors — so that when something goes wrong, both sides know which path applies instead of improvising. Silence is the thing that turns a refund into a dispute.

The honest pivot: Mexico has no Pix Automático

Now the part where I have to be straight with you: Mexico has no exact Pix Automático equivalent today. None. There is no central-bank recurring-mandate rail you can plug into here.

What we actually have are the closest pieces, and they don’t combine into the same thing:

• CoDi and DiMo — instant-payment rails sitting on top of SPEI. Great for one-off and request-to-pay flows, but there’s no native user-held recurring-mandate layer like Pix Automático’s.
• Card subscriptions — the workhorse, via processors. Consent quality is whatever you build into checkout.
• Domiciliación (direct debit) — bank-account pulls, older and clunkier, with its own authorization process that lives at the bank, not in a clean in-app mandate manager.

None of these is a single, native, user-held recurring-mandate rail with in-app authorization management the way Pix Automático is. So the framing for this whole post is “learn from Brazil,” not “use Pix in Mexico.” For MX today you implement recurring through Mercado Pago subscriptions, Conekta subscriptions, card mandates, or CoDi/DiMo. If you want the full lay of the land, I mapped it in payment gateways in Mexico.

What MX builders should copy

You can’t copy the rail. You can copy the design. Four things transfer cleanly:

• Explicit, user-held consent. The mandate should belong to the payer, captured with clear authenticated consent — not buried in checkout fine print they never read. Record what they agreed to.
• Variable-amount mandates. Don’t only support a fixed monthly figure. Capture consent for variable amounts and cycles, with a cap the user can see, so usage-based billing isn’t a surprise.
• Easy cancel plus in-app management. One-tap cancel, and a visible list of active authorizations the user can pause or revoke anytime. This single screen is the highest-leverage thing you can build.
• A defined refund path. Name the process. State who handles ordinary merchant disputes versus authorization errors versus suspected fraud — the way Brazil separates the direct-with-merchant path from MED. Don’t leave disputes undefined.

Opinion, labeled clearly: the mandate UX is the lesson. Most card-subscription churn and most disputes come from murky consent and hard cancel. Brazil’s clarity is the cheap win — copy it.

Applying it to a Mexican recurring flow

Here’s how I’d build the Pix Automático clarity on top of the rails we actually have in Mexico. None of this needs a new rail — it’s all design and data modeling you layer over Conekta, Mercado Pago, or card tokens.

Step 1 — Capture explicit consent. Record exactly what the user agreed to: the amount rules, the cadence, and who is charging them. Store a timestamp and a consent version so you can prove what they saw.

Step 2 — Store the mandate plus amount rules. Persist a stable mandate_id, the fixed-vs-variable cap, and the cycle — whether you’re backing it with Conekta/Mercado Pago subscriptions or raw card tokens.

Step 3 — Notify before each charge. Send a pre-charge notice. Echo Brazil’s 2–10 day window idea: tell the user what’s coming before you pull, so there are no surprises and far fewer disputes.

Step 4 — Make cancel one tap. Surface an authorizations screen where the user pauses or cancels instantly, and honor it server-side immediately — no support ticket, no friction.

Step 5 — Define your refund path. Document the process: who handles an ordinary merchant dispute, who reviews authorization errors and suspected fraud, the SLA, and how a refund actually gets issued on your provider.

Here’s an illustrative, provider-agnostic mandate data model — this is a sketch to mirror the design, not a real provider API:

// Illustrative only — provider-agnostic mandate model.
// Map mandate_id to a Conekta/Mercado Pago subscription or a card token.
type AmountRule =
  | { kind: "fixed"; amount_mxn: number }
  | { kind: "variable"; cap_mxn: number }; // user sees the cap

interface Mandate {
  mandate_id: string;        // stable id you control
  payer_id: string;
  payee: string;             // who is charging
  amount_rule: AmountRule;   // fixed or variable-with-cap
  cycle: "monthly" | "weekly" | "yearly";
  status: "active" | "paused" | "cancelled";
  consent: {
    version: string;         // which terms they accepted
    accepted_at: string;     // ISO timestamp
    method: "app" | "checkout";
  };
  notify_days_before: number; // e.g. 2–10, echoing Brazil's window
}

// Before each cycle: only charge an active mandate,
// after a pre-charge notice, and never above a variable cap.
function canCharge(m: Mandate, requested_mxn: number): boolean {
  if (m.status !== "active") return false;
  if (m.amount_rule.kind === "fixed")
    return requested_mxn === m.amount_rule.amount_mxn;
  return requested_mxn <= m.amount_rule.cap_mxn;
}

FAQ

Can I use Pix Automático in Mexico? No. It’s a Brazilian rail, supervised by Brazil’s central bank. For MX, use Mercado Pago or Conekta subscriptions, card mandates, or CoDi/DiMo.

Is CoDi/DiMo the same as Pix Automático? No. CoDi and DiMo are Mexican instant-payment rails running over SPEI. They don’t include a native, user-held recurring-mandate layer the way Pix Automático does.

When did Pix Automático launch? June 16, 2025 — the go-live date PagBrasil cites.

Does Pix Automático refund automatically? No. A completed Pix isn’t auto-reversed like a card chargeback. An ordinary refund of an authorized charge is negotiated directly with the receiving company, while fraud and operational-error cases go through MED (the Pix Special Refund Mechanism). Verify the current rules with the Banco Central do Brasil.

Am I getting fiscal or regulatory advice here? No. I’m an engineer doing a design comparison — not a contador and not a regulatory authority. Verify current rules and prices (everything here is as of 2026, confirm current) before you ship.

The takeaway

You can’t ship Pix Automático in Mexico. You can ship its clarity.

User-held mandate, variable-amount consent, one-tap cancel, named refund paths — that’s the copyable part, and it has nothing to do with which rail moves the money. Build it on what you already have — Conekta, Mercado Pago, card mandates, CoDi/DiMo — and you cut the disputes that murky consent quietly creates. If you want more on the rails themselves, start with my integrations guides.