Sofort/Klarna: pay-by-bank

1) რა არის Sofort/Klarna Pay-by-Bank

Sofort (ახლანდელი Klarna Pay Now/Pay-by-Bank) არის A2A ინსტრუმენტი, რომელიც მყიდველს საშუალებას აძლევს გადაიხადოს შეკვეთა პირდაპირ საბანკო ანგარიშიდან ონლაინ ბანკის/მობილური აპლიკაციის საშუალებით. ნაკადი, როგორც წესი, აგებულია issuer-redirect/App2App- ზე, SCA (PSD2) დადასტურებით, ხოლო success იღებს ონლაინ ავტორიზაციას, შემდეგ კი საბანკო სესხს პროვაიდერის ანგარიშებზე/გამოთვლებით.

• დაბალი ღირებულება მუყაოს MDR- სთან შედარებით.
• ონლაინ სტატუსი (წარმატება/წარუმატებლობა) თითქმის დაუყოვნებლივ, ხოლო თანხების ჩარიცხვა ყოველთვის არ არის ინსტანტი (ჩვეულებრივ T + 1/T + 2).
• ფართო გეოგრაფია ევროკავშირში/EEZ (განსაკუთრებით ძლიერი გერმანია/ავსტრია), ათეულობით გამცემი ბანკის მხარდაჭერა.
• მყიდველს აქვს მინიმალური გადახდის დეტალები - ბანკის არჩევანი და დადასტურება.

2) როლები და მონაწილეები

Klarna/Sofort (სქემა/პროვაიდერი): ბანკების როუტინგი, სტატუსები, მოხსენებები, გამოთვლები, გადახდები.
ისუერი (გადამხდელი ბანკი): SCA, ჩამოწერის დადასტურება, ლიმიტები/ანტიფროდი.
Merchant PSP/Acquirer: merchant, API/SDK, webhooks და recon კავშირი.
მერჩანტი (გამყიდველი): გადახდის დაწყება, სტატუსის/დაბრუნების დამუშავება, შერიგება.

3) გადახდის ნაკადები: Redirect და App2App

3. 1 Classic redirect

1. მერკანტის შემოწმება - არჩევანის გაკეთება ბანკში (Sofort/Klarna).
2. ბანკების სია არის ონლაინ ბანკის რედაქცია (ან პროვაიდერის მასპინძელ გვერდზე) SCA.
3. ბანკი ადასტურებს გადახდას სტატუსის მქონე მერჩანტზე დაბრუნების შესახებ (success/failed/canceled/pending).
4. მერჩანტი აფიქსირებს ბრძანებას, როგორც „გადახდილი/მოლოდინი“, ელოდება ვებსაიტზე/ჩარიცხვის ანგარიშს.

3. 2 App2App / Mobile

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

3. 3 Request-to-Pay/Embedded ვარიანტები

რიგი ბანკები ხელმისაწვდომია გადახდის/PIS პროვაიდერის ინტერფეისების საშუალებით (მყიდველი იღებს თხოვნას ბანკის განაცხადში).
PSP- ის Embedded ვიჯეტები ამარტივებს ბანკების ჩამონათვალს, შეცდომებსა და სტატუსებს.

4) ბანკების ლიმიტები და ქცევა

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

5) სტატუსები და ჩარიცხვა

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

6) ზარბაზნები, ნაწილობრივი ზარალი და დავები

Chargeback (როგორც რუქებში) არ არის. დაბრუნება არის ახალი საკრედიტო ოპერაცია გადამხდელის პროვაიდერის მეშვეობით.
მხარს უჭერს პარტიული refunds.
დაბრუნების ვადები - საბანკო (T + 1/T + 2).
დებატები/საჩივრები გადის პროვაიდერის + ODR პროცედურას გადამხდელის ბანკის მეშვეობით; მოამზადეთ შეკვეთის ლოგოები, proof-of-delivery/მომსახურება.

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

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

8) Conconciliation

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

9) UX პრაქტიკა

ბანკების ინდიკატორი: წინასწარ შეავსეთ ბოლო არჩევანი, დალაგეთ მოწყობილობის პოპულარობა/ბანკი.
მობილური პირველი: შესთავაზეთ App2App, fallback - ვებ რედაქტორი.
შეცდომები და გამეორება: მოდით, გასაგები მიზეზები (ლიმიტი, SCA, ტაიმუთი), გამეორების ღილაკი და ალტერნატივა.
Idempotence: 'orderId' + idempotent- ის გასაღები უსაფრთხო გამეორებისთვის.
ქვითარი: თანხა, თარიღი/დრო, 'transaction Id', ბანკი, არხი (App2App/Redirect).

10) განმეორებითი ჩამოწერები და მანდატები

კლასიკური Sofort - ერთჯერადი. განმეორებითი მოდელებისთვის გამოიყენება კავშირი: პირველი გადახდა A2A-e-mandate/SEPA DD/Open Banking PIS მომავლისთვის.
აკონტროლეთ მანდატები (ლიმიტი, სიხშირე, შეტყობინებები), შეინახეთ მიმღების ჟურნალები.

11) შესაბამისობა, უსაფრთხოება, მონაცემები

PSD2/SCA: დადასტურება ბანკში, მოწყობილობის შესყიდვა, ბანკის ანტიფროზი.
PII მინიმიზაცია: შეინახეთ მხოლოდ საჭირო ატრიბუტები; დაშიფვრა PII; HMAC ვებ-ჰუკების ხელმოწერები.
GDPR/Logs: თანხმობა, მოცილების უფლება, ცვლილებების აუდიტი.

12) მაღალი რისკის ვერტიკალები (iGaming- ის ჩათვლით)

ზოგიერთი კატეგორიის Pay-by-Bank- ის ხელმისაწვდომობა შემოიფარგლება მიმწოდებლის/ბანკების მიერ შიდა პოლიტიკოსებისა და ადგილობრივი სამართლის შესაბამისად.
დაელოდეთ შემცირებულ ლიმიტებს, დამატებით. KUS/finmonitoring, შესაძლო hold.
შეინახეთ ალტერნატიული რელსები (ბარათები, SEPA, ღია ბანკინგი A2A, ვაუჩერები) და ტრაფიკის სეგმენტი.

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

1. Hosted/Embedded от PSP/Klarna

სწრაფი დასაწყისი: ვიჯეტი ბანკის არჩევანის, სტატუსის, შეცდომების, შაბათ-კვირის „ყუთიდან“.

2. Server-to-Server + redirect/App2App

მეტი კონტროლი: ბანკების საკუთარი გვერდი, შეცდომების დახვეწილი დამუშავება, საკუთარი QR/Deep Link.

3. Invoises/Request-to-Pay

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

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

14) არქიტექტურა „Sofort/Klarna Gateway“

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

15) Check Life Prode

1. არჩიეთ PSP/არხი Klarna/Sofort ბანკების სწორი გეოგრაფიით.
2. გააცნობიერეთ 'CreatePayment' + ბანკის არჩევანი + redirect/App2App fallback- ით.
3. დააკავშირეთ webhooks, idempotence, tymauts და სტატუსის გამეორება.
4. ჩანაწერების პარამეტრები (daily + full), UTR/ფინის რეფერენდუმის შენახვა.
5. ჩართეთ partial/full refunds და ODR რეგულაციები საფორტეპიანო.
6. მოამზადეთ უარის/ლიმიტების და ალტერნატიული მეთოდების UX სკრიპტები.
7. გამოსცადეთ მობილური ბანკები (iOS/Android) და ძირითადი issuer სამიზნე ქვეყნებში.
8. შეინარჩუნეთ ლიმიტების ცნობარი და ინციდენტების სტატუსის გვერდი.

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

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

რეზიუმე

კონვერტაციისთვის - App2App/Embedded, სტაბილურობისთვის - მკაფიო webhooks + recon.
გაიზიარეთ ონლაინ დადასტურება და ფაქტობრივი სესხი (T + 1/T + 2) ბიზნეს ლოგიკაში.
არ დააფიქსიროთ მკაცრი თანხები: ბანკებისთვის/ქვეყნებისთვის ლიმიტების ჩამორთმევა + რეგულარული განახლება.
ხელმოწერებისთვის გამოიყენეთ პირველი A2A გადახდა - მანდატი, გასაგები UX მენეჯმენტისა და ლიმიტებისთვის.