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/мессенджеру; удобно для B2B/сервисов.

• Эндпоинты: `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, лимитами и быстрыми выплатами.