TWINT Швейцария: QR и in-app

1) Контекст и позиционирование TWINT

TWINT — швейцарская схема мобильных A2A-платежей и кошелек, интегрированный с банками страны. Пользователь платит из приложения TWINT/банка: в онлайне — через in-app/App2App или Deep Link, в офлайне — через QR (стандартный «TWINT QR»). Подтверждение выполняется в приложении (SCA: PIN/биометрия), средства списываются со связанного счета/карты и зачисляются мерчанту банковским кредитом.

• Единый бренд/QR для онлайн и POS, высокий охват пользователей.
• Мгновенное онлайн-подтверждение для UX и быстрый settlement (в рамках банковских окон).
• P2P по номеру телефона/контакту внутри экосистемы.
• Низкий фрод за счет SCA и device binding.

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

TWINT (схема/свитч): правила, каталоги участников, маршрутизация.
Банки-участники/эмитенты TWINT: KYC, лимиты и антифрод.
PSP/эквайеры: подключают мерчанта (онлайн/POS), предоставляют API/SDK, веб-хуки и отчеты.
Мерчант: инициирует платеж/запрос, обрабатывает статусы/возвраты, ведет сверку.
Плательщик: подтверждает операции в приложении TWINT/банка.

3) Каналы и пользовательские сценарии

3.1 E-commerce: in-app / Deep Link / App2App

На чекауте мерчант создает платежный intent → отдает Deep Link/кнопку «Оплатить TWINT».
Приложение TWINT открывается (App2App), пользователь подтверждает → возврат в кассу со статусом.
Для десктопа отображается динамический QR per-order; клиент сканирует в приложении и подтверждает.

3.2 POS/офлайн: TWINT QR

Динамический QR на экране кассы/терминала: сумма, orderId, метаданные.
Пользователь сканирует → подтверждает в приложении → мерчант получает online-статус.
Статический QR (сумма вводится вручную) применим для донатов/мелкой розницы, но хуже по сверке.

3.3 P2P «на телефон»

Переводы между физлицами по номеру телефона/контакту с push-подтверждением и мгновенным кредитом получателю.

3.4 Request-to-Pay / Pay-by-Link

Мерчант инициирует запрос на оплату (сумма/назначение/срок) → клиент подтверждает в приложении → оплата проходит по обычному A2A-флоу.

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

Типовые статусы: `initiated` → `pending` → `success` / `failed` / `canceled` / `expired`.
Для QR/десктопа учитывайте таймаут на подтверждение (показывайте таймер).
Settlement: банковский кредит T+0/T+1 в зависимости от окна расчетов/PSP; для отчетности все равно обязателен дневной recon.

5) Лимиты и риск-политики

• Per-transaction, per-day/24h, иногда weekly/monthly.
• Новый получатель/мерчант — пониженные пороги и/или выдержка.
• Канальные лимиты: e-commerce (Deep Link/QR), POS, P2P, Request-to-Pay.
• Velocity/девайс/гео-правила применяются банками и схемой.

6) Экономика и комиссии

Для мерчанта TWINT обычно дешевле типичного картового MDR; условия различаются у PSP (фикс/невысокий %).
Закладывайте расходы на интеграцию/SDK, обработку `pending/expired`, поддержку/ODR и сверку.

7) Возвраты и диспуты

Chargeback (как в картах) отсутствует. Возврат — новая кредитовая операция от мерчанта к плательщику; поддерживаются partial refunds.
Сроки возвратов — банковские (обычно T+0/T+1).
Диспуты/жалобы — по процедурам PSP/банка; храните логи заказа, подтверждение оказания услуги/доставки, связку refund↔order.

8) Безопасность и соответствие

SCA в приложении TWINT/банка (PIN/биометрия), device binding.
Антифрод у банка/PSP: velocity, новые получатели, риск-скоринг.
PII-минимизация и шифрование, HMAC/nonce на веб-хуках, защита от replay, журнал аудита.
Соответствие местным требованиям по платежным услугам и GDPR-сопоставимым нормам защиты данных.

9) Интеграция мерчанта

Варианты

1. Hosted/Embedded у PSP — быстрый старт, in-app/QR из коробки, статусы и ошибки.
2. Server-to-Server + Deep Link/QR — собственный UX, динамический QR per-order, тонкая обработка ошибок.
3. Pay-by-Link / Request-to-Pay — выставление счета ссылкой (email/SMS/мессенджер).

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

10) Сверка и отчетность

Логируйте: `paymentId/transactionId` провайдера, `orderId`, канал (App2App/QR/Link), банк плательщика, статус, сумму/валюту, timestamp, UTR.
От PSP/банка: реестры зачислений/возвратов/коррекций, поздние обновления статусов.
Настройте алерты по рассинхронам и «подвисшим» `pending`.

11) UX-практики

Mobile-first: на мобильных — in-app/App2App; на десктопе — крупный динамический QR с таймером.
Recovery: при `timeout/expired` — безопасный повтор и альтернатива (карта/SEPA/другой A2A).
Квитанция: сумма, время, `transactionId`, канал, UTR, контакты саппорта.
Подсветка риска/лимитов: показывайте пользователю, кто выставил порог — банк или канал.

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

Базовый TWINT — one-off с SCA. Для подписок используют связку: первый платеж TWINT → e-mandate/SEPA DD/Open-Banking для будущих списаний (лимит/периодичность/уведомления).
Дайте пользователю экран управления мандатами (pause/cancel/update) и pre-notification перед списанием.

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

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

14) Архитектура «TWINT Gateway»

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

15) Чек-лист вывода в прод

1. Подключите TWINT у PSP/банка; выберите каналы (App2App/QR/Link).
2. Реализуйте `createPayment`/`requestToPay`, динамический QR, экраны ошибок/лимитов.
3. Подключите webhooks, идемпотентность, ретраи и дедуп событий.
4. Настройте recon (daily + full), хранение UTR/фин-референций.
5. Поддержите partial/full refunds и процедуры ODR.
6. Запустите SLA-дашборды и алерты по конверсии/латентности/подвисшим статусам.
7. Проведите e2e-тесты с основными банками/устройствами и POS (если актуально).

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

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

Резюме

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