How cardholder CPF blocking works on paid purchases
On card payments, both the buyer's CPF and the cardholder's CPF are checked against the cap.
On purchases paid by credit card, Baila runs a dual identity check: the buyer's CPF (Brazilian taxpayer ID) and the cardholder's CPF both have to sit within the configured limit. That stops scalpers from using other people's cards to buy under their own name and get round the cap.
Why dual identity
Without that protection, the per-CPF cap would be trivial to get round: a scalper only has to use their mother's, their partner's, or a business partner's card to buy whole tiers. The double check closes that shortcut: both the CPF typed at checkout (the buyer) and the cardholder's CPF (the one charged at Asaas, the payment gateway) count against the limit.
How it works, step by step
The buyer opens checkout and fills in their personal details — CPF A (the buyer).
On the payment step they fill in the card details, including CPF B (the cardholder). The two may be the same or different.
Before creating the charge at Asaas, Baila checks: does CPF A have enough headroom inside the cap? Does CPF B?
If either one goes over, the purchase is blocked with the matching message (buyer or cardholder). No charge is created at Asaas.
If both pass, the purchase goes ahead. Once the payment is confirmed, Baila increments the counter for the CPF that paid — the cardholder's, when it differs from the buyer's.
On PIX (no card)
On payments by PIX (Brazil's instant bank transfer) there is no "cardholder" — only the buyer's CPF is checked (single identity). The same rule applies to free events.
LGPD compliance
The CPF is never stored in the clear. The counter uses only an HMAC-SHA256 hash, with a key (a "pepper") held in Secret Manager. The payer's CPF is stored too, but encrypted (AES-256-GCM) — never readable — so it can be re-checked when confirming the payment, on transfers, and during reconciliation. That satisfies Art. 7 (IX) of the LGPD, Brazil's data-protection law.