Trustly: прямі банківські платежі

1) Що таке Trustly

Trustly - провайдер A2A (account-to-account) платежів і виплат, який з'єднує мерчантів з банками платників через redirect/App2App. Покупець підтверджує переказ у своєму банку (SCA по PSD2), мерчант миттєво отримує онлайн-підтвердження, а зарахування коштів приходить через звіти/розрахунки провайдера.

• Низька вартість відносно карткових MDR.
• Широка географія в Європі (Nordics, DACH, Benelux, UK, Southern EU та ін.) + локальні банки.
• Pay-ins і Payouts (включаючи instant payouts для підтримуваних банків).
• Спеціалізовані рішення для iGaming (наприклад, Pay N Play: «депозит → акаунт створений/верифікований»).

2) Продуктова лінійка та сценарії

Pay-in (оплата з банку): redirect/App2App в банк платника → SCA → онлайн-успіх/відмова → наступний кредит.
Payouts (виплати): переказ на рахунок користувача; для ряду банків - миттєво (в іншому випадку T + 1/T + 2).
Pay N Play (iGaming): поєднує депозит з онбордингом: витягуються KYC-сигнали з банківських даних (ім'я, IBAN/BIC та ін.), створюється ігровий аккаунт без окремої реєстрації, можливий Fast Withdraw назад на той же рахунок.
Account Info/Check (опціонально): підтвердження володіння рахунком, перевірка імені/IBAN для anti-mule/ODR.

3) Потоки оплати: Redirect и App2App

3. 1 Classic redirect

1. Checkout мерчанта → вибір банку (directory/пошук).
2. Редирект на сторінку банку або хостований екран → SCA.
3. Повернення на сайт мерчанта зі статусом (success/pending/failed/canceled/expired).
4. Очікування webhook/звіту про зарахування (settlement).

3. 2 App2App (мобільний)

Відкриття банківського додатку через deeplink/intent → підтвердження → повернення.
Вище конверсія і менше кинутих платежів; обов'язково тримайте fallback на веб-редирект.

3. 3 Payouts

Ініціюєте виплату через API з референсом замовлення/виграшу; отримуєте онлайн-статус «прийнято до обробки» і підсумок по webhook/реєстру.
Підтримувати ідемпотентність і карту статусів виплат критично (аж до повторів/відкатів).

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

• Per-transaction і per-day/week ліміти у банку платника.
• Нові одержувачі/мерчанти - знижені пороги і/або витримка.
• Канальні/velocity-правила, гео/девайс-сигнали, анти-мули.
• Для payouts - окремі квоти/порогові перевірки (особливо instant).

5) Статуси та розрахунки: онлайн-успіх vs фактичний кредит

Online status: `success`, `pending`, `failed`, `canceled`, `expired`.
Settlement: фактичне зарахування за звітами/реєстрами Trustly (часто T + 1/T + 2 банківських днів; для деяких напрямків/виплат - instant).
Для критичних послуг застосовуйте модель «умовне виконання до кредиту» (наприклад, активація цифрового товару після підтвердження settlement).

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

Chargeback як в картах відсутній. Повернення - нова кредитова операція через провайдера до платника.
Partial refunds підтримуються.
Терміни повернення - банківські (зазвичай T + 1/T + 2).
Диспути - через ODR-процеси провайдера та банк платника: готуйте логи замовлення, підтвердження доставки/надання послуги, зв'язку payout↔pay -in.

7) Комісії та економіка

Зазвичай фікс/низький відсоток за транзакцію + збори за платформні функції (hosted checkout, звітність, ODR, payouts/instant).
Плануйте витрати на підтримку pending/expiries, ODR і recon.

8) Звірка та звітність (reconciliation)

Зберігайте'paymentId/transactionId'провайдера,'orderId', банк-issuer, тимчасові мітки, UTR/банківську референцію з фін-звітів.
Підключіть webhooks на зміну статусу; запускайте daily auto-recon та періодичний full-recon (рух за зарахуваннями/поверненнями/корекціями).
Для payouts - окремі реєстри і зіставлення з вихідними pay-ins/ігровими балансами.

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

Directory of banks: швидкий пошук, сортування за популярністю/останнім вибором.
Mobile-first: пропонуйте App2App; при відмові - fallback на веб.
Помилки та повтори: чіткі коди причин (ліміт, відмова SCA, таймаут), кнопка повтору, альтернативні методи.
Ідемпотентність: 'orderId'+ ключ ідемпотентності для safe-retry.
Квитанція: сума, час,'transactionId', банк, канал (App2App/Redirect), посилання на саппорт.
Payout UX: прозорі ETA (instant/T + 1), статус трекінг, повідомлення.

10) Pay N Play (для iGaming)

Онбординг без форми реєстрації: користувач вибирає банк, підтверджує депозит, а провайдер віддає в мерчант верифіковані банківські дані (ім'я/рахунок) - створюється ігровий аккаунт.
KYC-сигнали з банку знижують тертя і прискорюють перший депозит.
Fast Withdraw: виплати на той же підтверджений рахунок, часто миттєво.
Потрібні суворі політики відповідальної гри, лімітів депозитів, журнал мандатів і прозорий ODR.

11) Комплаєнс і безпека

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

12) Вертикалі підвищеного ризику

Доступність і ліміти для деяких категорій (включаючи iGaming, крипто і т.п.) залежать від країни і банків-партнерів.
Очікуйте: посилені ліміти, розширений KYC, можливі hold'и і доп. докази.
Тримайте альтернативні рейки (карти, SEPA, open banking PIS від інших провайдерів), маршрутизацію за профілем клієнта.

13) Інтеграція мерчанта: варіанти

1. Hosted/Embedded від провайдера

Швидкий старт, готовий список банків, статуси, помилки, webhooks.

2. Server-to-Server + Redirect/App2App

Більше контролю: власна сторінка вибору банку, глибока обробка помилок, власні deeplink/QR.

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

Відсилання платіжного посилання за email/SMS/месенджером; зручно для В2В/сервісів.

• Ендпоінти: `createPayment`, `refund`, `createPayout`, `queryStatus`, `webhook`, `reconcile`.
• Ідемпотентність і dedupe по'orderId'.
• Ретраї статусів по експоненті, dead-letter на нестабільні відповіді.
• Каталоги: банки/країни, ліміти/коди помилок, SLA-метрики по issuer'ам.

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

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

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

1. Виберіть географії/банки і підключіть канал Trustly у PSP.
2. Реалізуйте'createPayment'+ вибір банку + redirect/App2App з fallback.
3. Підключіть webhooks, таймаути і повтори отримання статусів.
4. Налаштуйте recon (daily + full), зберігання UTR/фін-референцій.
5. Увімкніть partial/full refunds, журнали ODR, процедури саппорту.
6. Для iGaming - запустіть Pay N Play, ліміти депозитів, Fast Withdraw, трекінг відповідальної гри.
7. Побудуйте моніторинг SLA по банках/каналах і алерти по інцидентах.
8. Протестуйте мобільні банки (iOS/Android) і основні issuer'и по країнах.

Картка орієнтирів

Статуси: `success`, `pending`, `failed`, `canceled`, `expired`.
Settlement pay-in: частіше T + 1/T + 2; payouts - instant де доступно, інакше T + 1/T + 2.
Ліміти: per-txn/day/week у issuer’а; нові одержувачі - знижені пороги.
Рекурент: через e-mandate/SEPA DD/Open Banking (перший A2A → мандат).

Резюме

Робіть ставку на App2App/Embedded для конверсії та instant payouts для утримання.
Поділяйте онлайн-підтвердження та фактичний кредит у бізнес-логіці.
Не фіксуйте суми: ведіть конфіги лімітів по банках/країнах/каналах.
Для iGaming використовуйте Pay N Play з прозорим KYC, лімітами і швидкими виплатами.