Brazil has the feature that surprises foreign engineering teams more than any other: a card payment here can be split into monthly instalments at checkout, and that instalment count travels with the authorisation. If your payment model assumes one sale equals one charge, it does not fit this market.
| Currency | BRL (Brazilian real) |
|---|---|
| Card networks in common use | Visa, Mastercard, Elo and Hipercard |
| National card scheme | Elo — operated by Elo Serviços S.A. (domestic credit and debit) |
| Other payment methods a checkout has to handle | Pix, Boleto bancário and Card instalments (parcelamento) |
| Payments regulator | Banco Central do Brasil |
| Strong customer authentication | Not mandated nationally; individual acquirers and issuers may still require it |
Instalments are part of the transaction, not a financing add-on
Parcelamento lets a customer split a card purchase across monthly instalments — commonly up to twelve, sometimes more, often advertised as sem juros, without interest, with the merchant absorbing the cost. It is not a separate financing product bolted onto the side. The number of instalments is chosen at checkout and sent with the authorisation, and it changes what the merchant receives and when.
Almost everything downstream has to accommodate this. The order record needs an instalment count, not just an amount. Settlement arrives in pieces over months rather than in one payout, so reconciliation matches many receipts to one sale. A refund on a partly-settled instalment plan is its own small problem. And the price shown on the page is frequently the instalment price rather than the total — “12x R$ 49,90” — which means your display logic, not just your payment logic, has a Brazil-shaped branch in it.
For testing, the important consequence is that the instalment count is an input field with a range, and range inputs are where bugs live. What happens at one instalment? At the maximum? Above the maximum? With a total so small that dividing it produces sub-cent instalments? Those are ordinary boundary tests, and they simply do not exist in a checkout built for a single-charge market.
Elo, Hipercard, and brand detection that has to be told
Brazil has its own card schemes. Elo is the larger, a domestic network issuing both credit and debit, created by a group of Brazilian banks Elo1. Hipercard is a second domestic brand with a strong regional presence.
These carry their own issuer identification ranges, which means brand-detection code assembled from the usual four or five international networks will not recognise them. The failure mode is specific and bad: an Elo card is entered, the detector matches nothing, and the form either shows no brand icon or — worse — rejects the number as invalid. The customer has a working card in their hand and a checkout telling them it is fake.
If you are localising for Brazil, brand detection is not a cosmetic feature you can defer. The mechanics of how prefix ranges map to networks are in the BIN and IIN guide, and the same principle applies here as everywhere: a detector should return “unknown” and let the payment attempt proceed, rather than blocking a card it does not recognise. New ranges get allocated constantly, and a hardcoded table is out of date the day it ships.
Pix, and what it changes
Pix is the instant payment system run by the central bank, live since late 2020 Pix2. It settles in seconds, at any hour, with no card network in the path.
From a checkout perspective Pix is asynchronous in a way cards are not. The customer is shown a QR code or a copy-paste key, leaves your page to approve the transfer in their banking app, and your server learns about it through a webhook. That is a different shape of flow: there is a pending state that can last minutes, a customer who may never come back to your tab, and a success path that arrives out of band. Testing it means testing the waiting state, the webhook-arrives-late case, the customer-pays-twice case, and the expiry.
What Pix does not do is instalments. That, more than anything, is why Brazilian checkouts carry both: Pix for immediacy and lower fees, cards for the instalment plan customers expect on larger purchases.
What to test, concretely
- Instalment boundaries. One, the maximum, one above the maximum, and a total small enough that instalments round badly.
- Elo and Hipercard detection. Confirm your brand detector handles them, and confirm it degrades to “unknown, proceed anyway” rather than rejecting.
- Amount formatting. Comma as the decimal separator, dot as the thousands separator. R$ 1.234,56 is a thousand-odd reais, and a parser that reads it as 1.23 will not warn you.
- CPF input. The taxpayer identification number is routinely collected at checkout and has a check-digit algorithm of its own. The identity generator produces synthetic identity fields for exercising forms like this.
- The Pix pending state. Everything that happens between the QR code being shown and the webhook arriving, including the case where it never does.
The card field itself is the easy part. Generate a Luhn-valid number from the generator and the input behaves normally — it is everything Brazil wraps around the card field that needs the test coverage.
The same is true of every market that has its own payment culture. Germany runs a large share of its commerce through direct debit and invoice, and India bars merchants from storing card numbers outright. A checkout built to handle only cards is a checkout that has not been localised.
The scheme and regulatory details on this page were last checked against provider documentation on . Providers do change what they publish — the official link beside each claim is authoritative.