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-Pay/Инвойсы

Мерчант отправляет платежную ссылку/запрос (в 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 (если актуально).

Карточка ориентиров по лимитам

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

Резюме

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