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 (фіз. 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 .
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).

Натискаючи кнопку, ви погоджуєтесь на обробку даних.