GH GambleHub

PIX Бразилия: мгновенные переводы

1) Что такое PIX и почему это важно iGaming

PIX — национальная система мгновенных переводов от Banco Central do Brasil (BCB), доступная 24/7/365 с финализацией за секунды. Для iGaming это:
  • высокий охват пользователей (мобильные банки/кошельки),
  • низкая комиссия и отсутствие чарджбеков как у карт,
  • мгновенные cash-in/cash-out при строгом комплаенсе.
💡 Важно: юридический режим iGaming в Бразилии развивается; платежные потоки всегда строим с учетом местных правил и лицензий по конкретному продукту.

2) Ключевые элементы экосистемы PIX

Chave PIX (ключ): идентификатор получателя — CPF (физ. лицо), CNPJ (юр. лицо), e-mail, телефон или рандомный ключ.
DICT: централизованный реестр ключей PIX.
QR-коды: статический (фикс реквизиты) и динамический (включает сумму/назначение/TTL/параметры).
E2E ID / TxID: уникальные идентификаторы операции/счета для мэппинга и реконсиляции.
Pix Cobrança: «счет к оплате» с датой, штрафами/скидками, похож на инвойс.
Request for Payment (cobV / cobrança com vencimento): запрос платежа в адрес плательщика с TTL.

3) Юзкейсы iGaming

3.1 Депозиты (inbound)

Генерация динамического QR или RfP с полем TxID = `payment_id`.
Прием на CNPJ оператора через PSP/банк; авто-зачисление при вебхуке.
Рекомендация: включать в QR назначение платежа и суммы, TTL 10–30 минут.

3.2 Выплаты (outbound)

Выплата на ключ PIX игрока (CPF/e-mail/телефон/рандом) или напрямую по реквизитам счета.
Перед отправкой — валидировать ключ в DICT, сверить CPF ↔ ФИО (name-match), держать whitelist реквизитов с TTL.

3.3 Сервисные сценарии

Возврат депозита = новая PIX-транзакция (ссылка на исходный `payment_id` в ремиттенсе).
VIP-кэшаут: ETA «секунды/минуты» при онлайн-банке получателя.

4) Лимиты, «ночные окна» и политика рисков

Базовые лимиты per-tx/per-period задаются банком/PSP и профилем клиента; для B2C переводы есть «ночные» ограничения (обычно с вечера до раннего утра) с пониженными капами для снижения социальной инженерии.
Пользователь может повышать лимиты в своем банке, но применяется задержка вступления (анти-фрод).
На стороне мерчанта: RBA-лимиты по сегментам (новый игрок/высокий риск/VIP), velocity по CPF/устройству/IP, гео-паттерны.

5) Возвраты и MED (Mecanismo Especial de Devolução)

Классического chargeback нет, но есть MED — спецмеханизм возврата при подозрении на мошенничество/операционные ошибки.
Схема: банк получателя может заблокировать и вернуть средства по запросу банка отправителя при наличии инцидента (фишинг/вымогательство и т. п.).

Окно MED ограничено (оператором и BCB-правилами), типично используются:
  • временная блокировка (до ~72 ч) на анализ аномалии;
  • расширенное окно для подтвержденных фрод-кейсов (до нескольких недель/месяцев).
  • Практика для iGaming: храните артефакты проверки (логи, KYC, согласия), быстро отвечайте на запросы PSP, ведите журнал MED-исходов.

6) Комплаенс: KYC/AML/санкции/налоги

KYC: валидация CPF (личность) и CNPJ (контрагент/аффилиат), скрининг PEP/adverse media.
AML/KYT: аномалии (rapid in→out, дробление сумм, новые ключи, «мулы»), лимиты и ручной review.
Санкции/OFAC-аналог: локальные и международные списки — check до отправки/зачисления.
Хранение данных: минимизация PII, токенизация, отдельный PII-vault, ретеншн по закону.

7) Интеграция и архитектура

7.1 Слои

Payments Core: инвойсы, статусы, лимиты, идемпотентность.
PIX Gateway (абстракция над PSP): генерация QR/RfP, DICT-валидация, статусы, retry/failover.
Banking/PSP Layer: расчетный счет CNPJ, webhook/statement API.
Risk & Compliance: RBA/AML/KYT, MED-оркестрация.
Accounting & Recon: лейджер, мэппинг `payment_id ↔ e2e/TxID ↔ psp_ref`.
Monitoring: SLA, алерты деградаций, MED-кейсы.

7.2 Потоки

Deposit (QR/RfP): `создать инвойс → QR/RfP (TxID=payment_id) → подтверждение в банке → webhook → зачисление → реконсиляция`.
Payout: `заявка → KYC/AML/DICT/name-match → отправка → статус posted → нотификация → реконсиляция`.

7.3 Оркестрация и фейловер

Два и более PSP на Бразилию; если деградация — fallback на boleto/TED/карточный push (как крайний случай).
Идемпотентность (`payment_id/withdrawal_id`), retry с backoff+jitter, подписанные вебхуки.

8) Валидации и снижение ошибок

DICT-проверка ключа и состояние (активен/перенесен).
Name-match: сверка имени по CPF/CNPJ с банком получателя.
QR-гигиена: проверка структуры EMV-поля, суммы, TTL, запрет повторного использования динамического QR.
Анти-фишинг UX: крупно показывать имя получателя/сумму перед подтверждением, предупреждения о социнженерии.

9) Лейджер и реконсиляция

Идентификаторы: храните TxID, e2e ID, psp_ref, сумму/комиссию/время.
T+0/T+1-сверка: сопоставляйте вебхуки PSP с банковскими выписками/фидами.
Несопоставленные строки → «unmatched-очередь» с SLA.
Возвраты (в т.ч. MED) — как отдельные движения, связать с исходным `payment_id`.

10) Экономика и SLA

Стоимость: обычно ниже карт; считайте Cost per Approved (all-in) = тариф PSP + опер-время (MED/ручные кейсы) + доля fallback.
SLA: p50 «секунды», p95 «минуты»; ночью возможны доп. проверки у банков — закладывайте это в ETA.

11) UX-паттерны (конверсия и доверие)

Автовыбор PIX для Бразилии, четкий ETA («обычно секунды»).
Кнопка “Copiar código PIX” и QR; таймер TTL и «создать новый счет».
Ясные статусы: «ожидание подтверждения → зачислено/отклонено/истекло».
Для выплат — визуальное name-match: «Отправляем João Silva (CPF …123-45)».

12) Метрики и OKR

Approval/Success Rate по депозитам и выплатам.
Time-to-Funds / Time-to-Payout p50/p95.
MED rate и доля успешных/неуспешных возвратов; среднее время обработки.
DICT/name-match fail %, ошибки QR/TTL.
Unmatched recon %, доля ручных кейсов, cost per approved.
Uptime PSP, задержки вебхуков.

13) Анти-паттерны

Один PSP без резерва (SPOF).
Прием «статических» QR на массовых потоках без TTL/TxID → рассыпанная реконсиляция.
Отсутствие DICT/name-match и whitelist → ошибки/фрод.
Нет идемпотентности и подписанных вебхуков → дубли/рассинхрон.
Игнор «ночных» лимитов и RBA-порогов → всплеск MED и блокировок.
Смешение PII и платежных логов без токенизации/RBAC.

14) Чек-лист внедрения (коротко)

  • Контракты с 2+ PSP; поддержка динамического QR/RfP, DICT, вебхуков.
  • TxID = payment_id, TTL для инвойсов; в ремиттенсе — ссылка на инвойс.
  • KYC (CPF/CNPJ), PEP/adverse, KYT/velocity, санкции; whitelist реквизитов.
  • DICT-валидация ключей и name-match перед выплатами.
  • MED-плейбук: роли, артефакты, SLA ответов, журнал исходов.
  • Лейджер и T+0/T+1-реконсиляция; unmatched-очередь и дедлайны.
  • Идемпотентность, backoff+jitter, подписанные вебхуки; fallback (boleto/TED/карта).
  • Дашборды: AR, Time-to-Funds/-Payout, MED, DICT/name-match fail, unmatched, cost.
  • UX: копирование кода, QR, таймер TTL, статусы; антиподсказки против социнженерии.
  • Обучение саппорта: MED, ночные лимиты, частые ошибки QR/DICT.

15) Резюме

PIX — «рабочая лошадка» Бразилии для мгновенных A2A-платежей. Постройте мульти-PSP контур с динамическими QR/RfP, DICT/name-match, строгими RBA-лимитами (в т.ч. ночными), плейбуком MED, и надежной T+0/T+1-реконсиляцией. Такой стек даст вам быструю конверсию депозитов, секундные выплаты и контролируемые риски на крупнейшем рынке Латинской Америки.

Contact

Свяжитесь с нами

Обращайтесь по любым вопросам или за поддержкой.Мы всегда готовы помочь!

Начать интеграцию

Email — обязателен. Telegram или WhatsApp — по желанию.

Ваше имя необязательно
Email необязательно
Тема необязательно
Сообщение необязательно
Telegram необязательно
@
Если укажете Telegram — мы ответим и там, в дополнение к Email.
WhatsApp необязательно
Формат: +код страны и номер (например, +380XXXXXXXXX).

Нажимая кнопку, вы соглашаетесь на обработку данных.