PIX Brasilien: Sofortüberweisungen

1) Was ist PIX und warum ist es wichtig, iGaming

• hohe Nutzerabdeckung (mobile Banken/Wallets),
• geringe Provision und keine Chargebacks wie bei Karten,
• Instant Cash-in/Cash-out mit strikter Compliance.

2) Schlüsselelemente des PIX-Ökosystems

Chave PIX (Schlüssel): Die Empfänger-ID ist CPF (Ph. Person), CNPJ (Jr. Person), E-Mail, Telefon oder Zufallsschlüssel.
DICT: zentrale PIX-Schlüsselregistrierung.
QR-Codes: statisch (Fix-Details) und dynamisch (beinhaltet Summe/Ziel/TTL/Parameter).
E2E ID/TxID: Eindeutige Transaktions-/Konto-IDs für Mapping und Rekonsolidierung.
Pix Cobrança: „zu zahlende Rechnung“ mit Datum, Geldbußen/Rabatten, ähnlich einer Rechnung.
Zahlungsanforderung (cobV/cobrança com vencimento): Zahlungsaufforderung an den Zahler mit TTL.

3) iGaming-Benutzer

3. 1 Einlagen (inbound)

Dynamische QR- oder RfP-Generierung mit Feld TxID = 'payment _ id'.
Empfang des CNPJ-Betreibers über PSP/Bank; Automatische Anmeldung beim Webhook.
Empfehlung: Zahlungsziel und Beträge in den QR aufnehmen, TTL 10-30 Minuten.

3. 2 Auszahlungen (outbound)

Auszahlung auf den PIX-Schlüssel des Spielers (CPF/E-Mail/Telefon/Rand) oder direkt auf die Kontodaten.
Vor dem Versand - validieren Sie den Schlüssel in DICT, überprüfen Sie CPF ↔ Name (Name-Match), halten Sie Whitelist-Details mit TTL.

3. 3 Service-Szenarien

Einzahlungsrückerstattung = neue PIX-Transaktion (Link zum ursprünglichen 'payment _ id' im remittens).
VIP-Cashout: ETA „Sekunden/Minuten“ bei der Online-Bank des Empfängers.

4) Grenzwerte, „Nachtfenster“ und Risikopolitik

Die Basislimits per-tx/per-period werden von der Bank/PSP und dem Kundenprofil festgelegt; für B2C-Transfers gibt es „Nacht“ -Beschränkungen (in der Regel vom Abend bis in die frühen Morgenstunden) mit reduzierten Caps, um Social Engineering zu reduzieren.
Der Nutzer kann die Limits bei seiner Bank anheben, es gilt aber eine Einstiegsverzögerung (Anti-Betrug).
Auf der Merchant-Seite: RBA-Limits nach Segment (neuer Spieler/hohes Risiko/VIP), Velocity nach CPF/Gerät/IP, Geo-Muster.

5) Rücksendungen und MED (Mecanismo Especial de Devolução)

Es gibt kein klassisches Chargeback, aber es gibt MED - Special Return Mechanism bei Verdacht auf Betrug/Betriebsfehler.
Schema: Die Bank des Empfängers kann das Geld auf Anfrage der Bank des Absenders sperren und zurückgeben, wenn ein Vorfall vorliegt (Phishing/Erpressung usw.).

• vorübergehende Blockierung (bis zu ~ 72 Stunden) zur Analyse der Anomalie;
• erweitertes Fenster für bestätigte Betrugsfälle (bis zu mehreren Wochen/Monaten).
• Üben Sie für iGaming: Speichern Sie Verifizierungsartefakte (Protokolle, KYC, Einwilligungen), reagieren Sie schnell auf PSP-Anfragen, protokollieren Sie MED-Ergebnisse.

6) Compliance: KYC/AML/Sanktionen/Steuern

KYC: Validierung von CPF (Personality) und CNPJ (Counterparty/Affiliate), PEP/Adverse Media Screening.
AML/KYT: Anomalien (Rapid in→out, Summentrennung, neue Schlüssel, „Maultiere“), Limits und manuelle Überprüfung.
Sanktionen/OFAC-Analog: lokale und internationale Listen - Check vor Versand/Immatrikulation.
Datenspeicherung: PII-Minimierung, Tokenisierung, separates PII-Vault, Retention per Gesetz.

7) Integration und Architektur

7. 1 Schichten

Payments Core: Rechnungen, Status, Limits, Idempotenz.
PIX Gateway (Abstraktion über PSP): QR/RfP-Generierung, DICT-Validierung, Status, Retry/Failover.
Banking/PSP Layer: CNPJ Girokonto, Webhook/Statement API.
Risiko & Compliance: RBA/AML/KYT, MED-Orchestrierung.
Accounting und Recon: lejdscher, mepping ' payment_id ↔ e2e/TxID ↔ psp_ref '.
Monitoring: SLA, Degradationsalerts, MED-Fälle.

7. 2 Ströme

Deposit (QR/RfP): „Erstellung einer Rechnung → QR/RfP (TxID = payment _ id) → Bestätigung bei der Bank → Webhook → Gutschrift → Rekonsolidierung“.
Payout: „Antrag → KYC/AML/DICT/Name-Match → Senden → Status veröffentlicht → Benachrichtigung → Rekonsolidierung“.

7. 3 Orchestrierung und Failover

Zwei oder mehr PSPs auf Brasilien; wenn Degradierung - Fallback auf boleto/TED/card push (als Extremfall).
Idempotenz ('payment _ id/withdrawal _ id'), retry mit backoff + jitter, signierte Webhooks.

8) Validierungen und Fehlerreduzierung

DICT Schlüsselüberprüfung und Status (aktiv/migriert).
Name-Match: Abstimmung des Namens über CPF/CNPJ mit der Bank des Empfängers.
QR-Hygiene: Überprüfung der Struktur des EMV-Feldes, Menge, TTL, Verbot der Wiederverwendung von dynamischem QR.
Anti-Phishing-UX: Groß, um den Namen des Empfängers/den Betrag vor der Bestätigung anzuzeigen, Warnungen vor Social Engineering.

9) Layger und Rekonsilierung

IDs: Speichern Sie TxID, e2e ID, psp_ref, Betrag/Provision/Zeit.
T + 0/T + 1-Abstimmung: PSP-Webhooks mit Kontoauszügen/Zuführungen abgleichen.
Nicht zugeordnete Zeilen → „unmatched-queue“ mit SLA.
Retouren (inkl. MED) - als separate Bewegungen, mit dem Original 'payment _ id' verknüpfen.

10) Wirtschaft und SLA

Kosten: in der Regel niedriger als die Karten; Cost per Approved (all-in) = PSP-Rate + Opernzeit (MED/Handkoffer) + Fallback-Anteil.
SLA: p50 „Sekunden“, p95 „Minuten“; in der Nacht sind zusätzliche Kontrollen bei Banken möglich - legen Sie dies in die ETA.

11) UX-Muster (Conversion und Trust)

Automatische PIX-Auswahl für Brasilien, klare ETA („normalerweise Sekunden“).
Taste „Copiar código PIX“ und QR; TTL-Timer und „neues Konto erstellen“.
Klarer Status: „Warten auf Bestätigung → gutgeschrieben/abgelehnt/abgelaufen“.
Für Auszahlungen - visuelles Namensspiel: „Wir senden João Silva (CPF... 123-45)“.

12) Metriken und OKRs

Approval/Success Rate für Einlagen und Auszahlungen.
Time-to-Funds / Time-to-Payout p50/p95.
MED-Rate und Anteil der erfolgreichen/erfolglosen Rücksendungen; durchschnittliche Bearbeitungszeit.
DICT/name-match fail%, QR/TTL-Fehler.
Unmatched recon%, Anteil manueller Fälle, Kosten pro approved.
PSP-Uptime, Webhook-Latenzen.

13) Anti-Muster

Ein PSP ohne Reserve (SPOF).
Empfang von „statischen“ QRs auf Massenströmen ohne TTL/TxID → verstreute Rekonsilierung.
Keine DICT/name-match und whitelist → Fehler/Betrug.
Es gibt keine Idempotenz und signierte Webhooks → Takes/Rassynhron.
Das Ignorieren von „Nacht“ -Limits und RBA-Schwellenwerten → einen Anstieg von MED und Sperren.
Mischen Sie PII und Zahlungslogs ohne Tokenisierung/RBAC.

14) Checkliste Umsetzung (kurz)

• Verträge mit 2 + PSP; Unterstützung für dynamische QR/RfP, DICT, Webhooks.
• TxID = payment_id, TTL für Rechnungen; in remittens - Verweis auf die Rechnung.
• KYC (CPF/CNPJ), PEP/adverse, KYT/velocity, sanctions; Whitelist-Details.
• DICT-Validierung von Schlüsseln und Name-Match vor Auszahlungen.
• MED-Playbook: Rollen, Artefakte, SLA-Antworten, Outcome-Log.
• Träger und T + 0/T + 1-Sanierung; unmatched-Warteschlange und Fristen.
• Idempotenz, Backoff + Jitter, signierte Webhooks; fallback (boleto/TED/Karte).
• Дашборды: AR, Time-to-Funds/-Payout, MED, DICT/name-match fail, unmatched, cost.
• UX: Code kopieren, QR, TTL-Timer, Status; Antipodien gegen die Sozialingenie.
• Saport-Training: MED, Nachtgrenzen, häufige QR/DICT-Fehler.

15) Zusammenfassung

PIX ist Brasiliens „Arbeitstier“ für sofortige A2A-Zahlungen. Erstellen Sie eine Multi-PSP-Schleife mit dynamischem QR/RfP, DICT/Name-Match, strengen RBA-Limits (inkl. Nacht), einem MED-Playbook und einer zuverlässigen T + 0/T + 1-Reconsilation. Ein solcher Stack gibt Ihnen eine schnelle Umwandlung von Einlagen, Sekundenauszahlungen und kontrollierbaren Risiken im größten Markt Lateinamerikas.