Brazil Pix Validator

Pix is Brazil's instant-payment scheme operated under Banco Central do Brasil rules. A copy-and-paste Pix QR payload is a BR Code string based on EMV TLV fields: each field has a two-digit tag, a two-digit length, and a value. The most important Pix-specific branch is Merchant Account Information tag 26, where tag 26.00 must identify the Pix GUI (br.gov.bcb.pix) and tag 26.01 usually carries the static Pix key.

This workbench keeps all analysis in the browser. It can validate the local shape of CPF, CNPJ, email, phone, and EVP UUID Pix keys; build static BR Code payloads; render scannable QR SVG; parse nested TLV fields; replay CRC16-CCITT-FALSE; compare a payload against a safe fixture; and export a developer JSON snapshot. These checks are useful before fixtures, QA payloads, checkout forms, reconciliation tools, and PSP integration tests reach production systems.

Local validation is intentionally not the same as official verification. A valid key shape or valid QR payload does not prove that the key exists in DICT, that the payee owns it, that a PSP account is active, that settlement will occur, or that a payment request is authorized. Treat ValidoHub output as syntax, structure, and implementation evidence; use official PSP or BCB-connected flows for live existence, ownership, payment, and settlement decisions.

Common checks to run before shipping a Pix integration:

• Paste an email Pix key such as payments@example.com and confirm it normalizes as an email key, not as a BR Code payload.
• Paste CPF and CNPJ fixture keys and verify that invalid check digits fail before the values are allowed into QR generation.
• Generate a static QR payload with amount, merchant name, city, TXID, and optional description; then inspect tag 54, tag 59, tag 60, tag 62.05, and tag 63.
• Use Break CRC to create a negative fixture. The TLV may still parse, but the CRC replay must fail, which is exactly what downstream scanner tests should catch.
• Use Diff sample when a payload looks valid but differs from the safe fixture. The diff highlights changed merchant, key, amount, city, TXID, and description branches without requiring a debugger.

Good Pix QA suites should contain at least one valid static BR Code, one bad CRC payload, one malformed TLV length payload, one valid key-only sample, and one key shape that looks plausible but fails CPF/CNPJ checksum or email/phone syntax.

Can this prove that a Pix key exists?

No. Browser checks can prove local shape, TLV structure, QR rendering, and CRC consistency. DICT existence, ownership, account status, PSP enrollment, payment initiation, and settlement require official connected systems.

Why does a valid QR still need manual integration review?

BR Code syntax is only one layer. Production code also needs PSP rules, merchant onboarding, limits, error handling, refunds, reconciliation, audit logs, privacy controls, and live status handling outside this page.

Why does the workbench store amount as 34.00 instead of 34,00?

EMV tag 54 should carry decimal text with a dot. Locale display can show Brazilian formatting elsewhere, but the payload itself should remain compact and scanner-safe.

Should real customer Pix keys be pasted here?

Avoid it when possible. The lab is browser-local, but production teams should still use fixture-safe keys and mask real values in screenshots, logs, tickets, analytics, and exported examples.

Primary source families to re-check before production:

• Banco Central do Brasil Pix portal: public Pix scheme information and official user-facing context.
• Banco Central technical manuals and API documents: DICT, SPI, Pix API, QR, and communication-document references.
• Pix regulation and normative updates: current constraints, participant obligations, rule changes, and official implementation boundaries.
• EMV QR / BR Code conventions: TLV field structure, merchant-account templates, point-of-initiation method, currency, country, merchant data, additional data, and CRC behavior.

ValidoHub links to official sources where possible, but the browser lab deliberately avoids live official calls. Use the links as implementation references and use PSP/BCB-connected services for any stateful operation.

Implementation checklist for developers:

• Keep a compact canonical payload string for scanners and CRC. Add visual grouping only in UI.
• Compute CRC over the payload ending in 6304, then append the four uppercase hex digits as tag 63.
• Normalize and validate Pix keys before QR assembly, but do not treat local key validity as DICT proof.
• Preserve field boundaries in logs and QA output: raw payload, parsed TLV rows, offsets, lengths, value paths, CRC input, expected CRC, calculated CRC, and warnings.
• Generate negative fixtures deliberately: bad CRC, missing tag 26.00, missing tag 26.01, wrong currency, wrong country, malformed amount, overlong merchant name, and malformed nested lengths.
• Separate static Pix key QR flows from dynamic URL/location flows. Dynamic Pix depends on PSP/network behavior and cannot be simulated by a static browser-only payload checker.

The developer snapshot on this page is designed to be copied into bug reports or automated fixture reviews. It should describe what the browser proved and, just as importantly, what official systems still need to verify.