Готівкові ваучери та мережі рітейлу

1) Що це і коли застосовувати

Готівкові ваучери і eCash-мережі дозволяють прийняти оплату без банківських карт і IBAN. Користувач купує передплачений ваучер (PIN) або отримує штрихкод/QR (pay-at-store) і оплачує замовлення в офлайн-точці партнера (кіоск, супермаркет, АЗС, поштове відділення) або в інтернет-банку/АТМ. Гроші надходять мерчанту через PSP/провайдера по банківських рейках; чарджбека немає, ризики фроду мінімальні.

• Цифрових товарів/ігор, контенту, підписок з низьким/середнім чеком.
• Регіонів з високою часткою готівки або низькою карт-пенетрацією.
• Аудиторій, що віддають перевагу приватність/передоплату.

2) Типологія eCash-інструментів

1. PIN-ваучери (передплачені коди):

Приклади: Paysafecard, Neosurf, Flexepin.
UX: введення 16-/10-значного PIN на хостед-формі або оплата з гаманця (myPaysafe/myNeosurf).
Особливості: часткові списання, комбінація декількох PIN, залишок зберігається.

2. Штрихкоди/QR «Оплатити в магазині» (cash payment barcode):

Приклади: paysafecash, локальні мережі (OXXO Pay - MX, RapiPago/PagoFácil - AR, Efecty/Baloto - CO, PayPoint/Payzone - UK, ePay/Paylink - EU та ін.).
UX: мерчант генерує barcode/QR → клієнт платить готівкою на касі → провайдер надсилає підтвердження.
Особливості: чек дійсний обмежений час (expiry), сума фіксована.

3. Reference/Slip для АТМ/онлайн-банкінгу (інвойс-реквізити):

Приклади: Multibanco References — PT, Konbini — JP.
UX: виводиться код/референс + сума, оплата в АТМ/інтернет-банку/магазині-партнері.
Особливості: мінімум фрода, сувора звірка по референсу.

3) Учасники екосистеми

Провайдер/схема (eCash/ваучери): випускає PIN/баркоди, веде каталоги рітейлу, KYC/AML, антифрод, дає API/віджети.
PSP/еквайєр: підключає мерчанта, хостед-каса/SDK, статуси, веб-хуки, реєстри та розрахунки.
Рітейл/каса: прийом готівки/зчитування штрих-коду, синхронізація з провайдером.
Банк/кліринг: розрахунки та зарахування коштів мерчанту.
Мерчант: ініціює оплату/інвойс, обробляє статуси, повернення і recon.

4) Потоки оплати

4. 1 PIN-ваучер (Hosted/Redirect)

1. Checkout → вибір eCash (наприклад, Paysafecard/Neosurf).
2. Redirect/Hosted форма провайдера → введення PIN/вхід в гаманець → підтвердження (SCA/поведінковий скоринг).
3. Повернення в мерчанта: `success/pending/failed/canceled/expired`.
4. Фактичний кредит - за щоденними реєстрами (T + 1/T + 2).

4. 2 Штрихкод/QR «оплатити в магазині»

1. Мерчант створює інвойс: сума + barcode/QR + expiry.
2. Клієнт йде в точку рітейлу і платить готівкою → каса підтверджує операцію провайдеру.
3. Провайдер надсилає мерчанту online-успіх, далі - кредит у реєстрах (T + 0/T + 1).

4. 3 Reference/Slip (ATM/online-banking/конбіні)

1. Генерація референса (entity/reference/amount) + термін дії.
2. Оплата в АТМ/інтернет-банку/магазині-партнері.
3. Online-статус'paid'і наступний settlement в реєстрах.

5) Статуси та розрахунки

Онлайн-статуси: `created` / `pending` / `success|paid` / `failed` / `canceled` / `expired`.
Settlement: зазвичай T + 0/T + 2 банківських днів (за договором/каналом).
У бізнес-логіці поділяйте online-підтвердження і фактичний кредит.

6) Ліміти, KYC і ризик

• Per-transaction, 24h/7d, ліміт на число PIN за оплату/добу.
• Для нових одержувачів/мерчантів - знижені пороги/витримка.
• Гео-правила (країна ваучера vs локація клієнта/мерчанта), velocity, девайс-сигнали.
• Чарджбека немає; диспути - за ODR провайдера/PSP.
• Рекомендація: тримайте конфіг лімітів по країнах/мережах/КУС і не хардкодьте суми.

7) Повернення і часткові списання

Refund = нова кредитова операція (в гаманець eCash/банківським переказом - за правилами провайдера).
Partial refunds зазвичай підтримуються.
Для PIN-ваучерів часто доступні часткові списання і комбінація PIN; для barcode-інвойсів - сума фіксована.

8) Економіка і тарифи

Комісія для мерчанта зазвичай нижче CNP-картового MDR, але варіюється за гео/обсягом/категорією.
Допзатрати: хостед/SDK, реклама точок продажів, саппорт/ODR, обробка'expired/pending', recon.

9) UX-патерни

PIN-оплата: зрозумілий UI для декількох PIN і індикатор залишку; повідомлення про помилки: «невірний/використаний», «ліміт перевищено», «регіон не підтримується».
Barcode/QR: великий код + таймер терміну дії, кнопки «роздрукувати/відправити в messenger/email».
Інструкції офлайн-оплати: 3-4 кроки з логотипами мереж; карта найближчих точок/години роботи.
Стан замовлення: «Очікує оплати» з автооновленням; при'expired'- кнопка «створити новий код».
Квитанція: сума, час,'paymentId', канал (PIN/Barcode/Reference), UTR/реф. з реєстру, контакти саппорту.
Локалізація: валюта/мова/податкові тексти, локальні бренди мереж.

10) Безпека та відповідність

PII-мінімізація: PIN/гаманець вводяться на стороні провайдера (Hosted/Widget).
Веб-хуки: HMAC/nonce, захист від replay, дедуп подій, журнал аудиту.
KYC/AML/GDPR: вікові/лімітні правила для передплачених коштів, санкційні/гео-обмеження.
Антифрод: ліміти по пристрою/сесії, cooling-off, step-up, моніторинг повторюваних PIN/баркодів.

11) Інтеграція та архітектура

Варіанти підключення

1. Hosted/Embedded у PSP/провайдера - швидкий запуск, мінімальна відповідальність за чутливі дані.
2. Server-to-Server + Hosted - власний checkout з контролем статусів, без обробки PIN у вас.
3. Pay-by-Link/Invoice - посилальні оплати і саппорт-кейси.

Бекенд-мінімум

API: `createPayment|createInvoice` (amount + expiry), `refund`, `queryStatus`, `webhook`, `reconcile`.
Ідемпотентність ('orderId'+ ключ), експоненціальні ретраї, DLQ, дедуп веб-хуків.
Каталоги: країни/мережі/ліміти/КУС-рівні, коди помилок, SLA-метрики по каналах.
Observability: конверсія (PIN vs Barcode/Reference), частка'pending→expired', середні таймінги до оплати/settlement, гео-аномалії.

12) Географічні нотатки (орієнтири)

Європа: Paysafecard, paysafecash, Neosurf, PayPoint/Payzone (UK), ePay/Paylink (EU), Multibanco (PT).
ЛатАм: OXXO Pay (MX), RapiPago/PagoFácil (AR), Efecty/Baloto (CO).
Азія: Konbini (JP) і локальні мережі (FamilyMart/Lawson/7-Eleven).

13) Чек-лист виведення в прод

1. Виберіть провайдера/PSP і цільові мережі (PIN/Barcode/Reference), узгодьте тарифи/SLA/settlement.
2. Реалізуйте'createPayment'createInvoice'з expiry, сторінки інструкцій і fallback-сценарії.
3. Підключіть webhooks (HMAC), ідемпотентність, ретраї і дедуп подій.
4. Налаштуйте daily auto-recon + full-recon, зберігайте UTR/фін-референції.
5. Увімкніть partial refunds, ODR-процедури та зрозумілі повідомлення про відмови/ліміти.
6. Запустіть SLA-дашборди (конверсія,'expired', час до оплати/settlement) і алерти по розсинхронах.
7. Проведіть e2e-тести: кілька PIN, прострочений штрих-код, невірна сума, подвійна оплата, повернення частинами.

Картка орієнтирів

Статуси: `created/pending/success|paid/failed/canceled/expired`.
Settlement: зазвичай T + 0-T + 2 за реєстрами PSP/провайдера.
Chargeback: відсутній; refund - окрема кредитова операція.
Ліміти/КУС: залежать від країни/мережі/каналу і профілю клієнта.
Рекурент: перший eCash → мандат (SEPA/Open-Banking/локальний) для наступних списань.

Резюме

Стратегія: eCash-мікс (PIN + barcode/QR + reference) для охоплення готівкової аудиторії і зниження MDR.
Архітектура навколо webhooks + recon, сувора ідемпотентність і зрозумілий UX'pending/expired'.
Конфіги лімітів/КУС і гео-правил - поза кодом, з регулярною актуалізацією.
Для підписок - перший eCash → мандат, прозоре управління і повідомлення для користувача.