iDEAL هلند: پرداخت A2A

1) زمینه iDEAL و موقعیت

iDEAL یک طرح ملی برای پرداخت A2A غیر نقدی (حساب به حساب) در هلند است. خریدار برای خرید به طور مستقیم از حساب بانکی خود از طریق بانک آنلاین/برنامه تلفن همراه بانک صادر کننده پرداخت می کند. جریان بر روی صادر کننده تغییر مسیر (تغییر مسیر به بانک) و یا در باز کردن یک برنامه بانکی توسط deeplink/App2App ساخته شده است. محاسبه سریع است، کمیسیون برای تاجر پایین تر از MDR کارت است، نهایی مانند انتقال اعتبار بانکی است.

• قابلیت همکاری از طریق صدور بانک (ING، Rabobank، ABN AMRO، و غیره).
• مکاتبات SCA/PSD2 - تایید در بانک (PIN/بیومتریک).
• مجوز فوری (موفقیت وضعیت آنلاین) و وام نهایی از طریق بانک خریدار/گیرنده.
• فراداده غنی برای آشتی (buyId/orderId, description, reference).

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

iDEAL (طرح) - قوانین, صدور گواهینامه, مسیریابی به صدور بانک.
صادر کننده - تأیید اعتبار مشتری، تأیید پرداخت، وضعیت.
Acquirer/CPSP (ارائه دهنده خدمات پرداخت) - اتصال بازرگان، API/SDK، گزارش و محاسبات.
Merchant - پرداخت را آغاز می کند، وضعیت/بودجه را دریافت می کند، بازده و آشتی را حفظ می کند.

3) گزینه های جریان پرداخت

3. 1 صدور تغییر مسیر (کلاسیک)

1. Checkout merchant → انتخاب یک بانک از دایرکتوری صادر کننده.

2. تغییر مسیر یا App2App به بانک → SCA → تایید

3. بازگشت به بازرگان با «transactionId» و وضعیت (موفقیت/شکست/لغو/باز/منقضی شده).

3. 2 App2App/جاسازی شده

در دستگاه های تلفن همراه، بازرگان یک برنامه بانکی را با deeplink/intent باز می کند (UX بهتر، اصطکاک کمتر).
Embedded/Hosted: ارائه دهنده یک ویجت آماده از لیست بانک ها، مدیریت تغییر مسیر، مدیریت خطا را ارائه می دهد.

3. 3 iDEAL QR (آفلاین/آنلاین)

QR پویا در هر سفارش با مجموع جاسازی شده و مرجع ؛ خریدار دوربین برنامه بانکی را اسکن می کند و پرداخت را تایید می کند.
QR استاتیک (نادر برای بازرگانان ؛ بیشتر برای P2P/donations) - مقدار به صورت دستی توسط کاربر وارد شده است.

3. 4 تکرار/احکام

مدل «اولین پرداخت + مجوز الکترونیکی»: اولین لغو برای iDEAL با SCA صریح → ایجاد یک مجوز الکترونیکی (معمولا منجر به بدهی مستقیم SEPA برای لغو بعدی در محدودیت ها/دوره های توافق شده می شود). مناسب برای اشتراک ها

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

• در هر معامله (حداکثر در هر عملیات).
• Per-day/24h و هفتگی (مبلغ و/یا تعداد معاملات).
• ذینفع جدید/بازرگان جدید - کاهش آستانه و/یا قرار گرفتن در معرض امکان پذیر است.
• قوانین کانال/خطر (تلفن همراه در مقابل دسکتاپ, سرعت, جغرافیایی/دستگاه).

تمرین: اعداد هاردکد را حفظ نکنید - یک دایرکتوری از محدودیت های بانک ها را نگه دارید و کاربر را یک خطای قابل فهم «بیش از حد توسط بانک» با گزینه های دیگر (تقسیم، روش دیگری، بعدا تکرار کنید) نمایش دهید.

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

• هزینه های ارائه دهنده (دروازه، ویجت، پرداخت میزبانی)،
• هزینه بازگشت/ODRs،
• پشتیبانی و بررسی حوادث

6) وضعیت، لغو، بازگشت

وضعیت معاملات: «موفقیت»، «باز» (انتظار)، «شکست خورده»، «لغو»، «منقضی شده».
لغو قبل از تایید - از مشتری (در بانک) و یا با زمان (منقضی شده).
شارژر به عنوان در کارت - نه. بازپرداخت یک معامله اعتباری جدید از تاجر به پرداخت کننده (بازپرداخت) است، بازپرداخت جزئی امکان پذیر است.
دوره بازگشت بستگی به PSP/بانک ؛ اغلب T + 0/T + 1 در انتقال بانکی.

7) ایمنی و انطباق

SCA در بانک صادر کننده + سیاست های اتصال و ضد تقلب دستگاه در طرف بانک.
نمایش نام/IBAN در برخی از صادرکنندگان خطر اشتباه را کاهش می دهد.
PSD2/GDPR: به حداقل رساندن PII، حفاظت از قلاب وب (HMAC)، ورود به سیستم حسابرسی.

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

صرفه جویی در 'transactionId' (iDEAL)، 'buyId '/' orderId'، زمان، صادر کننده، وضعیت نهایی، مرجع UTR/بانک از گزارش PSP.
تنظیم روزانه خودکار recon و دوره ای کامل recon (آشتی گردش، بازده، تنظیمات).
در گزارش های PSP: پارامترهای سفارش اولیه، وضعیت ها، به روز رسانی های دیر (به عنوان مثال، «open → success/expired»)، حرکات را برمی گرداند.

9) الگوهای UX

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

10) نوشتن مجدد از طریق بلیط الکترونیکی

سناریوی «iDEAL اولین پرداخت → دستور برای آینده نوشتن آف» (معمولا از طریق بدهی مستقیم SEPA).
محدودیت هر بدهی, فرکانس, حق لغو در دستور ثابت.
در رابط، یک صفحه مکث/لغو/به روز رسانی و اطلاعیه ها قبل از انهدام وجود دارد.

11) iDEAL و iGaming/دسته های پرخطر

در دسترس بودن iDEAL برای برخی از verticals محدود به بانک ها/PSPs در سیاست ریسک و قانون محلی است.
برای iGaming، انتظار می رود: چک های سخت تر، محدودیت های کاهش یافته، انطباق اجباری محلی و جریان ODR/بازپرداخت شفاف.
برنامه ریزی ریل های جایگزین (کارت، SEPA، بانکداری باز A2A) و تقسیم بندی ترافیک.

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

1. میزبانی/جاسازی شده iDEAL پرداخت от PSP

شروع سریع، به روز رسانی خودکار لیست بانک ها، وضعیت ها و خطاها.

2. تغییر مسیر سرور به سرور +

کنترل UX انعطاف پذیر: صفحه انتخاب بانک خود، نسل QR، ادغام عمیق به صندوقدار.

3. iDEAL QR

برای POS/آفلاین: QR پویا در هر سفارش با مجموع/علائم، بهتر است برای آشتی و ضد هزینه.

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

13) طرح معماری «دروازه iDEAL»

لایه API: REST برای میز نقدی + ادغام با PSP/iDEAL API.
صف های رویداد: رویدادهای وضعیت → صورتحساب/CRM/تجزیه و تحلیل.
قابلیت مشاهده: معیارهای تبدیل توسط بانک ها/کانال ها (Redirect/App2App/QR)، سهم «open → expired»، تأخیر متوسط برای موفقیت.
امنیت: اسرار در طاق, IP-مجاز از PSP, حفاظت URL تغییر مسیر, نشانه ضد پخش.
داده ها: ثبت پرداخت/بازگشت، ورود ODR، کارت بلیط.

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

1. انتخاب PSP/خریدار با iDEAL (میزبانی/جاسازی شده/App2App/QR).
2. پیاده سازی 'createPayment' + تغییر مسیر/برنامه 2 برنامه، صفحه انتخاب بانک.
3. فعال کردن قلاب های وب، idempotency، زمان بندی و پخش وضعیت.
4. تنظیم recon (روزانه + کامل)، آپلود و هشدار برای خارج از همگام سازی.
5. پشتیبانی از بازپرداخت جزئی/کامل و مقررات ODR در حمایت.
6. اضافه کردن UX-fallback (روش های جایگزین، تکرار)، با «transactionId» چک کنید.
7. تست App2App/QR در بانک های بزرگ (iOS/Android/desktop).
8. یک راهنمای محدود توسط بانک و یک صفحه وضعیت حادثه تهیه کنید.

محدود کردن کارت مرجع

آستانه های واقعی توسط بانک پرداخت کننده تعیین می شود و ممکن است متفاوت باشد.

Per-txn/24h/7d: فروشگاه در پیکربندی ؛ بررسی قبل از شروع تغییر مسیر.
ذینفعان/بازرگانان جدید: محدودیت های شروع و/یا تاخیر را کاهش می دهد.
کانال: در App2App تلفن همراه، سیاست های محدودیت/تقلب ممکن است از وب متفاوت باشد.
بلیط - محدودیت/فرکانس در شرایط بلیط (برای نوشتن تکراری) تنظیم شده است.

خلاصه

شرط بندی در App2App/Embedded تبدیل و QR پویا برای آفلاین.
مقادیر سخت را محدود نکنید: محدودیت ها و قوانین رفتاری بانک ها را تنظیم کنید.
این روند در اطراف webhooks + recon، وضعیت های روشن و بازپرداخت جزئی ساخته شده است.
برای اشتراک - اولین پرداخت iDEAL → مجوز الکترونیکی ؛ محدودیت ها و اعلان ها را به صورت شفاف مدیریت کنید.