In-depth penetration testing for Pix flows. Dynamic QR, refunds, DICT, MED and payment initiation.

Pix is not like card payments. Cards have chargebacks, 3-D Secure and dispute resolution through the card network. Pix is instant and irreversible by default. Once the money is gone, it's gone. Getting it back depends on the recipient's good faith (or on MED when fraud is proven).

That changes the risk math. With Pix, any bug that lets someone:

• Change the amount between the QR code and processing
• Race a refund into a double refund
• Trigger a payment without the payer's explicit consent
• Bypass anti-fraud controls by tampering with the payload
• Leak DICT key data at scale

...turns into direct financial loss or regulatory damage. There's no downstream safety net. That's why Pix penetration testing is its own discipline — it requires a methodology that generic scanners don't have.

Regulatory coverage

• Pix Security Manual (BACEN) — all technical requirements
• BCB Resolution 1 — Pix operational risk management
• BACEN Resolution 4,893 (CMN 4,893) — cybersecurity policy for regulated financial and payment institutions
• MED Operating Manual — Special Refund Mechanism
• LGPD Art. 46 (Brazil's data protection law) — protection of Pix key and account holder data

Static QR code

• BR Code payload tampering (Brazil's EMV-based QR standard) — changing the receiver or amount
• Multiple payment abuse — several payers on the same QR code
• QR code reuse after payment
• Phishing through forged QR codes in deep links
• Additional information validation (description tampering)

Dynamic QR code (BR Code with a URL)

• Tampering with the billing URL payload
• SSRF via the client-side URL parser
• Race conditions in generation and expiration
• Replay after expiration
• BOLA on the billing endpoint (accessing another recipient's QR code)
• Recipient key leakage through a public URL

Sending (DICT lookup + transaction)

• BOLA in DICT lookups — leaking account holder data
• Rate limiting on DICT lookups (BACEN requires strict limits)
• Race between the debit and the balance reservation
• Inconsistency between the cached balance (Redis) and the source of truth
• Amount tampering between the confirmation screen and actual submission
• JWT/token replay in the flow between frontend, backend and BACEN

Pix refunds and MED

• Race condition — double refund through duplicate requests
• Refund amount tampering (fraudulent partial refunds)
• Receiver tampering (refunding to a different account)
• MED — abuse of the fraud refund flow
• Refund receipt replay
• Bypassing time-window validation (90 days for MED)

Pix Cobrança and Pix Saque

• BR Code Cobrança — tampering with the due date, interest and late fees
• Pix Saque — limit bypass through payload modification
• Pix Troco — race between the cash-back amount and the purchase amount
• Location validation (PSS — the withdrawal service providers behind Saque/Troco at merchants)

Payment initiation (PISP via Open Finance)

• FAPI 1.0 Advanced — JWS detached signatures, mTLS certificate binding
• Confused deputy between the PISP and the account-holding institution
• Scope escalation in consent
• Consent ID replay
• Payment tampering via the JWE response
• Validation of the payments scope × initiated_payment status

DICT (Directory of Transactional Account Identifiers)

• BOLA — leaking other account holders' keys
• Lookup rate limits — abuse to build a database
• Tampering with portability claims
• Ownership validation bypass (taking over someone else's key)
• Replay of authenticated DICT operations

A Pix penetration test can be purchased standalone or as a module of a fintech pentest. The hourly rate ranges from US$ 150 to US$ 250 depending on stack, testing mode and timeline — larger packages have a lower hourly rate. Invoiced in USD via Wise or international wire transfer: 50% at kickoff, 50% on delivery.