Bizum Іспанія: миттєві переклади

1) Контекст і позиціонування Bizum

Bizum - іспанська міжбанківська схема миттєвих переказів і платежів, вбудована в додатки місцевих банків. Працює 24/7, охоплює P2P (на номер телефону), P2M (оплата в e-commerce/офлайні), а також пожертви/донати та рахунки до оплати. Підтвердження виконується в банківському додатку (SCA/PSD2), кошти рухаються по банківських рейках з негайною авторизацією і швидким зарахуванням.

• Адресація по телефону (alias), без IBAN в UX.
• Миттєвість і фінальність кредитового переказу (chargeback як в картах відсутня).
• P2M: оплата на сайті, в додатку, в офлайні (QR/код Bizum).
• Request-to-Pay: «запит грошей» контактам або клієнтам.

2) Учасники та ролі

Схема Bizum/міжбанківський світч - правила, роутинг, каталоги учасників.
Банки-емітенти - мобільні додатки, SCA, антифрод і ліміти.
PSP/еквайєри - підключення мерчанта до Bizum P2M, API/SDK, звітність і розрахунки.
Мерчант - ініціює платіж/запит, обробляє статуси, веде повернення і звірку.
Платник/отримувач - підтверджує операції в додатку банку.

3) Режими і призначені для користувача сценарії

3. 1 P2P «на телефон»

Відправник вибирає контакт (номер телефону) → вводить суму → підтверджує в своєму банківському додатку → одержувач бачить миттєвий кредит на рахунку.
Для нових одержувачів можливі знижені пороги/доп. див. перевірки.

3. 2 P2M (оплата мерчанту)

E-commerce: на касі вводиться номер телефону Bizum, або відкривається банківський додаток по deeplink; підтвердження - push/SCA.
Офлайн/QR: динамічний QR per-order (сума + orderId), сканування в банківському додатку → підтвердження → онлайн-статус мерчанту.
Код Bizum: мерчант може показувати короткий код/alias для оплати в точці продажів.

3. 3 Request-to-Pay/Інвойси

Мерчант формує запит на оплату (сума/призначення/термін дії) → клієнт підтверджує у своєму банківському додатку → кошти зараховуються як звичайний Bizum-переказ.

3. 4 Донати та рахунки до оплати

Підтримуються короткі коди/alias для благодійності та комунальних/дрібних платежів.

4) Статуси

'initiated'→'pending'( очікується підтвердження/відповідь банку) →'success '/' failed '/' canceled '/' expired'.
Для запитів - додаткові стани'requested '/' expired'.

5) Ліміти та ризик-політики

Єдиної «надсхемної» стелі немає: ліміти задають банки та/або PSP, часто залежать від KYC-рівня, історії та каналу.

Per-transaction, per-day/24h, іноді weekly/monthly.
Новий одержувач/мерчант - знижені пороги, витримка або підтвердження.
Канал/сценарій: окремі ліміти для P2P, P2M (web/app/QR), Request-to-Pay.
Velocity/девайс/гео-правила на стороні банку.

6) Економіка та комісії

Для мерчанта Bizum зазвичай дешевше карткового MDR, але умови залежать від PSP/банку.
Плануйте витрати на інтеграцію/SDK, обробку'pending/expired', підтримку/ODR і recon.

7) Повернення і диспути

Chargeback (як в картах) відсутній для A2A. Повернення - нова кредитова операція від мерчанта до платника (підтримуються partial refunds).
Терміни - банківські (часто T + 0/T + 1).
Диспути/скарги - через процедури PSP і банк; готуйте логи замовлення, підтвердження та комунікацію з клієнтом.

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

PSD2/SCA в банківському додатку: PIN/біометрія, device binding, risk-based аутентифікація у банку.
PII-мінімізація: зберігайте тільки необхідні атрибути (телефон/рефи), шифруйте PII, обмежуйте доступ.
Webhooks: HMAC/nonce, захист від replay, журнал аудиту і ретраї.

9) Інтеграція мерчанта

Варіанти

1. Hosted/Embedded від PSP - швидкий старт: форми Bizum, статуси, помилки з коробки.
2. Server-to-Server + App2App/QR - власний UX, динамічний QR per-order, глибока обробка помилок.
3. Pay-by-Link/Request-to-Pay - рахунок за посиланням (email/SMS/месенджер), підтвердження в банку.

• API: `createPayment`, `requestToPay`, `refund`, `webhook`, `reconcile`.
• Ідемпотентність ('orderId'+ ключ), експоненціальні ретраї, дедуп подій.
• Recon: daily auto-recon + періодичний full-recon; зберігання UTR/фін-референцій.
• SLA-дашборди: конверсія, «pending→success/expired», латентність до зарахування.

10) Звірка і звітність

Логіруйте: 'paymentId/transactionId','orderId', канал (P2P/P2M/QR/App2App/Request), банк платника, статус, сума/валюта, timestamp, UTR/банківське посилання.
Від PSP: реєстри із зарахувань/повернень/корекцій, пізні оновлення статусів.

11) UX-патерни

Mobile-first: для мобайла - App2App; для десктопа - динамічний QR.
Прозорі помилки: ліміт, таймаут, відмова SCA; безпечний повтор + альтернатива (карта/SEPA/інший A2A).
Квитанція: сума, час,'transactionId', канал, UTR, контакти підтримки.
Термін дії запиту/QR: показуйте таймер і сценарій відновлення.

12) Рекуррент і мандати

Базовий Bizum - one-off з SCA. Для підписок використовують зв'язку: перший платіж Bizum → e-mandate/SEPA DD/Open-Banking для наступних списань (ліміт/періодичність/повідомлення, екран управління мандатом).

13) Високоризикові вертикалі (включаючи iGaming)

Доступність/ліміти залежать від політики банків/PSP і місцевого права.
Очікуйте знижені пороги, посилений KYC, можливі hold'и.
Плануйте альтернативні рейки (карти, SEPA, інші PIS) і smart-routing по ризику.

14) Архітектура «Bizum Gateway»

API-шар (REST/GraphQL) для каси та бекофісу.
Черги подій: статус-івенти → білінг/CRM/аналітика.
Security: vault для секретів, IP-allowlist PSP, сувора валідація redirect-URI, анти-replay токени.
Observability: метрики по каналах (App2App/QR/Request),'pending→success/expired', час до settlement.

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

1. Підпишіть канал Bizum у PSP/банку; виберіть канали (App2App/QR/Request).
2. Реалізуйте'createPayment '/' requestToPay', динамічний QR, екрани помилок/лімітів.
3. Підключіть webhooks, ідемпотентність, ретраї і дедуп подій.
4. Налаштуйте recon (daily + full), зберігання UTR/фін-референцій.
5. Підтримайте partial/full refunds і процедури ODR.
6. Запустіть SLA-дашборди та алерти з конверсії/латентності.
7. Проведіть e2e-тести з основними банками/пристроями.

Картка орієнтирів по лімітах

Per-txn / 24h / 7d: зберігати в конфігу, перевіряти до запуску.
Нові одержувачі/мерчанти: знижені пороги/витримка.
Канали: окремі ліміти для P2P, P2M (web/app/QR), Request-to-Pay.
Velocity/ризик: антифрод банку може м'яко відхиляти/уповільнювати операції.

Резюме

Для онлайну - App2App + динамічний QR, для офлайну - QR/код Bizum, для переказів - P2P за номером.
Поділяйте онлайн-підтвердження і фінальний кредит в логіці; будуйте навколо webhooks + recon і partial refunds.
Не фіксуйте суми: підтримуйте конфіги лімітів по банках/каналах і регулярно оновлюйте.
Для підписок - зв'язка перший Bizum → мандат з прозорим управлінням і повідомленнями.