Sofort/Klarna: pay-by-bank

1) Sofort/Klarna Pay-by-Bank nima

Sofort (hozirgi Klarna Pay Now/Pay-by-Bank) - A2A vositasi bo’lib, xaridorga buyurtmani o’z bank hisobvarag’idan to’g «ridan to’g» ri onlayn-bank/mobil ilova orqali to’lash imkonini beradi. Oqim odatda SCA (PSD2) tasdig’i bilan issuer-redirect/App2App qurilgan bo’lib, savdogar onlayn-avtorizatsiyani (success), so’ngra esa provayderning hisobotlari/hisob-kitoblari bo’yicha bank kreditini oladi.

• MDR kartalariga nisbatan past qiymat.
• Onlayn maqom (muvaffaqiyat/muvaffaqiyatsizlik) deyarli darhol, bunda mablag’larni o’tkazish har doim ham instant emas (odatda T + 1/T + 2).
• EI/EEAning keng geografiyasi (ayniqsa Germaniya/Avstriya kuchli), oʻnlab emitent banklarning qoʻllab-quvvatlashi.
• Xaridorning minimal to’lov rekvizitlari - bankni tanlash va tasdiqlash.

2) Rollar va ishtirokchilar

Klarna/Sofort (sxema/provayder): banklarga routing, maqomlar, hisobotlar, hisob-kitoblar, qaytarishlar.
Issuer (to’lovchining banki): SCA, hisobdan chiqarishni tasdiqlash, limitlar/antifrod.
Merchant PSP/Acquirer: merchant, API/SDK, webhooks va recon.
Merchant (sotuvchi): to’lov tashabbusi, maqomlarga ishlov berish/qaytarish, solishtirish.

3) To’lov oqimlari: Redirect va App2App

3. 1 Classic redirect

1. Checkout merchant → «Pay by bank (Sofort/Klarna)» tanlovi.
2. Banklar ro’yxati → onlayn-bankka redirekt (yoki provayderning hosted-sahifasiga) → SCA.
3. Bank to’lovni tasdiqlaydi → maqomi bo’lgan savdogarga qaytarish (success/failed/canceled/pending).
4. Merchant buyurtmani «toʻlangan/kutmoqda» deb belgilaydi, webhook/qabul qilish hisobotini kutadi.

3. 2 App2App / Mobile

Mobil qurilmalarda sotuvchi yuqoridagi sxema bo’yicha deeplink/intent → tasdiqlash → qaytarish bo’yicha bank ilovasini ochadi.
Konvertatsiya yuqori, ishqalanish past; fallbackni veb-tahrirda saqlang.

3. 3 Request-to-Pay/Embedded variantlari

Bir qator banklarda provayder interfeysi orqali request-to-pay/PIS mavjud (xaridorga ilova-bankdan so’rov keladi).
PSP embedded-vidjetlari banklar ro’yxatini, xato va maqomlarni soddalashtiradi.

4) Banklarning limitlari va xulq-atvori

• Per-transaction, per-day/week to’lovchining bankida.
• Yangi oluvchilar/sotuvchilar - pasaytirilgan chegaralar, chidash mumkin.
• Kanal (mobayl/veb), velocity qoidalari, geo/devays signallari.
• Ayrim mamlakatlar/banklarda cheklangan SCA istisnolari (RA, TRA) bankka bog’liq bo’lishi mumkin.

5) Maqomi va qabul qilish (authorization vs settlement)

Online status: `success`, `pending`, `failed`, `canceled`, `expired`.
Pending tasdiqlash kechiktirilganda yoki asinxron tekshirilganda mumkin.
Settlement: haqiqiy kredit provayderning hisobotlari bo’yicha keladi (odatda T + 1/T + 2 bank kuni; mamlakatga/bankka/kliring sxemasiga bog’liq).
Tanqidiy xizmatlar uchun «avtorizatsiya ⇒ shartli ijro» modelidan foydalaning.

6) Qaytarishlar, qisman qaytarishlar va munozaralar

Chargeback (xaritalarda boʻlgani kabi) mavjud emas. Qaytarish - bu provayder orqali to’lovchiga yangi kredit operatsiyasidir.
Partial refunds qoʻllab-quvvatlanmoqda.
Qaytarishni o’tkazish muddatlari - bank (T + 1/T + 2).
Disputlar/shikoyatlar provayderning ODR-tartib-taomillari bo’yicha + to’lovchining banki orqali; buyurtma loglarini, proof-of-delivery/xizmatlarni tayyorlang.

7) Komissiyalar va iqtisodiyot

Odatda fix/tranzaksiyadan past foiz + platforma funksiyalari uchun to’lov (hosted checkout, hisobotlar, ODR).
Qo’llab-quvvatlash qiymati (pending/expiries), xavf-hodisalar va recon operatsion xarajatlarini hisobga oling.

8) Solishtirish va hisobot (reconciliation)

’paymentId/transactionId’,’orderId’, bank-issuer, vaqtinchalik belgilar va maqomlarni saqlang.
Status oʻzgarishi va kundalik auto-recon haqida webhooksni yoqing.
Onlayn-eventlarni (muvaffaqiyat/pending) moliyaviy hisobotlar (pul kiritish/qaytarish/tuzatish) bilan birlashtiring.
Har bir operatsiya uchun hisobotdan UTR/bank referansini saqlang.

9) UX-amaliyotlar

Directory of banks: Oxirgi tanlovni oldindan toʻldiring, qurilmaning mashhurligiga/bankiga qarab saralang.
Mobile-first: App2App, fallback - veb-tahririyatni taklif qiling.
Xatolar va takrorlash: aniq sabablarni bering (limit, SCA muvaffaqiyatsizligi, taymaut), takrorlash va muqobil tugmalar.
Idempotentlik:’orderId’+ xavfsiz takrorlash uchun idempotentlik kaliti.
Kvitansiya: summa, sana/vaqt,’transactionId’, bank, kanal (App2App/Redirect).

10) Rekurrent hisobdan chiqarish va mandatlar

Klassik Sofort - one-off. Rekurrent modellar uchun: birinchi to’lov A2A → e-mandate/SEPA DD/Open Banking PIS.
Mandatlarni (limit, davriylik, xabarnomalar) boshqaring, aksept jurnallarini saqlang.

11) Komplayens, xavfsizlik, ma’lumotlar

PSD2/SCA: bankda tasdiqlash, device binding, bankning antifrodi.
PII-minimallashtirish: faqat zarur atributlarni saqlang; PII ni shifrlang; Veb-xuklarning HMAC imzolari.
GDPR/Logs: rozilik, olib tashlash huquqi, o’zgarishlar auditi.

12) Yuqori xavfli vertikal (shu jumladan iGaming)

Pay-by-Bankning ayrim toifalar uchun foydalanish imkoniyati ichki siyosat va mahalliy huquq bo’yicha provayder/banklar tomonidan cheklanadi.
Pasaytirilgan limitlar, qo’shimcha KTS/moliyaviy monitoring, mumkin bo’lgan holdlarni kuting.
Muqobil relslar (kartalar, SEPA, open banking A2A, vaucherlar) va trafik segmentini saqlang.

13) Merchant integratsiyasi: variantlar

1. Hosted/Embedded от PSP/Klarna

Tezkor boshlash: bank tanlash vidjeti, maqomi, xatolari, «qutidan» webhooks.

2. Server-to-Server + redirect/App2App

Ko’proq nazorat: banklarning o’z sahifasi, xatolarga nozik ishlov berish, QR/Deep Link.

3. Invoyslar/Request-to-Pay

To’lov so’rovini jo’natish (email/SMS/havola), B2B/servislar uchun qulay.

• Эндпоинты: `createPayment`, `queryStatus`, `refund`, `webhook`, `reconcile`.
• Idempotentlik va «orderId» jadvali.
• Statuslar uchun eksponent, beqaror javoblar uchun dead-letter retraalari.
• Kataloglar: banklar/mamlakatlar, limitlar/xato kodlari, issuer’lar bo’yicha SLA-metriklar.

14) «Sofort/Klarna Gateway» arxitekturasi

Kassa uchun API qatlami (REST/GraphQL).
Voqealar navbatlari: status-events → billing/CRM/analitika.
Observability: bank/kanallar bo’yicha konvertatsiya,’pending → success/expired’, yashirlik, SCA rad etish.
Security: sirlar uchun vault, provayder IP-allowlist, anti-replay tokenlar, qat’iy validatsiya redirect-URI.

15) Mahsulotga olib chiqish chek-varaqasi

1. Kerakli bank geografiyasi bilan PSP/Klarna/Sofort kanalini tanlang.
2. ’createPayment’ + bankni + redirect/App2App fallback bilan tanlang.
3. Webhooks, idempotentlik, taymautlar va statuslarni takrorlash.
4. Recon (daily + full), UTR/fin-referensiyalarni saqlash.
5. Sapportda partial/full refunds va ODR reglamentini kiriting.
6. Muvaffaqiyatsizliklar/limitlar va muqobil usullarning UX-stsenariylarini tayyorlang.
7. Maqsadli mamlakatlarda mobil banklarni (iOS/Android) va asosiy issuerlarni sinab ko’ring.
8. Hodisalarning limitlari va maqomi sahifasini yuriting.

Mo’ljallar kartochkasi

Статусы: `success`, `pending`, `failed`, `canceled`, `expired`.
Settlement: ko’pincha T + 1/T + 2; kreditgacha «shartli ijro» ni rejalashtiring.
Limitlar: per-txn/day/week v issuer’a; yangi oluvchilar uchun - quyida.
Rekurrent: e-mandate/SEPA DD/Open Banking orqali.

Xulosa

Konversiya uchun - App2App/Embedded, barqarorlik uchun - aniq webhooks + recon.
Biznes mantiqida onlayn tasdiqlash va haqiqiy kreditni (T + 1/T + 2) ajrating.
Qattiq summalarni qayd etmang: banklar/mamlakatlar bo’yicha limitlar konfigurasi + muntazam yangilanish.
Obuna uchun birinchi to’lovdan foydalaning A2A → mandat, tushunarli boshqaruv UX va limitlari bilan.