OTP در Checkout Block و پرداخت کلاسیک ووکامرس چه تفاوتی دارد؟
پاسخ کوتاه: ظاهر تجربه میتواند یکسان باشد، اما مسیر فنی یکسان نیست. پرداخت کلاسیک فرم و هوکهای PHP ووکامرس را به کار میگیرد؛ Checkout Block سفارش را از Store API میسازد. افزونه OTP باید برای هر دو مسیر اعتبارسنجی سمت سرور جدا داشته باشد. نبض هر دو را پوشش میدهد، اما سازگاری نهایی باید با قالب، درگاه و افزونههای همان فروشگاه روی staging آزموده شود.
یک هدف، دو نقطه اتصال
چرا ورود کاربر تا بعد از ساخت سفارش عقب میافتد؟
در پرداخت کلاسیک نبض، کلیک مهمان روی ثبت سفارش متوقف و مودال OTP باز میشود. پس از تأیید، سرور یک اثبات کوتاهعمر میسازد و جاوااسکریپت آن را در فرم میگذارد. فرم دوباره با nonce معتبر مهمان ارسال میشود؛ سپس سرور اثبات را میسنجد، حساب را پیدا یا ایجاد میکند و شناسه آن را به سفارش میدهد.
حفظ nonce مهمان
لاگینکردن پیش از ارسال دوباره فرم میتواند نشست و nonce را عوض کند. به همین دلیل ابتدا سفارش ساخته و بعد کوکی ورود تنظیم میشود.
فیلد اثبات
توکن تأیید فقط وقتی پذیرفته میشود که با شماره نرمالشده و مقدار کوتاهعمر ذخیرهشده در سرور برابر باشد.
اتصال سفارش
شناسه مشتری پیش از نهاییشدن سفارش جایگزین میشود و پس از ثبت، ورود استاندارد وردپرس اجرا میگردد.
Store API به هوکهای کلاسیک متکی نیست
Checkout Block سفارش را با REST/Store API میفرستد و ممکن است هوک فرم کلاسیک اصلاً اجرا نشود. نبض پس از تأیید OTP، شماره و توکن را در کوکی HttpOnly کوتاهعمر نگه میدارد. Store API پیش از پرداخت تطابق شماره، کوکی و مقدار سرور را کنترل میکند؛ ساخت یا اتصال حساب بعد از اعتبارسنجی خود ووکامرس انجام میشود.
کوکی HttpOnly
جاوااسکریپت صفحه نمیتواند مقدار اثبات را بخواند. کوکی با SameSite=Lax تنظیم میشود و روی HTTPS پرچم Secure میگیرد.
خطای API روشن
اگر شماره یا اثبات منقضی و نامعتبر باشد، درخواست ثبت سفارش با خطای مشخص رد میشود و مشتری باید کد تازه بگیرد.
ساخت حساب دیرهنگام
حساب فقط بعد از معتبرشناختهشدن سفارش ساخته میشود تا خطای نشانی یا پرداخت، حساب نیمهکاره تولید نکند.
شماره موبایل هویت اصلی مهمان است
- فرمت ۰۹، ۹۸ و ارقام فارسی به شماره ۱۱ رقمی استاندارد تبدیل میشود.
- حساب موجود ابتدا با متای شماره صورتحساب و قالبهای رایج شماره پیدا میشود.
- اگر حسابی وجود نداشته باشد، حساب customer ساخته میشود.
- نام و ایمیل برای منطق حساب نبض اختیاریاند؛ قواعد checkout ممکن است آنها را لازم کنند.
- اثبات پرداخت ده دقیقه اعتبار دارد و بعد باید دوباره OTP دریافت شود.
دو مسیر را جداگانه آزمایش کنید
نوع checkout را تأیید کنید
در ویرایشگر صفحه ببینید شورتکد کلاسیک است یا بلوک Checkout. ظاهر قالب همیشه نوع معماری را آشکار نمیکند.
مهمان تازه و موجود
یک شماره بدون حساب و یک شماره با حساب را تست کنید؛ سفارش نباید به مشتری اشتباه متصل شود.
کد غلط و منقضی
ثبت سفارش بدون اثبات معتبر باید در سمت سرور رد شود، نه فقط با پیام ظاهری مرورگر.
همه درگاهها
درگاه مستقیم، پرداخت در محل و روشهای سفارشی مسیرهای متفاوت دارند. هر روش فعال را تا صفحه نتیجه اجرا کنید.
کش و بهینهساز
ترکیب یا تأخیر جاوااسکریپت میتواند مودال و ارسال دوباره را خراب کند. فایل checkout OTP را از تغییر مخرب مستثنا کنید.
موبایل واقعی
مرورگر موبایل، بازگشت از اپ بانک و تغییر تب را آزمایش کنید؛ اثبات باید تا پایان بازه کوتاهعمر سالم بماند.
برای OTP لازم نیست بهخاطر نبض نوع checkout را عوض کنید
اگر checkout فعلی با درگاه، حمل و قالب شما پایدار است، صرفاً برای OTP مهاجرت نکنید. انتخاب بلاک یا کلاسیک باید بر اساس کل اکوسیستم فروشگاه باشد. نبض هر دو مسیر را پوشش میدهد؛ با این حال checkoutهای کاملاً سفارشی که از هوکهای استاندارد یا Store API معمول خارج شدهاند، ممکن است به بررسی و تطبیق نیاز داشته باشند.
راهنماهای مرتبط
ثبت نام با شماره موبایل ووکامرس
تفاوت فرم ثبتنام عمومی با ساخت حساب در Checkout را دقیقتر ببینید.
امنیت OTP و سقف تلاش
کنترلهای سمت سرور که تعیین میکنند ورود پیامکی واقعاً امن است یا نه.
ورود موبایلی در پرداخت
کل سفر مشتری از شماره تا ساخت حساب و ثبت سفارش را بخوانید.
راهنمای انتخاب افزونه
سازگاری checkout را در کنار هزینه، گزارش، امنیت و پشتیبانی بسنجید.
متن پیامک سفارش
پس از موفقیت checkout، برای هر وضعیت پیام روشن بفرستید.
OTP را روی همان checkout واقعی آزمایش کنید
نبض پرداخت کلاسیک و Checkout Block را پوشش میدهد؛ انتشار نهایی را بعد از تست staging انجام دهید.