Sofort/کلارنا: پرداخت توسط بانک

1) Sofort/Klarna Pay-by-Bank چیست ؟

Sofort (در حال حاضر Klarna Pay Now/Pay-by-Bank) یک ابزار A2A است که به خریدار اجازه می دهد برای سفارش به طور مستقیم از حساب بانکی خود از طریق یک برنامه آنلاین بانک/تلفن همراه پرداخت کند. جریان معمولا بر روی یک issuer-redirect/App2App تایید SCA (PSD2) ساخته می شود و بازرگان مجوز آنلاین (موفقیت) را دریافت می کند و سپس یک وام بانکی بر اساس گزارش ها/محاسبات ارائه دهنده.

• هزینه کم نسبت به MDR های کارت.
• وضعیت آنلاین (موفقیت/شکست) تقریبا بلافاصله، در حالی که اعتبار وجوه همیشه فوری (معمولا T + 1/T + 2).
• جغرافیای گسترده در اتحادیه اروپا/EEA (آلمان/اتریش به ویژه قوی است)، پشتیبانی از ده ها بانک صادر کننده.
• حداقل جزئیات پرداخت از خریدار - انتخاب بانک و تایید.

2) نقش ها و شرکت کنندگان

Klarna/Sofort (scheme/provider): مسیریابی به بانک ها، وضعیت ها، گزارش ها، شهرک ها، بازده ها.
صادر کننده (بانک پرداخت کننده): SCA، تأیید لغو، محدودیت/ضد تقلب.
بازرگانی PSP/Acquirer: اتصال بازرگان، API/SDK، webhooks و recon.

بازرگان - آغاز پرداخت، وضعیت روند/بازده، آشتی

3) جریان پرداخت: تغییر مسیر و App2App

3. 1 تغییر مسیر کلاسیک

1. گزینه «Pay by bank (Sofort/Klarna)» را انتخاب کنید.
2. لیست بانکها → تغییر مسیر به بانک آنلاین (یا به صفحه میزبان ارائه دهنده) → SCA.
3. بانک تایید پرداخت → بازگشت به تاجر با وضعیت (موفقیت/شکست خورده/لغو/در انتظار).
4. Merchant records order as «paid/pending», waits for webhook/ثبت نام گزارش.

3. 2 App2App/موبایل

در دستگاه های تلفن همراه، بازرگان برنامه بانکی را با deeplink/intent → تأیید → return according to the scheme above.
تبدیل بالاتر است، اصطکاک پایین تر است ؛ نگه داشتن سقوط در تغییر مسیر وب.

3. 3 درخواست به پرداخت/گزینه های جاسازی شده

تعدادی از بانک ها درخواست به پرداخت/PIS موجود از طریق رابط ارائه دهنده (خریدار یک درخواست از بانک نرم افزار دریافت).
ویدجت های جاسازی شده از PSP لیست بانک ها، خطاها و وضعیت ها را ساده می کنند.

4) محدودیتها و رفتار بانکها

• هر معامله، در روز/هفته در بانک پرداخت کننده.
• گیرندگان/بازرگانان جدید - آستانه کاهش، سرعت شاتر امکان پذیر است.
• کانال (تلفن همراه/وب)، قوانین سرعت، سیگنال های جغرافیایی/دستگاه.
• در کشورها/بانک های فردی، استثنائات SCA آستانه (RA، TRA) ممکن است - بسته به بانک.

5) مجوز در مقابل حل و فصل

وضعیت آنلاین: «موفقیت»، «در انتظار»، «شکست خورده»، «لغو شده»، «منقضی شده».
در حال انتظار ممکن است زمانی که تاخیر تایید یا چک آسنکرون رخ می دهد.
حل و فصل: وام واقعی می آید از گزارش ارائه دهنده (معمولا T + 1/T + 2 روز بانکی; بستگی به طرح کشور/بانک/پاکسازی دارد).
برای خدمات بحرانی، از مدل اجرای مجوز ⇒ مشروط استفاده کنید تا ثبت نام تایید شود.

6) بازده، بازده جزئی و اختلافات

Chargeback (همانطور که در کارت ها) گم شده است. بازگشت یک معامله اعتباری جدید از طریق یک ارائه دهنده به پرداخت کننده است.
بازپرداخت جزئی پشتیبانی می شود.
شرایط اعتباری بازگشت - بانک (T + 1/T + 2).
اختلافات/شکایات از طریق روش ارائه دهنده + ODR از طریق بانک پرداخت کننده انجام می شود ؛ آماده سیاهههای مربوط سفارش، اثبات تحویل/خدمات.

7) کمیسیون ها و اقتصاد

معمولا درصد ثابت/کم با معامله + پرداخت برای توابع پلت فرم (پرداخت میزبان، گزارش، ODR).
هزینه پشتیبانی (انتظار/انقضا)، حوادث ریسک و هزینه های معامله مجدد را در نظر بگیرید.

8) آشتی و گزارش

صرفه جویی در «paymentId/transactionId» ارائه دهنده، «orderId»، صدور بانک، زمان بندی، وضعیت.
فعال کردن webhooks در مورد تغییرات وضعیت و روزانه خودکار شناسایی.
ترکیب رویدادهای آنلاین (موفقیت/در انتظار) با گزارش های مالی (اعتبار/بازده/اصلاحات).
مرجع UTR/بانک را از گزارش برای هر معامله ذخیره کنید.

9) شیوه های UX

دایرکتوری بانک ها: قبل از پر کردن آخرین انتخاب، مرتب سازی بر اساس محبوبیت/بانک دستگاه.
Mobile-first: ارائه App2App، برگشت - تغییر مسیر وب.
خطاها و دوباره امتحان کنید: دلایل روشن (محدودیت، شکست SCA، وقفه)، دکمه دوباره امتحان کنید و جایگزین.
Idempotence: 'orderId' + کلید idempotence برای تکرار ایمن.
رسید: مقدار, تاریخ/زمان, 'transactionId', بانک, کانال (App2App/تغییر مسیر).

10) تکرار نوشتن آف و حکم

کلاسیک Sofort - یک خاموش. برای مدل های بازگشتی، یک دسته استفاده می شود: اولین پرداخت A2A → e-mutation/SEPA DD/Open Banking PIS برای آینده است.
مدیریت احکام (محدودیت، فرکانس، اطلاعیه ها)، سیاهههای مربوط به پذیرش فروشگاه.

11) انطباق، امنیت، داده ها

PSD2/SCA: تایید در بانک، اتصال دستگاه، بانک ضد تقلب.
به حداقل رساندن PII: ذخیره تنها ویژگی های لازم ؛ رمزگذاری PII ؛ امضای HMAC از قلاب های وب.
GDPR/Logs: موافقت، حق حذف، تغییرات حسابرسی.

12) Verticals با ریسک بالا (از جمله iGaming)

در دسترس بودن پرداخت توسط بانک برای برخی از دسته ها توسط ارائه دهنده/بانک ها با توجه به سیاست های داخلی و قانون محلی محدود شده است.
انتظار می رود محدودیت های کاهش یافته، نظارت اضافی CUS/مالی، نگه می دارد ممکن است.
ریل های جایگزین (کارت ها، SEPA، بانکداری باز A2A، کوپن) و تقسیم بندی ترافیک را نگه دارید.

13) ادغام بازرگان: گزینه ها

1. میزبانی/جاسازی شده от PSP/کلارنا

شروع سریع: ویجت انتخاب بانک، وضعیت، اشکالات، webhooks خارج از جعبه.

2. سرور به سرور + redirect/App2App

کنترل بیشتر: صفحه شخصی بانک ها، پردازش خطای خوب، QR/Deep Link خود.

3. درخواست به پرداخت

ارسال درخواست پرداخت (ایمیل/SMS/لینک)، مناسب برای B2B/services.

• Эндпоинты: 'ایجاد پرداخت'، 'queryStatus'، 'بازپرداخت'، 'webhook'، 'آشتی'.
• جدول idempotence و dedupe توسط 'orderId'.
• Retrai به صورت نمایی برای statuses، حرف مرده برای پاسخ های ناپایدار.
• کاتالوگ ها: بانک ها/کشورها، محدودیت ها/کدهای خطا، معیارهای SLA توسط صادرکنندگان.

14) معماری دروازه Sofort/Klarna

لایه API (REST/GraphQL) برای ثبت نام نقدی.
صف های رویداد: رویدادهای وضعیت → صورتحساب/CRM/تجزیه و تحلیل.
قابلیت مشاهده: تبدیل بانک/کانال، «در انتظار → موفقیت/منقضی شده»، تاخیر، شکست SCA.
امنیت: طاق برای اسرار، ارائه دهنده IP-allowlist، نشانه های ضد پخش، اعتبار سنجی سخت تغییر مسیر-URI.

15) چک لیست خروجی

1. PSP/Klarna/Sofort کانال با جغرافیای بانک مورد نظر را انتخاب کنید.
2. پیاده سازی «ایجاد پرداخت» + انتخاب بانک + redirect/App2App با بازپرداخت.
3. اتصال webhooks، idempotency، وقفه و تکرار وضعیت.
4. راه اندازی recon (روزانه + کامل)، UTR/fin منابع ذخیره سازی.
5. بازپرداخت جزئی/کامل و ODR را در پشتیبانی فعال کنید.
6. سناریوهای شکست/محدودیت UX و روش های جایگزین را آماده کنید.
7. تست بانک های تلفن همراه (iOS/Android) و صادرکنندگان عمده در کشورهای هدف.
8. یک راهنمای محدود و صفحه وضعیت حادثه را حفظ کنید.

کارت علامت گذاری

Статусы: «موفقیت»، «در انتظار»، «شکست خورده»، «لغو شده»، «منقضی شده».
حل و فصل: اغلب T + 1/T + 2 ؛ طرح «اجرای مشروط» قبل از اعتبار.
محدودیت ها: per-txn/day/week در صادر کننده برای دریافت کنندگان جدید - در زیر.
تکرار: از طریق مجوز الکترونیکی/SEPA DD/بانکداری باز.

خلاصه

برای تبدیل - App2App/Embedded، برای ثبات - webhooks روشن + recon.
تایید آنلاین جداگانه و اعتبار واقعی (T + 1/T + 2) در منطق کسب و کار.
مقادیر سخت را رفع نکنید: پیکربندی های محدود توسط بانک/کشور + به روز رسانی منظم.
برای اشتراک، از اولین پرداخت A2A → دستور، با مدیریت UX روشن و محدودیت استفاده کنید.