Наличные ваучеры и сети ритейла

1) Что это и когда применять

Наличные ваучеры и eCash-сети позволяют принять оплату без банковских карт и IBAN. Пользователь покупает предоплаченный ваучер (PIN) или получает штрихкод/QR (pay-at-store) и оплачивает заказ в офлайн-точке партнера (киоск, супермаркет, АЗС, почтовое отделение) либо в интернет-банке/ATM. Деньги поступают мерчанту через 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 для ATM/онлайн-банкинга (инвойс-реквизиты):

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

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. Оплата в ATM/интернет-банке/магазине-партнере.
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.
• Рекомендация: держите конфиг лимитов по странам/сетям/KYC и не хардкодьте суммы.

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, дедуп веб-хуков.
Каталоги: страны/сети/лимиты/KYC-уровни, коды ошибок, 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 — отдельная кредитовая операция.
Лимиты/KYC: зависят от страны/сети/канала и профиля клиента.
Рекуррент: первый eCash → мандат (SEPA/Open-Banking/локальный) для последующих списаний.

Резюме

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