Trustly: Direct Bank Payments

1) What is Trustly

Trustly is an A2A (account-to-account) payments and disbursement provider that connects merchants to payer banks via redirect/App2App. The buyer confirms the transfer at his bank (SCA via PSD2), the merchant instantly receives an online confirmation, and the crediting of funds comes through the provider's reports/calculations.

• Low cost relative to card MDRs.
• Wide geography in Europe (Nordics, DACH, Benelux, UK, Southern EU, etc.) + local banks.
• Pay-ins and Payouts (including instant payouts for supported banks).
• Specialized solutions for iGaming (for example, Pay N Play: "deposit → account created/verified").

2) Product line and scenarios

Pay-in (payment from the bank): redirect/App2App to the payer's bank → SCA → online success/refusal → subsequent loan.
Payouts: transfer to the user's account; for a number of banks - instantly (otherwise T + 1/T + 2).
Pay N Play (iGaming): combines deposit with onboarding: KYC signals are extracted from bank data (name, IBAN/BIC, etc.), a game account is created without separate registration, Fast Within is possible back to the same account.
Account Info/Check (optional): Confirm account ownership, verify name/IBAN for anti-mule/ODR.

3) Payment flows: Redirect and App2App

3. 1 Classic redirect

1. Checkout merchant → bank selection (directory/search).
2. Redirect to bank page or hosted screen → SCA.
3. Return to the merchant's site with the status (success/pending/failed/canceled/expired).
4. Waiting for webhook/settlement report.

3. 2 App2App (mobile)

Opening a banking application via deeplink/intent → confirmation → return.
Higher conversion and fewer dropped payments; be sure to keep the fallback on the web redirect.

3. 3 Payouts

Initiate payment through the API with the order/win reference; receive an online status "accepted for processing" and the result for the webhook/registry.
Maintaining idempotency and payment status card is critical (up to repetitions/rollbacks).

4) Limits and risk policies

• Per-transaction and per-day/week limits at the payer's bank.
• New recipients/merchants - reduced thresholds and/or exposure.
• Channel/velocity rules, geo/device signals, anti-mules.
• For payouts - individual quotas/threshold checks (especially instant).

5) Statuses and Settlements: Online Success vs Actual Credit

Online status: `success`, `pending`, `failed`, `canceled`, `expired`.
Settlement: actual crediting by Trustly reports/registers (often T + 1/T + 2 bank days; for some destinations/payouts - instant).
For critical services, use the conditional execution before credit model (for example, activation of a digital product after settlement confirmation).

6) Returns and disputes

Chargeback as in cards is absent. Return - a new credit transaction through the provider to the payer.
Partial refunds are supported.
Return dates are bank (usually T + 1/T + 2).
Disputes - through the provider's ODR processes and the payer's bank: prepare order logs, confirmation of delivery/service provision, communication payout↔pay -in.

7) Commissions and Economics

Usually fixed/low transaction interest + platform fees (hosted checkout, reporting, ODR, payouts/instant).
Plan spending on pending/expiries, ODR and recon support.

8) Reconciliation and reporting

Store the 'paymentId/transactionId' of the provider, 'orderId', issuing bank, timestamps, UTR/bank reference from the fin reports.
Connect webhooks to change status; Run daily auto-recon and periodic full-recon.
For payouts - separate registers and comparison with the original pay-ins/game balances.

9) UX practices

Directory of banks: quick search, sorting by popularity/last choice.
Mobile-first: offer App2App; on failure - fallback to the web.
Errors and repetitions: clear cause codes (limit, SCA failure, timeout), repeat button, alternative methods.
Idempotence: 'orderId' + idempotence key for safe-retry.
Receipt: amount, time, 'transactionId', bank, channel (App2App/Redirect), support link.
Payout UX: transparent ETA (instant/T + 1), tracking status, notifications.

10) Pay N Play (for iGaming)

Onboarding without a registration form: the user selects a bank, confirms the deposit, and the provider gives the verified bank data (name/account) to the merchant - a game account is created.
KYC signals from the bank reduce friction and speed up the first deposit.
Fast Within: Payouts to the same confirmed account, often instantly.
Strict responsible play policies, deposit limits, mandate log, and transparent ODR are required.

11) Compliance and safety

PSD2/SCA, device binding and anti-fraud of the issuing bank.
GDPR/PII minimization: store only necessary attributes, encrypt PII, restrict access.
Webhooks: HMAC signatures/nonce, replay protection, allowlist IP.
AML/sanctions: transaction monitoring, name match, anti-mule signals.

12) High Risk Verticals

Availability and limits for some categories (including iGaming, crypto, etc.) depend on the country and partner banks.
Expect: tightened limits, expanded KYC, possible holds and additional evidence.
Keep alternative rails (cards, SEPA, open banking PIS from other providers), routing along the customer profile.

13) Merchant Integration: Options

1. Hosted/Embedded by provider

Quick start, ready-made list of banks, statuses, errors, webhooks.

2. Server-to-Server + Redirect/App2App

More control: own bank selection page, deep error processing, own deeplink/QR.

3. Request-to-Pay

Sending a payment link by email/SMS/messenger; convenient for B2B/services.

• Эндпоинты: `createPayment`, `refund`, `createPayout`, `queryStatus`, `webhook`, `reconcile`.
• Idempotence and dedupe by 'orderId'.
• Retrai status exponentially, dead-letter on unstable responses.
• Catalogs: banks/countries, limits/error codes, SLA metrics by issuers.

14) "Trustly Gateway" architecture

API layer (REST/GraphQL) for cash desk and cashier services.
Event queues: status events → billing/CRM/gaming backend/analytics.
Observability: bank/channel conversion, 'pending→success/expired', average latency to settlement, share of instant payouts.
Security: vault for secrets, IP-allowlist, strict redirect-URI validation, anti-replay tokens.

15) Output checklist

1. Select geographies/banks and connect the Trustly channel at the PSP.
2. Implement 'createPayment' + bank selection + redirect/App2App with fallback.
3. Connect webhooks, timeouts and status retrievals.
4. Set up recon (daily + full), UTR/fin references storage.
5. Enable partial/full refunds, ODR logs, support procedures.
6. For iGaming - run Pay N Play, deposit limits, Fast Within, tracking responsible play.
7. Build SLA monitoring by bank/channel and alerts by incident.
8. Test mobile banks (iOS/Android) and major issuers by country.

Landmark card

Статусы: `success`, `pending`, `failed`, `canceled`, `expired`.
Settlement pay-in: more often T + 1/T + 2; payouts - instant where available, otherwise T + 1/T + 2.
Limits: per-txn/day/week at issuer'a; new recipients - reduced thresholds.
Recurrence: through e-mandate/SEPA DD/Open Banking (first A2A → mandate).

Summary

Bet on conversion App2App/Embedded and instant payouts to hold.
Separate online confirmation and actual credit in business logic.
Do not fix amounts: keep limit configs by bank/country/channel.
For iGaming, use Pay N Play with transparent KYC, limits and quick payouts.