کاربر تا صفحه پرداخت فروشگاه رسیده، اما دوباره باید اطلاعاتی را وارد کند که مرورگر یا کیف پولش از قبل می‌شناسد. کم کردن این اصطکاک یکی از هدف‌های Web Payments است. با این حال، میان «مرورگر انتخاب روش پرداخت را ساده می‌کند» و «مرورگر به‌تنهایی پول جابه‌جا می‌کند» فاصله زیادی وجود دارد. اگر این دو را یکی بدانیم، هم معماری محصول اشتباه می‌شود و هم ممکن است پرداختی را موفق اعلام کنیم که هنوز تأیید نشده است.
عنوان «تصویب استاندارد Web Payments 2.0» تصویر دقیقی از وضعیت فعلی نمی‌دهد. Web Payments نام یک حوزه و مجموعه فعالیت‌هاست، نه یک نسخه واحد که همه پرداخت‌های اینترنتی را جایگزین کرده باشد. این راهنما نقش Payment Request API، Payment Handler و backend فروشگاه را جدا می‌کند و نشان می‌دهد برای ساخت تجربه پرداخت بهتر، کدام سؤال‌ها باید پیش از انتخاب ابزار پاسخ داده شوند.
در سال ۲۰۲۶ کدام سند را داریم؟
در فهرست رسمی اسناد Payment Request در W3C، نسخه منتشرشده در ۲۲ ژوئن ۲۰۲۶ با وضعیت Candidate Recommendation Draft معرفی شده است. عبارت Draft به معنی سند در حال تکامل است و با اعلام نهایی شدن یک استاندارد تازه به نام Web Payments 2.0 تفاوت دارد. برای تصمیم فنی، نام سند، وضعیت انتشار و پیاده‌سازی مرورگر باید جداگانه خوانده شوند؛ یک خبر کوتاه معمولاً این تفاوت‌ها را حذف می‌کند.
یک Recommendation برای Payment Request در سال ۲۰۲۲ نیز وجود دارد. نسخه‌های بعدی روی هماهنگی مشخصات با پیاده‌سازی‌ها کار می‌کنند. از وجود سند تازه نمی‌توان نتیجه گرفت همه مرورگرها همه امکانات آن را عرضه کرده‌اند. همین‌طور لازم نیست منتظر یک عدد نسخه بزرگ بمانیم تا فرم پرداخت فعلی را بهتر کنیم. توضیح روشن مبلغ، مسیر بازگشت قابل فهم و مدیریت درست خطا، در هر روش پرداختی کاربرد دارند.
Payment Request API چه کاری انجام می‌دهد؟
این API یک راه ارتباطی میان سایت، مرورگر و روش پرداخت فراهم می‌کند. سایت اطلاعات درخواست را معرفی می‌کند و مرورگر می‌تواند رابط مناسبی برای انتخاب روش پرداخت نشان دهد. نتیجه‌ای که به سایت برمی‌گردد، بسته به روش انتخابی اطلاعات متفاوتی دارد. در مشخصات رسمی Payment Request نقش پرداخت‌کننده، دریافت‌کننده و ارائه‌دهنده روش پرداخت از هم جدا شده است؛ مرورگر واسطه تجربه است و تمام مسئولیت‌های فروشگاه را بر عهده نمی‌گیرد.
تصور کنید فروشگاهی یک کیف پول سازگار را به مشتری پیشنهاد می‌دهد. کاربر به‌جای تایپ چند فیلد، انتخابش را در رابط مرورگر تأیید می‌کند. این حرکت می‌تواند تعامل را کوتاه کند، اما حساب پذیرنده، پردازش تراکنش، وضعیت سفارش، رسید و بازپرداخت همچنان به سیستم پرداخت و برنامه فروشگاه وابسته‌اند. برای پرداخت‌های مختلف، قرارداد داده و شرایط استفاده نیز یکسان نیستند. وجود API مشترک، تفاوت سرویس‌ها را از بین نمی‌برد.
Payment Handler با Payment Request فرق دارد
Payment Request از سمت سایت درخواست پرداخت را آغاز می‌کند. Payment Handler به سمت برنامه یا سرویسی مربوط است که درخواست یک روش پرداخت را دریافت و پاسخ آن را فراهم می‌کند. این دو نام مشابه‌اند، اما جایگاهشان در جریان یکسان نیست. سند Web-based Payment Handler API در W3C مسیر مربوط به handler مبتنی بر وب را توضیح می‌دهد. وضعیت آن را هم باید مستقل از Payment Request بررسی کرد.
برای تیم طراحی، این تمایز کمک می‌کند مالک هر صفحه و هر پیام مشخص شود. شاید بعضی مرحله‌ها در سایت فروشگاه باشند، بعضی در رابط مرورگر و بعضی در محیط ارائه‌دهنده پرداخت. اگر کاربر میان این محیط‌ها جابه‌جا شود، نام فروشنده، مبلغ و زبان پیام‌ها باید پیوستگی داشته باشند. تغییر ناگهانی ظاهر یا اطلاعات متناقض، اعتماد را کم می‌کند حتی اگر اتصال فنی کاملاً درست انجام شده باشد.
چرا وجود API به معنی پشتیبانی کامل نیست؟
تشخیص وجود PaymentRequest فقط یکی از بررسی‌های اولیه است. ممکن است مرورگر interface را بشناسد، اما روش پرداخت مورد نظر، دستگاه کاربر یا تنظیمات او اجازه ادامه ندهند. همچنین بعضی قابلیت‌ها به secure context و تعامل مستقیم کاربر وابسته‌اند. راهنمای Payment Request در MDN این API را دارای دسترسی محدود معرفی می‌کند. بنابراین نباید تنها مسیر پرداخت سایت را بر فرض پشتیبانی عمومی بنا کنیم.
مسیر جایگزین باید از ابتدا طراحی شود. کاربر بدون کیف پول سازگار، با مرورگر متفاوت یا پس از انصراف از پنجره پرداخت باید بتواند با روش معمول فروشگاه ادامه دهد. این مسیر نباید یک دکمه پنهان یا پیام مبهم باشد. عنوانی مانند «پرداخت با روش دیگر» و حفظ اطلاعات سفارش، بازگشت را ساده‌تر می‌کند. مقاله طراحی Mobile-first برای فکر کردن به محدودیت صفحه و جریان کار روی موبایل نیز مرتبط است.
جریان درست از سفارش تا تأیید پرداخت
نقطه آغاز بهتر، ایجاد سفارش معتبر در سرور است. قیمت، موجودی، تخفیف و مبلغ قابل پرداخت باید براساس داده قابل اعتماد محاسبه شوند؛ عددی که از مرورگر می‌آید به‌تنهایی مرجع نیست. سپس تلاش پرداخت به همان سفارش متصل می‌شود. پس از پاسخ روش پرداخت، backend وضعیت را از مسیر مستند ارائه‌دهنده بررسی می‌کند و فقط وقتی شرط تأیید برقرار است، سفارش به حالت پرداخت‌شده می‌رود.
صفحه بازگشت می‌تواند به کاربر بگوید «در حال بررسی پرداخت هستیم» و وضعیت سفارش را از سرور بخواند. نمایش پیام موفقیت صرفاً به دلیل برگشتن به یک URL یا دریافت پارامتر success اشتباه است. قطع اینترنت و بسته شدن تب نباید حقیقت تراکنش را عوض کند. یک کاربر ممکن است پول پرداخت کرده باشد ولی صفحه بازگشت را نبیند؛ محصول باید بتواند این وضعیت را بعداً از مسیر معتبر بازیابی کند.
پرداخت یک عملیات هم‌زمان ساده نیست
بعضی ارائه‌دهندگان تغییرات را با webhook اطلاع می‌دهند. برای نمونه، مستندات webhook در Stripe درباره تأیید امضا، دریافت رویدادها و مدیریت تحویل آن‌ها توضیح می‌دهد. این نمونه برای فهم معماری است و به معنی مناسب بودن همان سرویس برای هر کشور یا کسب‌وکار نیست. هر ارائه‌دهنده قرارداد خودش را دارد و باید همان قرارداد مبنای پیاده‌سازی باشد.
اگر یک رویداد دوباره برسد، نباید دوباره محصول ارسال شود یا موجودی دوباره کاهش پیدا کند. پردازش تکرارپذیر، شناسه تلاش پرداخت و ثبت نتیجه کمک می‌کنند یک اتفاق چند بار اثر نگذارد. ترتیب رسیدن پیام‌ها هم همیشه مطابق انتظار ما نیست. از نظر طراحی، وضعیت‌هایی مانند در انتظار، پرداخت‌شده و ناموفق باید معنی روشن داشته باشند تا پشتیبانی و کاربر بتوانند درباره همان وضعیت صحبت کنند.
مبلغ، واحد پول و زبان را دقیق نمایش دهید
در یک رابط فارسی، تفاوت ریال و تومان نباید به حدس کاربر واگذار شود. واحد نمایش، واحد ارسال به سرویس و واحد ذخیره‌شده در سفارش را صریح تعریف کنید. تبدیل میان این واحدها باید در یک نقطه کنترل‌شده انجام شود. اعداد فارسی برای خواندن مناسب‌اند، اما داده ارسالی به API باید مطابق قرارداد آن باشد. نمایش مبلغ زیبا بدون هماهنگی با داده سرور می‌تواند به اختلاف واقعی در پرداخت منجر شود.
قبل از تأیید نهایی، مبلغ کل، هزینه‌های اضافه و موضوع خرید را قابل مشاهده نگه دارید. اگر هزینه ارسال تغییر می‌کند، توضیح دهید چرا. دکمه تأیید نیز بهتر است نتیجه عمل را بیان کند. «پرداخت مبلغ سفارش» از عبارتی مبهم مثل «ادامه» روشن‌تر است، به‌خصوص وقتی کلیک بعدی کاربر را وارد محیط دیگری می‌کند. راهنمای تایپوگرافی فارسی در طراحی برای نمایش خوانای مبلغ و متن‌های کوتاه مفید است.
خطا و انصراف را از هم جدا کنید
انصراف کاربر الزاماً خطای سیستم نیست. ممکن است بخواهد روش دیگری انتخاب کند یا اطلاعات سفارش را تغییر دهد. پیام «پرداخت لغو شد؛ می‌توانید روش دیگری انتخاب کنید» از اخطار قرمز و مبهم کاربردی‌تر است. در مقابل، خطای ارتباطی باید روشن کند آیا نتیجه پرداخت هنوز نامشخص است یا پرداخت رد شده است. دعوت فوری به پرداخت دوباره، وقتی نتیجه تلاش قبلی معلوم نیست، می‌تواند کاربر را نگران کند.
برای وضعیت نامشخص، مسیر مشاهده سفارش و تماس با پشتیبانی را فراهم کنید. اطلاعاتی مانند شماره سفارش کمک می‌کند کاربر بدون ارسال داده حساس مسئله را توضیح دهد. متن خطا نباید محتویات پاسخ خام سرویس یا اطلاعات محرمانه را نمایش دهد. اینجا طراحی حالت‌های خالی و پیام‌های معنادار به کار می‌آید: پیام باید وضعیت و حرکت بعدی را توضیح دهد، نه فقط یک کد خطا نشان دهد.
آیا تبدیل کاربران حتماً افزایش پیدا می‌کند؟
برای همه فروشگاه‌ها نمی‌توان یک درصد ثابت افزایش نرخ تبدیل اعلام کرد. نتیجه به مخاطب، روش‌های پرداخت، کیفیت فرم فعلی، هزینه ارسال و عوامل دیگر بستگی دارد. حتی کوتاه شدن تعداد مراحل ممکن است برای کاربری که روش پرداخت را نمی‌شناسد، اعتماد کمتری ایجاد کند. پیش از تغییر، مسئله واقعی را تعریف کنید: ترک فرم، خطای ورود اطلاعات، ابهام مبلغ یا شکست ارتباط؟ هر کدام راه‌حل متفاوتی دارند.
شاخص‌ها را در سطح تلاش پرداخت و سفارش دنبال کنید. آغاز پرداخت، تأیید معتبر، انصراف و وضعیت نامشخص را در یک دسته قرار ندهید. بهتر شدن یک عدد ظاهری، مثل تعداد کلیک روی دکمه، الزاماً فروش موفق را بیشتر نکرده است. داده تشخیصی نیز باید حداقل لازم باشد؛ ثبت اطلاعات کامل پرداخت در ابزار تحلیل یا log عمومی، راه مناسبی برای فهم رفتار کاربر نیست.
برای فروشگاه خودمان از کجا شروع کنیم؟
ابتدا روش‌هایی را مشخص کنید که ارائه‌دهنده پرداخت شما واقعاً پشتیبانی می‌کند. سپس مخاطب، مرورگرها و مسیر fallback را در طراحی بیاورید. وضعیت سفارش باید پیش از اتصال رابط جدید تعریف شده باشد. اگر این پایه آماده نیست، ساده کردن frontend مسئله اصلی را حل نمی‌کند. روی سرور مرجع مبلغ، روش تأیید و نحوه برخورد با تکرار پیام را روشن کنید؛ روی رابط، مبلغ و حرکت بعدی را واضح نگه دارید.
Web Payments زمانی ارزش دارد که بخشی از یک جریان قابل فهم و قابل اعتماد باشد. حذف چند فیلد می‌تواند کمک کند، اما سفارش درست، وضعیت روشن و پیگیری قابل اتکا مهم‌ترند. تصمیم مناسب برای یک کسب‌وکار ممکن است استفاده از کیف پول سازگار باشد و برای کسب‌وکار دیگر، بهبود مسیر پرداخت موجود. نام استاندارد به‌تنهایی تصمیم را تعیین نمی‌کند؛ قرارداد واقعی سرویس و تجربه مشتری تعیین می‌کنند کدام تغییر ارزش اجرا دارد.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!