Trustly: პირდაპირი საბანკო გადახდა

1) რა არის Trustly

Trustly არის A2A (Account-to-account) გადახდისა და გადახდების მიმწოდებელი, რომელიც აკავშირებს გადამხდელ ბანკებს redirect/App2App- ის საშუალებით. მყიდველი ადასტურებს მის ბანკში გადაცემას (SCA on PSD2), მატყუარა დაუყოვნებლივ იღებს ონლაინ დადასტურებას, ხოლო თანხების დაკრედიტება ხდება პროვაიდერის ანგარიშების/გამოთვლების საშუალებით.

• დაბალი ღირებულება მუყაოს MDR- სთან შედარებით.
• ფართო გეოგრაფია ევროპაში (Nordics, DACH, Benelux, UK, Southern EU და სხვ.) + ადგილობრივი ბანკები.
• Pay-ins და 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. მერკანტის შემოწმება - ბანკის არჩევანი (ინდიკატორი/ძებნა).
2. რედაქცია ბანკის გვერდზე ან ჰოსტელის ეკრანზე SCA.
3. დაბრუნება მერჩანტის ვებსაიტზე სტატუსით (success/pending/failed/canceled/expired).
4. Webhook/ჩარიცხვის ანგარიშის მოლოდინი.

3. 2 App2App (მობილური)

საბანკო განაცხადის გახსნა deeplink/intent- ის საშუალებით არის დადასტურება დაბრუნების შესახებ.
კონვერტაციის ზემოთ და ნაკლები მიტოვებული გადახდები; დარწმუნდით, რომ შეინახეთ fallback ვებ - რედაქტორზე.

3. 3 Payouts

დაიწყეთ გადახდა API- ს საშუალებით შეკვეთის/მოგების რეფერენდუმით; მიიღეთ ონლაინ სტატუსი „დამუშავებისთვის“ და შედეგი webhook/რეესტრში.
კრიტიკულია იდემპოტენტურობის შენარჩუნება და გადახდის სტატუსის რუკა (გამეორებამდე/გამოტოვებამდე).

4) ლიმიტები და რისკების პოლიტიკა

• Per-transaction და per-day/week შეზღუდვები გადამხდელის ბანკიდან.
• ახალი მიმღები/მერჩანტები - შემცირებული ბარიერები ან/და გამძლეობა.
• Canal/velocity წესები, geo/devais სიგნალები, anti muls.
• Payouts- ისთვის - ცალკეული კვოტები/ბარიერი შემოწმება (განსაკუთრებით ინსტანცია).

5) სტატუსები და გამოთვლები: ფაქტობრივი სესხის ონლაინ წარმატება

Online status: `success`, `pending`, `failed`, `canceled`, `expired`.
Settlement: ფაქტობრივი ჩარიცხვა Trustly ანგარიშებზე/რეესტრებზე (ხშირად T + 1/T + 2 საბანკო დღე; ზოგიერთი სფეროსთვის/გადასახადებისთვის - Instant).
კრიტიკული მომსახურებისთვის, გამოიყენეთ მოდელი „პირობითი შესრულება სესხამდე“ (მაგალითად, ციფრული საქონლის გააქტიურება settlement- ის დადასტურების შემდეგ).

6) ამაღლება და დებატები

Chargeback, როგორც ბარათებში, არ არის. დაბრუნება - ახალი საკრედიტო ოპერაცია გადამხდელის პროვაიდერის მეშვეობით.
პარტიული რეფუნდები მხარს უჭერს.
დაბრუნების ვადები - საბანკო (ჩვეულებრივ T + 1/T + 2).
დებატები - პროვაიდერის ODR პროცესების და გადამხდელის ბანკის მეშვეობით: მოამზადეთ შეკვეთის ლოგოები, მიწოდების/მომსახურების მიწოდების დადასტურება, payout-pay-in კომუნიკაციები.

7) კომისიები და ეკონომიკა

ჩვეულებრივ, fix/დაბალი პროცენტი გარიგების + საფასურის პლატფორმის ფუნქციებისთვის (მასპინძელი შემოწმება, მოხსენებები, ODR, payouts/instant).
დაგეგმეთ ხარჯების მხარდაჭერა pending/expiries, ODR და ჩანაწერები.

8) Conconciliation

შეინახეთ 'payshid Id/transacition Id' პროვაიდერი, 'orderId', ბანკი-issuer, დროებითი ეტიკეტები, UTR/საბანკო რეფერენდუმი ფინანსური ანგარიშებიდან.
დააკავშირეთ webhooks სტატუსის შეცვლაზე; დაიწყეთ daily auto-recon და პერიოდული full-recon (ჩართვა/დაბრუნება/კორექტირება).
Payouts- ისთვის - ცალკეული რეესტრები და შედარება თავდაპირველ ანაზღაურებასთან/თამაშის ბალანსებთან.

9) UX პრაქტიკა

ბანკების ინდიკატორი: სწრაფი ძებნა, პოპულარობის დახარისხება/ბოლო არჩევანი.
მობილური პირველი: შესთავაზეთ App2App; უარის თქმის შემთხვევაში - ვებ - გვერდზე fallback.
შეცდომები და გამეორებები: მიზეზების მკაფიო კოდები (ლიმიტი, SCA უკმარისობა, ტაიმუტი), გამეორების ღილაკი, ალტერნატიული მეთოდები.
Idempotence: 'orderId' + idempotent- ის გასაღები safe-retry- ისთვის.
ქვითარი: თანხა, დრო, 'transaction Id', ბანკი, არხი (App2App/Redirect), sport ბმული.
Payout UX: გამჭვირვალე ETA (instant/T + 1), ტრეკინგის სტატუსი, შეტყობინებები.

10) Pay N Play (iGaming- ისთვის)

Onboarding რეგისტრაციის ფორმის გარეშე: მომხმარებელი ირჩევს ბანკს, ადასტურებს ანაბარს, ხოლო პროვაიდერი გადასცემს გადამოწმებულ საბანკო მონაცემებს (სახელი/ანგარიში) - იქმნება თამაშის ანგარიში.
ბანკიდან KYC სიგნალები ამცირებს ხახუნებას და აჩქარებს პირველ ანაბარს.
Fast Withdraw: გადახდა იმავე დადასტურებულ ანგარიშზე, ხშირად მყისიერად.
საჭიროა საპასუხისმგებლო თამაშის მკაცრი პოლიტიკოსები, დეპოზიტების შეზღუდვები, მანდატების ჟურნალი და გამჭვირვალე ODR.

11) შესაბამისობა და უსაფრთხოება

PSD2/SCA, მოწყობილობა და ემიტენტის ბანკის ანტიფროზი.
GDPR/PII მინიმიზაცია: შეინახეთ მხოლოდ საჭირო ატრიბუტები, დაშიფვრა PII, შეზღუდეთ წვდომა.
Webhooks: HMAC ხელმოწერები/nonce, დაცვა replay, allowlist IP.
AML/სანქციები: გარიგების მონიტორინგი, ანგარიშის სახელის შემოწმება, ანტი-მულის სიგნალები.

12) მაღალი რისკის ვერტიკალები

ზოგიერთი კატეგორიის (მათ შორის iGaming, კრიპტო და ა.შ.) ხელმისაწვდომობა და ლიმიტები დამოკიდებულია პარტნიორულ ქვეყნებსა და ბანკებზე.
მოსალოდნელია: გამკაცრებული ლიმიტები, გაფართოებული KYC, შესაძლო hold's და დამატებითი მტკიცებულებები.
შეინარჩუნეთ ალტერნატიული რელსები (ბარათები, SEPA, ღია ბანკინგი PIS სხვა პროვაიდერებისგან), მარშრუტიზაცია კლიენტის პროფილის გასწვრივ.

13) ციმციმის ინტეგრაცია: ვარიანტები

1. Hosted/Embedded პროვაიდერისგან

სწრაფი დაწყება, მზა ბანკების სია, სტატუსები, შეცდომები, ვებსაიტები.

2. Server-to-Server + Redirect/App2App

მეტი კონტროლი: ბანკის არჩევის საკუთარი გვერდი, შეცდომების ღრმა დამუშავება, საკუთარი deeplink/QR.

3. Invois/Request-to-Pay

გადახდის ბმულის მითითება email/SMS/მესინჯერთან; მოსახერხებელია B2V/სერვისებისთვის.

• Эндпоинты: `createPayment`, `refund`, `createPayout`, `queryStatus`, `webhook`, `reconcile`.
• Idempotence და dedupe 'orderId'.
• ექსპონენტის სტატუსის retrais, dead-letter არასტაბილური პასუხებისთვის.
• კატალოგები: ბანკები/ქვეყნები, შეცდომების შეზღუდვები/კოდები, SLA მეტრიკა issuer- ზე.

14) არქიტექტურა „Trustly Gateway“

API ფენა (REST/GraphQL) სალაროსა და მოლარე მომსახურებისთვის.
მოვლენების ხაზები: სტატუს-Ivents-billing/CRM/თამაშის უკანა პლანზე/ანალიტიკა.
Observability: კონვერტაცია ბანკების/არხების გასწვრივ, 'pending-success/expired', საშუალო ლატენტობა settlement- ზე, ინსტალაციის ადგილების წილი.
უსაფრთხოება: საიდუმლოების Vault, IP-allowlist, redirect-URI მკაცრი შესაბამისობა, antireplay ნიშნები.

15) Check Life Prode

1. გეოგრაფიის/ბანკების არჩევა და Trustly არხის დაკავშირება PSP- ში.
2. გააცნობიერეთ 'CreatePayment' + ბანკის არჩევანი + redirect/App2App fallback- ით.
3. დააკავშირეთ webhooks, Timauts და სტატუსის გამეორება.
4. ჩანაწერების პარამეტრები (daily + full), UTR/ფინის რეფერენდუმის შენახვა.
5. ჩართეთ partial/full refunds, ODR ჟურნალები, sapport პროცედურები.
6. IGaming- ისთვის - Pay N Play, დეპოზიტების ლიმიტები, Fast Withdraw, საპასუხისმგებლო თამაშის ტრეკინგი.
7. ააშენეთ SLA- ს მონიტორინგი ბანკების/არხების და ალერტების საშუალებით.
8. გამოსცადეთ მობილური ბანკები (iOS/Android) და ქვეყნის მთავარი issuer's.

სახელმძღვანელო ბარათი

Статусы: `success`, `pending`, `failed`, `canceled`, `expired`.
Settlement გადახდა: უფრო ხშირად T + 1/T + 2; payouts - instant არის ხელმისაწვდომი, წინააღმდეგ შემთხვევაში T + 1/T + 2.
ლიმიტები: per-txn/day/week issuer 'a; ახალი მიმღები - შემცირებული ბარიერები.
რეკურენტი: e-mandate/SEPA DD/Open Banking მეშვეობით (პირველი A2A - მანდატი).

რეზიუმე

ფსონი დადეთ App2App/Embedded- ზე კონვერტაციისთვის და ინსტანციის პაკეტების შესანარჩუნებლად.
გაიზიარეთ ონლაინ დადასტურება და ფაქტობრივი სესხი ბიზნეს ლოგიკაში.
არ დააფიქსიროთ თანხები: აიღეთ ლიმიტების კონფისკაცია ბანკების/ქვეყნების/არხების საშუალებით.
iGaming- ისთვის გამოიყენეთ Pay N Play გამჭვირვალე KYC, ლიმიტები და სწრაფი გადახდები.