Swish Швеція: мобайл-платежі

1) Що таке Swish

Swish - національна шведська система мобільних A2A-платежів (оператор Getswish AB) з миттєвими переказами 24/7. Користувач підтверджує операції через BankID (SCA). Підтримуються сценарії P2P (на телефон), P2M для бізнесу (онлайн і офлайн), донати і виплати.

• Адресація за номером телефону (або мерчантським номером/QR), без IBAN в UX.
• Миттєве зарахування на банківський рахунок одержувача; фінальність банківського переказу.
• Низьке тертя: App2App/QR, підтвердження в BankID.
• Широке покриття банків і висока популярність в роздробі/онлайні.

2) Ролі та продукти

Getswish (схема) - правила, каталоги і бренд.
Банки-учасники - випускають/підключають Swish, застосовують ліміти і антифрод.
PSP/еквайєри - підключають мерчантів (Swish Handel/Swish Företag), надають API/SDK, звіти, settlement.

• Swish P2P - перекази між приватними особами.
• Swish Företag - прийом платежів в офлайні (вітрина/POS).
• Swish Handel (Swish for e-commerce) - онлайн-чекаут (QR/App2App/Link).
• Swish Donations - короткі номери/аліаси для пожертвувань.
• Swish Payouts/Disbursements - масові виплати (через банк/PSP).

3) Потоки платежів

3. 1 P2P (push)

1. Відправник вибирає контакт по телефону → вводить суму/повідомлення.
2. Підтверджує в BankID (Face/Touch/код).
3. Отримувач миттєво бачить кредит на рахунку і повідомлення в додатку.

3. 2 P2M: e-commerce (Swish Handel)

• App2App/Deeplink: на чекауті відкриваємо додаток Swish/BankID → підтвердження → повернення в мерчанта.
• QR per-order: генерується динамічний QR (сума, orderId, merchant reference); клієнт сканує камерою Swish → підтверджує в BankID.

3. 3 POS/офлайн (Företag)

Динамічний QR на касі або статичний Swish-номер (сума вручну).
Підтвердження в BankID; чек - у мерчанта і в додатку клієнта.

3. 4 Request-to-Рау/Інвойси

Мерчант відправляє платіжне посилання/запит (в email/SMS/месенджері); клієнт підтверджує в BankID.

3. 5 Виплати (Payouts)

Бізнес відправляє клієнту грошовий переказ на телефонний номер через банк/PSP; застосовується антифрод і ліміти на вихідні.

4) Статуси і таймінги

Типові статуси: `initiated` → `pending` → `success` / `failed` / `canceled` / `expired`.
Для веб-чекауту можливі затримки відповіді програми/BankID → тримайте таймаути і повтор статусу (polling + webhooks).
Settlement для мерчанта - банківський кредит в реальному часі/в найближчий операційний слот в залежності від банку/PSP (для звітності все одно робіть денний recon).

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

• Per-transaction, per-day/24h; іноді weekly/monthly.
• Новий одержувач/новий мерчант - знижені пороги/витримка.
• Канальні ліміти: P2P, e-commerce (App2App/QR), POS, payouts.
• Velocity/девайс/гео-правила і ризик-скоринг на стороні банку.

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

Вартість для мерчанта зазвичай нижче класичного карткового MDR, але умови залежать від банку/PSP (фікс/низький відсоток, плата за QR/SDK/звіти).
Закладіть витрати на підтримку'pending/expired', диспути, recon і моніторинг SLA.

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

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

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

SCA через BankID, device binding, перевірка сім/пристрою банком.
PII-мінімізація: зберігайте тільки необхідні атрибути (телефон/референси), шифруйте PII; доступ - за принципом найменших привілеїв.
Webhooks: HMAC/nonce, захист від replay, тайм-штампи і дедуп подій.
Відповідність PSD2/GDPR та локальним вимогам Finansinspektionen.

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

Варіанти

1. Hosted/Embedded від PSP - швидкий старт, App2App/QR з коробки, статуси і помилки.
2. Server-to-Server + App2App/QR - власний UX, динамічний QR per-order, глибока обробка помилок/повторів.
3. Pay-by-Link/Invoice - відправка посилання/запиту; зручно для сервісів і B2B.

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

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

Логіруйте: 'paymentId/transactionId'провайдера,'orderId', канал (App2App/QR/Link/POS), номер одержувача, статус, сума/валюта, timestamp, UTR.
З PSP/банку: реєстри зарахувань/повернень/корекції, пізні оновлення статусів.
Увімкніть алерти по розсинхронах і аномаліях (подвійні списання, підвислі'pending').

11) UX-патерни

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

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

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

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

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

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

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

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

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

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

Реальні пороги задають банк/PSP і розрізняються за сценаріями.

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

Резюме

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