Trustly: Plăți bancare directe
1) Ce este de încredere
Trustly este un furnizor de plăți și plăți A2A (cont în cont) care conectează comercianții la băncile plătitoare prin intermediul redirect/App2App. Cumpărătorul confirmă transferul la banca sa (SCA prin PSD2), comerciantul primește instantaneu o confirmare online, iar creditarea fondurilor vine prin rapoartele/calculele furnizorului.
Caracteristici cheie:- Cost redus în raport cu MDR-urile cardurilor.
- Geografie largă în Europa (Nordics, DACH, Benelux, Marea Britanie, sudul UE etc.) + bănci locale.
- Plăți și plăți (inclusiv plăți instantanee pentru băncile acceptate).
- Soluții specializate pentru iGaming (de exemplu, Pay N Play: „depozit → cont creat/verificat”).
2) Linia de produse și scenarii
Pay-in (plata de la bancă): la banca plătitorului SCA succesul online/refuzul împrumutului ulterior.
Plăți: transfer în contul utilizatorului; pentru un număr de bănci - instantaneu (altfel T + 1/T + 2).
Pay N Play (iGaming): combină depozitul cu onboarding: semnalele KYC sunt extrase din datele bancare (nume, IBAN/BIC etc.), un cont de joc este creat fără înregistrare separată, Fast Within este posibil înapoi la același cont.
Info cont/Verificați (opțional): Confirmați proprietatea contului, verificați numele/IBAN pentru anti-catârul/SOL.
3) Fluxuri de plată: Redirecționare și App2App
3. 1 Redirecționare clasică
1. Checkout comerciant → selecție bancară (director/căutare).
2. Redirecționați către pagina băncii sau ecranul găzduit → SCA.
3. Întoarceți-vă la site-ul comerciantului cu statutul (succes/în așteptare/eșuat/anulat/expirat).
4. Așteptare raport webhook/decontare.
3. 2 App2App (mobil)
Deschiderea unei aplicații bancare prin deeplink/intenție → confirmare → returnare.
conversie mai mare și mai puține plăți scăzute; asigurați-vă că pentru a păstra rezerva pe web redirecționa.
3. 3 Plăți
Inițiați plata prin API cu referința comandă/câștig; primiți un statut online „acceptat pentru procesare” și rezultatul pentru webhook/registry.
Menținerea idempotenței și a cardului de stare de plată este esențială (până la repetări/rollback-uri).
4) Limite și politici de risc
Nu există un plafon unic: există limite privind emiterea băncilor și politicile furnizorilor. De obicei găsite:- Per-tranzacție și limitele pe zi/săptămână la banca plătitorului.
- Noi destinatari/comercianți - praguri reduse și/sau expunere.
- Reguli de canal/viteză, semnale geo/dispozitiv, anti-catâri.
- Pentru plăți - cote individuale/cecuri prag (în special instant).
5) Statusuri și decontări: Succes online vs Credit actual
Status online: 'succes', 'în așteptare', 'eșuat', 'anulat', 'expirat'.
Decontare: creditare efectivă prin rapoarte/registre Trustly (adesea T + 1/T + 2 zile bancare; pentru unele destinații/plăți - instant).
Pentru serviciile critice, utilizați execuția condiționată înainte de modelul de credit (de exemplu, activarea unui produs digital după confirmarea decontării).
6) Returnări și dispute
Chargeback ca în cărți este absent. Retur - o nouă tranzacție de credit prin intermediul furnizorului către plătitor.
Sunt suportate restituiri parțiale.
Datele de returnare sunt bancare (de obicei T + 1/T + 2).
Litigii - prin procesele SOL ale furnizorului și banca plătitorului: pregătirea jurnalelor comenzii, confirmarea livrării/prestării serviciului, comunicarea payout↔pay -in.
7) Comisioane și economie
De obicei, dobânda de tranzacție fixă/scăzută + comisioanele platformei (checkout găzduit, raportare, SOL, plăți/instant).
Planul de cheltuieli pe în așteptare/cheltuieli, SOL și sprijin de recunoaștere.
8) Reconciliere și raportare
Stocați 'paymentId/transactionId' al furnizorului,' orderId', emitent bank, timestamps, UTR/bank reference from the fin reports.
Conectați cârlige web pentru a schimba starea; Rulați zilnic auto-recunoaștere și periodic full-recon.
Pentru plăți - registre separate și comparație cu soldurile inițiale de plată/joc.
9) Practici UX
Directorul băncilor: căutare rapidă, sortare după popularitate/ultima alegere.
Mobile-first: oferta App2App; pe eșec - rezervă la web.
Erori și repetiții: coduri de cauză clare (limită, eșec SCA, timeout), buton repetare, metode alternative.
Idempotence: 'orderId' + cheie de idempotence pentru siguranță-încercați din nou.
Chitanta: suma, timp, 'tranzactionId', banca, canal (App2App/Redirect), link de suport.
Plata UX: ETA transparent (instant/T + 1), starea de urmărire, notificări.
10) Pay N Play (pentru iGaming)
Onboarding fără un formular de înregistrare: utilizatorul selectează o bancă, confirmă depozitul, iar furnizorul dă datele bancare verificate (nume/cont) comerciantului - se creează un cont de joc.
Semnalele KYC de la bancă reduc frecarea și accelerează primul depozit.
Fast Within: Plăți în același cont confirmat, de multe ori instantaneu.
Sunt necesare politici de joc strict responsabile, limite de depozit, jurnalul de mandate și SOL transparente.
11) Conformitate și siguranță
PSD2/SCA, legarea dispozitivelor și antifrauda băncii emitente.
Minimizarea GDPR/PII: stocați numai atributele necesare, criptați PII, restricționați accesul.
Webhooks: semnături HMAC/nonce, protecție reluare, IP allowlist.
AML/sancțiuni: monitorizarea tranzacțiilor, potrivirea numelui, semnale anti-catâri.
12) verticale cu risc ridicat
Disponibilitatea și limitele pentru anumite categorii (inclusiv iGaming, cripto etc.) depind de țară și de băncile partenere.
Așteptați-vă: limite înăsprite, KYC extins, posesii posibile și dovezi suplimentare.
Păstrați șine alternative (carduri, SEPA, PiS open banking de la alți furnizori), rutare de-a lungul profilului clientului.
13) Integrarea comerciantului: Opțiuni
1. Găzduit/încorporat de furnizor
Pornire rapidă, listă gata făcută de bănci, statusuri, erori, cărți web.
2. Server-to-Server + Redirect/App2App
Mai mult control: pagina proprie de selecție a băncii, procesarea erorilor profunde, propria deeplink/QR.
3. Cerere-la-plată
Trimiterea unui link de plată prin e-mail/SMS/messenger; convenabil pentru B2B/services.
Componente backend necesare:- Эндпоинты: 'createPayment', 'restituire', 'createPayout', 'queryStatus', 'webhook', 'reconciliere'.
- Idempotența și dedupe prin "orderId'.
- Statutul Retrai exponențial, mort-scrisoare pe răspunsuri instabile.
- Cataloage: bănci/țări, limite/coduri de eroare, valori SLA de către emitenți.
14) Arhitectura „Trustly Gateway”
Strat API (REST/GraphQL) pentru casierie și servicii de casierie.
Cozi de evenimente: evenimente de stare → facturare/CRM/backend de jocuri/analytics.
Observabilitate: conversie bancă/canal, 'pending→success/expired', latență medie în decontare, cota de plăți instantanee.
Securitate: seif pentru secrete, IP-allowlist, validare strictă redirect-URI, jetoane anti-reluare.
15) Lista de verificare de ieșire
1. Selectați geografii/bănci și conectați canalul Trustly la PSP.
2. Implementați 'createPayment' + selecție bancară + redirect/App2App cu rezervă.
3. Conectați webhooks, timeout-uri și recuperări de stare.
4. Configurați recunoașterea (zilnică + completă), stocarea referințelor UTR/fin.
5. Activați rambursările parțiale/complete, jurnalele SOL, procedurile de asistență.
6. Pentru iGaming - rulați Pay N Play, limitele de depunere, Fast Within, urmărirea jocului responsabil.
7. Construiți monitorizarea SLA prin bancă/canal și alerte prin incident.
8. Testați băncile mobile (iOS/Android) și emitenții majori pe țări.
Carte de reper
Статусы: „succes”, „în așteptare”, „eșuat”, „anulat”, „expirat”.
Decontare pay-in: mai des T + 1/T + 2; plăți - instant unde este disponibil, altfel T + 1/T + 2.
Limite: per-txn/zi/săptămână la emitent 'a; noi destinatari - praguri reduse.
Recurență: prin e-mandat/SEPA DD/Open Banking (primul mandat → A2A).
Rezumat
Pariați pe App2App/Embedded de conversie și plăți instantanee pentru a deține.
Confirmarea online separată și creditul real în logica de afaceri.
Nu fixați sumele: păstrați configurațiile limită după bancă/țară/canal.
Pentru iGaming, utilizați Pay N Play cu KYC transparent, limite și plăți rapide.