PIX Brasil: traducciones instantáneas

1) Qué es PIX y por qué es importante iGaming

• alta cobertura de usuarios (bancos móviles/carteras),
• baja comisión y ningún charjeback como los de las tarjetas,
• cash-in/cash-out instantáneo con estricto cumplimiento.

2) Elementos clave del ecosistema PIX

Chave PIX (clave): el ID del destinatario es CPF (físico. persona), CNPJ (jure. persona), correo electrónico, teléfono o clave aleatoria.
DICT: registro de claves PIX centralizado.
Códigos QR: estático (datos fix) y dinámico (incluye suma/destino/parámetros TTL/).
E2E ID/TxID: identificadores de transacción/cuenta únicos para mapping y reconsificación.
Pix Cobrança: «factura a pagar» con fecha, multas/descuentos, similar a factura.
Solicitud de pago (cobV/cobrança com vencimento): solicitud de pago al pagador con TTL.

3) Yuzkeys iGaming

3. 1 Depósitos (inbound)

Genera QR o RfP dinámicos con el campo TxID = 'payment _ id'.
Admisión al CNPJ del operador a través del PSP/banco; inscripción automática en webhook.
Recomendación: incluir en QR la asignación del pago y el importe, TTL 10-30 minutos.

3. 2 Pagos (outbound)

Pago de la clave PIX del jugador (CPF/e-mail/teléfono/rand) o directamente según los detalles de la cuenta.
Antes del envío - validar la clave en DICT, comprobar CPF ↔ FIO (name-match), mantener los detalles whitelist con TTL.

3. 3 Escenarios de servicio

Devoluciones de depósitos = nueva transacción PIX (referencia al 'payment _ id' original en la remittense).
Cachaut VIP: ETA «segundos/minutos» con el banco online del destinatario.

4) Límites, «ventanas nocturnas» y políticas de riesgo

El banco/PSP y el perfil del cliente establecen los límites básicos per-tx/per-period; para las transferencias B2C hay restricciones «nocturnas» (generalmente desde la noche hasta la madrugada) con gotas reducidas para reducir la ingeniería social.
El usuario puede aumentar los límites en su banco, pero se aplica el retraso de entrada (anti-frod).
En el lado del merchant: límites RBA por segmentos (nuevo jugador/alto riesgo/VIP), velocity por CPF/dispositivo/IP, geo-patrones.

5) Devoluciones y MED (Mecanismo Especial de Devolução)

No hay un chargeback clásico, pero hay un MED - un mecanismo de devoluciones especiales cuando se sospecha de fraude/errores operativos.
Esquema: el banco del destinatario puede bloquear y devolver fondos a petición del banco del remitente si hay algún incidente (phishing/extorsión, etc.).

• bloqueo temporal (hasta ~ de 72 h) para analizar la anomalía;
• ventana extendida para casos de Frod confirmados (hasta varias semanas/meses).
• Práctica para iGaming: almacenar los artefactos de validación (registros, KYC, consentimiento), responder rápidamente a las solicitudes de PSP, mantener el registro de resultados MED.

6) Cumplimiento: KYC/AML/sanciones/impuestos

KYC: validación de CPF (identidad) y CNPJ (contraparte/afiliado), detección de medios PEP/adverse.
AML/KYT: anomalías (rapid in→out, trituración de sumas, nuevas claves, «mulas»), límites y revisión manual.
Sanciones/OFAC análogo: listas locales e internacionales - check antes del envío/inscripción.
Almacenamiento de datos: minimización de PII, tokenización, PII-vault separado, retoque por ley.

7) Integración y arquitectura

7. 1 Capas

Payments Core: facturas, estados, límites, idempotencia.
Gateway PIX (abstracción sobre PSP): generación de QR/RfP, validación DICT, estados, retry/failover.
Banking/PSP Layer: cuenta corriente CNPJ, API webhook/statement.
Risk & Compliance: RBA/AML/KYT, orquesta MED.
Accounting & Recon: etiqueta, mapping 'payment _ id ↔ e2e/TxID ↔ psp_ref'.
Monitoreo: SLA, alertas de degradación, casos MED.

7. 2 Hilos

Depósito (QR/RfP): 'crear una factura → QR/RfP (TxID = payment _ id) → confirmación en el banco → webhook → acreditación → reconstitución'.
Payout: 'solicitud → KYC/AML/DICT/name-match → envío → estado posted → notificación → reconsificación'.

7. 3 Orquestación y Failover

Dos o más PSP sobre Brasil; si la degradación es fallback en boleto/TED/push de tarjeta (como caso extremo).
Idempotencia ('payment _ id/withdrawal _ id'), retry con backoff + jitter, webhooks firmados.

8) Validación y reducción de errores

Comprobación de clave DICT y estado (activo/migrado).
Name-match: conciliar el nombre por CPF/CNPJ con el banco receptor.
Higiene QR: verificación de la estructura del campo EMV, sumas, TTL, prohibición de reutilización del QR dinámico.
Anti-phishing UX: mostrar en gran medida el nombre del destinatario/cantidad antes de la confirmación, advertencias de socingeneria.

9) Lager y Reconsilación

Identificadores: almacenar TxID, e2e ID, psp_ref, cantidad/comisión/tiempo.
T + 0/T + 1-conciliación: empareje los webhooks PSP con los extractos/feeds bancarios.
Las líneas incompletas → una «cola sin coincidir» con el SLA.
Devoluciones (como MED): como movimientos individuales, asociar con el 'payment _ id' original.

10) Economía y SLA

Costo: generalmente por debajo de las tarjetas; contar Costo por Aplicado (todo-en) = Tarifa PSP + Tiempo-Operario (MED/Casos manuales) + Fracción Fallback.
SLA: p50 «segundos», p95 «minutos»; Por la noche, es posible que los bancos realicen controles adicionales.

11) Patrones UX (conversión y confianza)

La recogida de coches PIX para Brasil, clara ETA («normalmente segundos»).
Botón «Copiar código PIX» y QR; temporizador TTL y «crear una nueva cuenta».
Estados claros: «pendiente de confirmación → acreditado/rechazado/vencido».
Para los pagos - name-match visual: «Enviamos João Silva (CPF... 123-45)».

12) Métricas y OKR

Approval/Tasa de éxito para depósitos y pagos.
Time-to-Funds / Time-to-Payout p50/p95.
La tasa MED y la proporción de devoluciones exitosas/fallidas; tiempo medio de procesamiento.
DICT/name-match fail%, errores QR/TTL.
Recon Unmatched%, proporción de casos manuales, costo per approved.
Uptime PSP, retrasos de webhooks.

13) Anti-patrones

Un PSP sin reserva (SPOF).
La recepción de QR 'estáticos' en flujos masivos sin TTL/TxID → reconsilación desmoronada.
Sin DICT/name-match y whitelist → error/frod.
No hay idempotencia y webhooks firmados → tomas/rassinchron.
Ignora los límites «nocturnos» y los umbrales RBA → un estallido de MED y bloqueos.
Mezcla de registros PII y de pago sin tokenización/RBAC.

14) Lista de verificación de implementación (corta)

• Contratos con 2 + PSP; soporte dinámico QR/RfP, DICT, webhooks.
• TxID = payment_id, TTL para las facturas; en remittense - referencia a la factura.
• KYC (CPF/CNPJ), PEP/adverse, KYT/velocity, sanciones; whitelist detalles.
• La validación DICT de claves y name-match antes de los pagos.
• MED playbook: roles, artefactos, respuestas SLA, registro de resultados.
• Lager y T + 0/T + 1-reconsilación; cola y deduplines sin procesar.
• Idempotencia, backoff + jitter, webhooks firmados; fallback (boleto/TED/tarjeta).
• Дашборды: AR, Time-to-Funds/-Payout, MED, DICT/name-match fail, unmatched, cost.
• UX: copiar código, QR, temporizador TTL, estados; anti-pistas contra la socingeneria.
• Entrenamiento de sapport: MED, límites nocturnos, errores frecuentes de QR/DICT.

15) Resumen

PIX es el «caballo de trabajo» de Brasil para pagos instantáneos A2A. Construya un circuito multi-PSP con los límites dinámicos QR/RfP, DICT/name-match, los límites RBA rigurosos (incluyendo nocturnos), el playbook MED, y la confiable T + 0/T + 1-reconsilación. Tal pila le dará una rápida conversión de depósitos, pagos de segundos y riesgos controlados en el mercado más grande de América Latina.