بهینه‌سازی پرداخت موبایل در فروشگاه اینترنتی: چک‌لیست

بیشتر خریدهای فروشگاه‌های ایرانی از گوشی انجام می‌شود، و پرداخت جایی است که دقت‌ترین ریزه‌کاری‌ها اهمیت پیدا می‌کنند: کیبورد اشتباه، فیلدی که پر نمی‌شود، دکمه‌ای که زیر انگشت دیده نمی‌شود، و صفحه‌ای که بعد از بازگشت از درگاه معلوم نیست پرداخت موفق بود یا نه. این مقاله یک چک‌لیست قابل‌آزمون برای تجربهٔ پرداخت موبایل می‌دهد: ورودی‌ها، خطاها، بازگشت از درگاه و دسترس‌پذیری.

مرز منابع: توصیه‌های ورودی از مستند web.dev، دسترس‌پذیری از WCAG 2.2، بخش علت‌های رهاکردن از Baymard (مربوط به آمریکا؛ برای ایران عددی نداریم) و جریان بازگشت از درگاه از مستند رسمی زرین‌پال به‌عنوان یک نمونه است. سهم موبایل در خریدهای فروشگاه شما را نمی‌دانیم و ادعا نمی‌کنیم؛ از آنالیتیکس خودتان بخوانید. بخش‌های «توصیهٔ نویسنده» منبع مستقل ندارند.

ساختار: HTML درست پایهٔ همه‌چیز است

web.dev می‌گوید از عناصر معنایی form، input، label و button استفاده کنید، هر فیلد را با label برچسب بزنید و برای فعال‌شدن قابلیت‌های داخلی مرورگر از type و autocomplete مناسب کمک بگیرید. دکمه باید button باشد نه div: دکمهٔ واقعی رفتار قابل‌دسترس و ارسال فرم داخلی دارد. این‌ها روی موبایل مهم‌اند چون مرورگر و کیبورد از آن‌ها تصمیم می‌گیرند چه نمایش دهند. برای مبانی طراحی فرم، فرم‌های خوب چگونه طراحی می‌شوند؟ را ببینید.

کیبورد درست برای هر فیلد

web.dev هشدار می‌دهد برای شماره‌هایی مثل تلفن، کارت و حساب از type="number" استفاده نکنید، چون فلش‌های افزایش و کاهش اضافه می‌کند که برای این داده‌ها بی‌معنی است. به‌جای آن type="tel" برای تلفن و inputmode="numeric" برای بقیهٔ اعداد را بگذارید تا کیبورد عددی ظاهر شود. توصیه‌ها در عمل (ترکیب با توصیهٔ نویسنده):

یک نکتهٔ فارسی از نویسنده: اگر مشتری ارقام فارسی تایپ می‌کند، سرور باید ارقام فارسی و عربی را به لاتین نرمال‌سازی کند، وگرنه اعتبارسنجی بی‌دلیل شکست می‌خورد. این را با تست روی کیبوردهای رایج گوشی بسنجید.

پر کردن خودکار: کمتر تایپ، کمتر خطا

web.dev می‌گوید اگر برای فیلدی مقدار autocomplete مناسب هست استفاده کنید؛ برای آدرس صورت‌حساب هم مثل ارسال از مقدار با پیشوند billing بهره ببرید تا کاربر چند بار داده وارد نکند. همچنین برای اینکه مرورگر بتواند فرم را پر کند، name و id فیلدها باید ثابت باشند و بین بارگذاری‌ها یا انتشار نسخه‌ها عوض نشوند. شماره کارت را در یک فیلد بگیرید، و فیلدهای سفارشی را که پر کردن خودکار را می‌شکنند کنار بگذارید. نام را با محدودیت نگیرید: web.dev توصیه می‌کند نام‌های بین‌المللی پذیرفته شوند و بدون دلیل اعتبارسنجی سخت نکنید.

در جریان ایرانی معمولاً اطلاعات کارت روی صفحهٔ درگاه وارد می‌شود، نه در فروشگاه (مثل جریان مستند زرین‌پال که خریدار به آدرس درگاه منتقل می‌شود). در این صورت فیلد کارت در فروشگاه شما لازم نیست؛ این بخش برای فرم‌های آدرس، مشخصات و کد تخفیف مهم است. وقتی مشتری به درگاه می‌رود ظاهر آن در کنترل شما نیست؛ بنابراین مهم‌ترین نقطهٔ بهینه‌سازی «قبل از درگاه» و «بعد از بازگشت» است.

طول فرایند و حساب کاربری

Baymard (نظرسنجی آمریکا، نه ایران) می‌گوید ۱۷٪ خریدارانی که به‌دلیل غیر از «فقط مرور» سفارش را رها کرده‌اند علت را «فرایند طولانی یا پیچیده» دانسته‌اند، ۱۸٪ «اجبار به ساخت حساب»، ۱۷٪ «خطا یا کرش سایت» و ۱۰٪ «رد شدن کارت». همین منبع می‌گوید پرداخت ایده‌آل می‌تواند ۱۲ تا ۱۴ عنصر فرم (۷–۸ فیلد) داشته باشد. عددها را الگو نکنید؛ مرجع شما باید رفتار کاربران خودتان باشد. اما جهت روشن است: فیلد اضافی را حذف کنید، ورود را اجباری نکنید (مثلاً ثبت‌نام با تأیید شماره موبایل بعد از خرید)، و استان و شهر را با انتخاب‌گر ساده بپرسید. (راهکارهای فارسی توصیهٔ نویسنده‌اند.)

خطا: متنی، نزدیک فیلد، با راه اصلاح

طبق WCAG 3.3.1 اگر خطا خودکار تشخیص داده شود، فیلد خطادار باید مشخص و خطا متنی توصیف شود. معیار 3.3.3 هم می‌گوید اگر پیشنهاد اصلاح شناخته‌شده است، داده شود. web.dev همین را با زبان محصول می‌گوید: کاربر را سرزنش نکنید و حین ورود در اصلاح کمک کنید. پیشنهاد عملی: خطا را کنار فیلد بنویسید، بعد از ارسال فوکوس را روی اولین خطا ببرید، متن خطا قابل‌فهم و بدون اصطلاح فنی باشد («شماره موبایل باید ۱۱ رقم و با ۰۹ شروع شود») و ورودی کاربر را پاک نکنید. توجه: قاعدهٔ «۱۱ رقم و ۰۹» مثال فارسی از نویسنده است.

اندازهٔ هدف و فاصله

معیار 2.5.8 در WCAG 2.2 حداقل ۲۴×۲۴ پیکسل CSS را برای هدف لمسی می‌خواهد (با استثناها). دکمهٔ «پرداخت»، انتخاب روش ارسال و ویرایش تعداد در سبد را با همین معیار بسنجید. فاصله بین دکمهٔ «پرداخت» و دکمه‌های ثانویه (مثل «بازگشت به سبد») را کافی بگیرید. برای مبانی دسترس‌پذیری، Accessibility چیست؟ را ببینید.

بازگشت از درگاه: نتیجه را روشن نشان دهید

مستند زرین‌پال می‌گوید بعد از پرداخت خریدار به callback_url بازمی‌گردد و Status با مقدار OK یا NOK می‌آید. NOK یعنی ناموفق یا لغو، و verify فقط برای OK صدا زده می‌شود. از دید تجربهٔ کاربر (توصیهٔ نویسنده، مبتنی بر این جریان):

• صفحهٔ بازگشت سه حالت متمایز داشته باشد: موفق (با شمارهٔ سفارش و شمارهٔ پیگیری)، لغوشده/ناموفق (با دکمهٔ «پرداخت دوباره»)، و در حال بررسی.
• در حالت «در حال بررسی» (مثلاً timeout در verify) به کاربر بگویید پول کسرشده بعد از بررسی برمی‌گردد یا سفارش تأیید می‌شود و منتظر پیام خواهد بود. متن را با تیم مالی هماهنگ کنید.
• ردیابی سفارش در حساب یا با پیامک و ایمیل ارسال شود تا کاربر رفرش‌های پشت‌سرهم نکند.
• سبد خرید تا قبل از تأیید پرداخت پاک نشود؛ اگر کاربر لغو کرد با یک کلیک به همان سبد برگردد.

جزئیات فنی verify و تکرار آن (مثل کد ۱۰۱) در این مقاله نیست؛ این‌جا فقط جنبهٔ تجربه را بررسی می‌کنیم.

آزمون روی دستگاه واقعی

1. پرداخت را روی دست‌کم دو گوشی واقعی (یک اندروید و در صورت امکان یک iOS) و دو مرورگر انجام دهید.
2. با کیبورد فارسی و انگلیسی همهٔ فیلدها را پر کنید.
3. پر کردن خودکار را فعال کنید و ببینید آدرس و تلفن پر می‌شود یا نه.
4. سناریوهای خطا: فیلد خالی، موبایل نامعتبر، لغو در درگاه، بازگشت با Status=NOK.
5. با اتصال کند (شبیه‌سازی در ابزار مرورگر) صفحهٔ بازگشت را تست کنید.
6. با یک screen reader بررسی کنید label و پیام خطا خوانده می‌شود. (نام ابزار را بر اساس دستگاه انتخاب کنید؛ ما مستندشان را بررسی نکردیم.)

چک‌لیست

1. همهٔ فیلدها label و type/autocomplete مناسب دارند و دکمه‌ها button واقعی‌اند.
2. برای تلفن و اعداد type="tel" یا inputmode="numeric" است و type="number" به کار نرفته است.
3. name و id فیلدها پایدارند و آدرس صورت‌حساب مقدار billing دارد.
4. ورود به حساب اجباری نیست و فرم فقط فیلدهای لازم را می‌پرسد.
5. خطاها متنی، کنار فیلد و با راه اصلاح‌اند و ورودی پاک نمی‌شود.
6. هدف‌های لمسی دست‌کم ۲۴×۲۴ پیکسل CSS‌اند.
7. صفحهٔ بازگشت از درگاه سه حالت روشن دارد و سبد تا تأیید پاک نمی‌شود.
8. روی دستگاه واقعی و با کیبورد فارسی آزموده شده است.

برای دید کلی تجربهٔ کاربری، UX چیست؟ را ببینید.

منابع و مراجع

• Payment and address form best practices — web.dev.
• Understanding SC 2.5.8: Target Size (Minimum) — W3C WAI، WCAG 2.2.
• Understanding SC 3.3.1: Error Identification — W3C WAI، WCAG 2.2.
• Understanding SC 3.3.3: Error Suggestion — W3C WAI، WCAG 2.2.
• 50 Cart Abandonment Rate Statistics 2026 — Baymard Institute، 2025-09-22.
• راهنمای اتصال به درگاه اینترنتی زرین‌پال — ZarinPal (مستندات رسمی).