قابل اعتماد: پرداخت مستقیم بانکی

1) چه چیزی قابل اعتماد است

Trustly پرداخت A2A (حساب به حساب) و ارائه دهنده پرداخت است که بازرگانان را به بانک های پرداخت کننده از طریق redirect/App2App متصل می کند. خریدار انتقال را در بانک خود (SCA از طریق PSD2) تأیید می کند، بازرگان بلافاصله تأیید آنلاین را دریافت می کند و اعتبار وجوه از طریق گزارش ها/محاسبات ارائه دهنده انجام می شود.

• هزینه کم نسبت به MDR های کارت.
• جغرافیای گسترده در اروپا (Nordics، DACH، Benelux، انگلستان، اتحادیه اروپا جنوبی، و غیره) + بانک های محلی.
• پرداخت ها و پرداخت ها (از جمله پرداخت های فوری برای بانک های پشتیبانی شده).
• راه حل های تخصصی برای iGaming (به عنوان مثال، پرداخت N بازی: «سپرده → حساب ایجاد شده/تایید شده»).

2) خط تولید و سناریوها

پرداخت (پرداخت از بانک): redirect/App2App به بانک پرداخت → SCA → موفقیت آنلاین/امتناع → وام بعدی.
پرداخت: انتقال به حساب کاربر ؛ برای تعدادی از بانک ها - فورا (در غیر این صورت T + 1/T + 2).
Pay N Play (iGaming): ترکیبی از سپرده با onboarding: سیگنال های KYC از داده های بانکی (نام، IBAN/BIC، و غیره) استخراج می شود، یک حساب بازی بدون ثبت نام جداگانه ایجاد می شود، سریع در داخل امکان بازگشت به همان حساب وجود دارد.
اطلاعات حساب/بررسی (اختیاری): تأیید مالکیت حساب، تأیید نام/IBAN برای ضد قاطر/ODR.

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

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

1. پرداخت بازرگان → انتخاب بانک (دایرکتوری/جستجو).
2. تغییر مسیر به صفحه بانک یا صفحه میزبان → SCA.
3. بازگشت به سایت فروشنده با وضعیت (موفقیت/در انتظار/شکست خورده/لغو/منقضی شده).
4. در انتظار گزارش webhook/settlement.

3. 2 App2App (تلفن همراه)

باز کردن یک برنامه بانکی از طریق deeplink/intent → تایید → بازگشت

تبدیل بالاتر و پرداخت کاهش یافته کمتر ؛ مطمئن شوید که به نگه داشتن fallback در تغییر مسیر وب.

3. 3 پرداخت

آغاز پرداخت از طریق API با مرجع سفارش/برنده ؛ دریافت وضعیت آنلاین «پذیرفته شده برای پردازش» و نتیجه برای webhook/رجیستری.
حفظ idempotency و کارت وضعیت پرداخت بسیار مهم است (تا تکرار/rollbacks).

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

• محدودیت های هر معامله و هر روز/هفته در بانک پرداخت کننده.
• گیرندگان/بازرگانان جدید - آستانه کاهش و/یا قرار گرفتن در معرض.
• قوانین کانال/سرعت، سیگنال های جغرافیایی/دستگاه، ضد قاطر.
• برای پرداخت - سهمیه های فردی/چک آستانه (به خصوص فوری).

تمرین: اعداد را سخت نگیرید. نگه داشتن یک دایرکتوری از محدودیت های بانک/کشور/کانال، نشان می دهد در UX دلیل قابل درک برای امتناع («حد بانک/کانال بیش از حد») و ارائه گزینه های (تقسیم، روش دیگر).

5) وضعیت و شهرک: موفقیت آنلاین در مقابل اعتبار واقعی

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

6) بازگشت و اختلافات

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

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

معمولا ثابت/کم بهره معامله + هزینه های پلت فرم (پرداخت میزبانی، گزارش، ODR، پرداخت/فوری).
برنامه ریزی هزینه در انتظار/expiries، ODR و پشتیبانی recon.

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

«ID پرداخت/transactionId» ارائه دهنده، «orderId»، صدور بانک، برچسب های زمانی، مرجع UTR/بانک از گزارش های مالی را ذخیره کنید.
اتصال وب سایت ها برای تغییر وضعیت ؛ روزانه auto-recon و periodic full-recon را اجرا کنید.
برای پرداخت - ثبت نام جداگانه و مقایسه با اصلی پرداخت/تعادل بازی.

9) شیوه های UX

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

10) پرداخت N بازی (برای iGaming)

ورود بدون فرم ثبت نام: کاربر یک بانک را انتخاب می کند، سپرده را تأیید می کند، و ارائه دهنده اطلاعات بانکی تأیید شده (نام/حساب) را به بازرگان می دهد - یک حساب بازی ایجاد می شود.
سیگنال های KYC از بانک باعث کاهش اصطکاک و سرعت بخشیدن به اولین سپرده می شود.
سریع در داخل: پرداخت به همان حساب تایید شده، اغلب بلافاصله.
سیاست های بازی دقیق مسئول، محدودیت های سپرده، ورود به سیستم و ODR شفاف مورد نیاز است.

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

PSD2/SCA، اتصال دستگاه و ضد تقلب بانک صادر کننده.
به حداقل رساندن GDPR/PII: فقط ویژگی های لازم را ذخیره کنید، PII را رمزگذاری کنید، دسترسی را محدود کنید.
Webhooks: امضای HMAC/nonce، حفاظت از پخش، IP allowlist.
AML/sanctions: نظارت بر معاملات، تطبیق نام، سیگنال های ضد قاطر.

12) Verticals با ریسک بالا

در دسترس بودن و محدودیت ها برای برخی از دسته ها (از جمله iGaming، رمزنگاری و غیره) به کشور و بانک های شریک بستگی دارد.
انتظار می رود: محدودیت های سخت تر، KYC گسترش یافته، نگهداری احتمالی و شواهد اضافی.
ریل های جایگزین (کارت ها، SEPA، PIS بانکی باز از سایر ارائه دهندگان) را نگه دارید، مسیریابی در امتداد مشخصات مشتری.

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

1. میزبانی/جاسازی شده توسط ارائه دهنده

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

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

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

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

ارسال یک لینک پرداخت از طریق ایمیل/SMS/مسنجر ؛ مناسب برای B2B/services

• Эндпоинты: 'create' Payment ',' refund ',' createPayout ',' queryStatus ',' webhook ',' آشتی '.
• Idempotence و dedupe توسط 'orderId'.
• وضعیت Retrai به صورت نمایی، حرف مرده در پاسخ های ناپایدار.
• کاتالوگ ها: بانک ها/کشورها، محدودیت ها/کدهای خطا، معیارهای SLA توسط صادرکنندگان.

14) معماری «دروازه اعتماد»

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

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

1. جغرافیا/بانک ها را انتخاب کنید و کانال Trustly را در PSP وصل کنید.
2. پیاده سازی «ایجاد پرداخت» + انتخاب بانک + redirect/App2App با بازپرداخت.
3. اتصال webhooks، timeouts و بازیابی وضعیت.
4. راه اندازی recon (روزانه + کامل)، UTR/fin منابع ذخیره سازی.
5. فعال کردن بازپرداخت جزئی/کامل، سیاهههای مربوط ODR، روش های پشتیبانی.
6. برای iGaming - اجرای پرداخت N بازی, محدودیت سپرده, سریع در داخل, ردیابی بازی مسئول.
7. ایجاد نظارت SLA توسط بانک/کانال و هشدار توسط حادثه.
8. تست بانک های تلفن همراه (iOS/Android) و صادرکنندگان عمده بر اساس کشور.

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

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

خلاصه

شرط بندی در App2App/Embedded تبدیل و پرداخت فوری به نگه دارید.
تایید آنلاین جداگانه و اعتبار واقعی در منطق کسب و کار.
مقدار را ثابت نکنید: تنظیمات محدود را با بانک/کشور/کانال نگه دارید.
برای iGaming، از Pay N Play با KYC شفاف، محدودیت ها و پرداخت های سریع استفاده کنید.