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 (якщо актуально).

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

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

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 → мандат з прозорим управлінням і повідомленнями.