نحوه عملکرد بوم‌سازگان پرداخت

درباره اینکه چه کسانی در بوم‌سازگان «پرداخت‌های وب» مشارکت دارند، نحوه تعامل آن‌ها با یکدیگر، و نحوه مشارکت شما بیشتر بدانید.

آناتومی پرداخت‌های وب

پرداخت‌های تحت وب شامل چندین استاندارد وب است:

  • میانای برنامه‌سازی کاربردی درخواست پرداخت: میانای برنامه‌سازی کاربردی درخواست پرداخت تسویه‌حساب سریع و آسان را ازطریق واسط کاربر مرورگر بومی امکان‌پذیر می‌کند. این میانای برنامه‌سازی کاربردی جریان تسویه‌حساب ثابتی را ارائه می‌دهد و نیاز کاربران به وارد کردن اطلاعات ارسال و پرداخت در هر تسویه‌حساب را کاهش می‌دهد.
  • Web-based Payment Handler API: Web-based Payment Handler API بوم‌سازگان را برای ارائه‌دهندگان پرداخت باز می‌کند و به برنامه‌های پرداخت مبتنی بر وب آن‌ها اجازه می‌دهد تا ازطریق Payment Request API استاندارد به‌عنوان روش‌های پرداخت در وب‌سایت‌های فروشنده عمل کنند.
  • شناسه‌های روش پرداخت: شناسه‌های روش پرداخت نحوه استفاده از رشته‌ها (https://google.com/pay، https://apple.com/apple-pay، و غیره) را برای شناسایی روش پرداخت تعریف می‌کند. این API علاوه‌بر شناسه‌های استاندارد روش پرداخت، به همه اجازه می‌دهد روش پرداخت خودشان را با شناسه‌های روش پرداخت مبتنی بر نشانی وب تعریف کنند.
  • مانیفست روش پرداخت: مانیفست روش پرداخت فایل مانیفست ماشین‌خوانا را تعریف می‌کند که به‌عنوان مانیفست روش پرداخت شناخته می‌شود و نحوه مشارکت روش پرداخت در بوم‌سازگان پرداخت و نحوه استفاده از این فایل‌ها را شرح می‌دهد.

فرایند درخواست پرداخت چگونه کار می‌کند

معمولاً چهار شرکت‌کننده در تراکنش آنلاین وجود دارد.

بازیکنان شرح استفاده از میانای برنامه‌سازی کاربردی
مشتریان کاربرانی که برای خرید آنلاین محصول(ها) روند تسویه‌حساب را طی می‌کنند. موجود نیست
فروشنده‌ها کسب‌وکارهایی که در وب‌سایتشان محصول می‌فروشند. Payment Request API
ارائه‌دهندگان خدمات پرداخت (PSP) شرکت‌های طرف سومی که درواقع پرداخت‌ها را پردازش می‌کنند، که شامل کسر هزینه از مشتریان و واریز به حساب فروشندگان می‌شود. به آن درگاه پرداخت یا پردازشگر پرداخت هم گفته می‌شود. Payment Request API
مدیریت‌كننده‌های پرداخت شرکت‌های شخص ثالثی که برنامه‌هایی ارائه می‌دهند که معمولاً اعتبارنامه‌های پرداخت مشتریان را ذخیره می‌کنند و با اجازه آن‌ها این اعتبارنامه‌ها را برای پردازش تراکنش به فروشندگان ارائه می‌دهند. Web-based Payment Handler API
توالی معمول رویدادها در پردازش پرداخت کارت اعتباری در وب
توالی معمول رویدادها در پردازش پرداخت با کارت اعتباری در وب
  1. مشتری از وب‌سایت فروشنده بازدید می‌کند، محصولاتی را به سبد خرید اضافه می‌کند، و روند تسویه‌حساب را شروع می‌کند.
  2. «فروشنده» برای پردازش تراکنش به اطلاعات کاربری پرداخت مشتری نیاز دارد. آن‌ها بااستفاده از میانای برنامه‌سازی کاربردی درخواست پرداخت، واسط کاربر درخواست پرداخت را به مشتری ارائه می‌دهند. رابط کاربری روش‌های پرداخت مختلفی را که توسط شناسه‌های روش پرداخت مشخص شده است فهرست می‌کند. روش‌های پرداخت می‌تواند شامل شماره کارت‌های اعتباری ذخیره‌شده در مرورگر، یا مدیران پرداخت مانند Google Pay،‏ Samsung Pay، و موارد مشابه باشد. «فروشنده» می‌تواند به‌طور اختیاری نشانی ارسال کالا و اطلاعات تماس مشتری را درخواست کند.
  3. اگر مشتری روش پرداختی مثل Google Pay را انتخاب کند، Chrome یک برنامه پرداخت بومی پلاتفرم یا یک برنامه پرداخت مبتنی بر وب را راه‌اندازی می‌کند. این مرحله کاملاً به پیاده‌سازی کنترل‌کننده پرداخت، براساس مانیفست روش پرداخت بستگی دارد. پس‌از اینکه مشتری پرداخت را مجاز کرد، مدیر پرداخت پاسخی به Payment Request API برمی‌گرداند که آن را به سایت فروشنده منتقل می‌کند. (اگر پرداخت از نوع فشاری باشد، مثل انتقال بانکی یا رمزارز، پرداخت قبلاً پردازش شده است و فروشنده پاسخ را دریافت می‌کند.)
  4. سایت فروشنده اعتبارنامه پرداخت را به «ارائه‌دهنده خدمات پرداخت» ارسال می‌کند تا پرداخت را پردازش کند و انتقال وجوه را آغاز کند. معمولاً درستی‌سنجی پرداخت در سمت سرور نیز لازم است.
  5. ارائه‌دهنده خدمات پرداخت، پرداخت را پردازش می‌کند، به‌طور ایمن درخواست انتقال وجوه از بانک مشتری یا صادرکننده کارت اعتباری به فروشنده را ارسال می‌کند، و سپس نتیجه موفقیت یا شکست را به وب‌سایت فروشنده برمی‌گرداند.
  6. وب‌سایت فروشنده موفقیت یا شکست تراکنش را به مشتری اطلاع می‌دهد و مرحله بعدی را نمایش می‌دهد، برای مثال، ارسال کالای خریداری‌شده.

هشدار: اتکا به «ارائه‌کننده سرویس پرداخت»

اگر فروشنده هستید و می‌خواهید پرداخت‌های کارت اعتباری را بپذیرید، «ارائه‌دهندگان خدمات پرداخت» پیوند مهمی در زنجیره پردازش پرداخت هستند. پیاده‌سازی Payment Request API نیاز به PSP را برطرف نمی‌کند.

فروشندگان معمولاً برای راحتی و دلایل مربوط به هزینه، برای پردازش پرداخت به ارائه‌دهنده خدمات پرداخت طرف سوم متکی هستند. دلیل اصلی این است که اکثر ارائه‌دهندگان خدمات پرداخت از PCI DSS پیروی می‌کنند که یک استاندارد امنیت اطلاعات است که ایمنی داده‌های دارنده کارت را تنظیم می‌کند.

ازآنجایی‌که دستیابی به استاندارد PCI DSS و حفظ آن می‌تواند پرهزینه و دشوار باشد، اکثر فروشندگان متوجه می‌شوند که تکیه بر یک ارائه‌دهنده خدمات پرداخت منطبق با استاندارد، آن‌ها را از طی کردن فرایند صدور گواهینامه بی‌نیاز می‌کند. بااین‌حال، برخی‌از شرکت‌های بزرگ و ازنظر مالی قدرتمند، گواهینامه PCI DSS خود را به‌طور خاص برای اجتناب از چنین اتکایی به طرف ثالث دریافت می‌کنند.

این موضوع به‌ویژه زمانی اهمیت دارد که با شماره حساب اصلی (PAN) به‌عنوان اعتبارنامه پرداخت سروکار دارید، یعنی شماره‌ای که روی کارت برجسته شده است. مدیریت یک با جاوا اسکریپت نیازمند مطابقت با PCI SAQ A-EP است.

بنابراین، واگذاری پردازش پرداخت به یک «ارائه‌دهنده خدمات پرداخت» منطبق با PCI DSS، هم الزامات سایت فروشنده را ساده می‌کند و هم یکپارچگی اطلاعات پرداخت را برای مشتری تضمین می‌کند.

بعدی

درباره فیلدها و روش‌های Payment Request API در نحوه عملکرد Payment Request API بیشتر بدانید.