اتصال زرین‌پال به Laravel — نکات قبل از فروش آنلاین

زرین‌پال فقط یک دکمه پرداخت نیست. سفارش، موجودی، کال‌بک، رسید و برگشت وجه باید در پنل شما ثبت شوند تا حسابداری و پشتیبانی یک روایت داشته باشند. این راهنما نکات قبل از فروش آنلاین را از پیاده‌سازی‌های Laravel تیم KGSM جمع می‌کند.

این راهنما با عنوان «اتصال زرین‌پال به Laravel — نکات قبل از فروش آنلاین» از تجربه تحویل پروژه‌های KGSM نوشته شده: محدوده نسخه اول، انتشار مرحله‌ای، و پشتیبانی بعد از تحویل.

مخاطب، ریسک و روش KGSM

مدیر فروشگاه یا محصول که می‌خواهد زرین‌پال را به Laravel وصل کند و نگران سفارش ناقص و پرداخت تکراری است

درگاه بدون مدل سفارش یعنی موجودی غلط، رسید گم، و مشتری که دو بار پول می‌دهد.

KGSM سفارش، کال‌بک و پنل مالی را قبل از دکمه پرداخت می‌بندد و اتصال را مرحله‌ای روی Staging تست می‌کند.

اول مدل سفارش، بعد درگاه

قبل از SDK، جدول سفارش باید کد، مبلغ قفل‌شده، هزینه ارسال، وضعیت، و اقلام با موجودی رزرو داشته باشد. اگر مبلغ از سبد لحظه‌ای در مرورگر بیاید، کاربر با ابزار توسعه‌دهنده قیمت را عوض می‌کند. موجودی را هنگام ایجاد سفارش رزرو کنید و اگر پرداخت در مهلت نشد آزاد کنید؛ در غیر این صورت دو نفر یک کالا را می‌خرند. وضعیت‌ها را محدود و معنی‌دار کنید: در انتظار پرداخت، پرداخت‌شده، ناموفق، منقضی، در حال ارسال. نسخه اول KGSM معمولاً این مدل را با برنامه‌نویسی وب می‌بندد و ظاهر فروش را با طراحی سایت جلو می‌برد. کد کالای پایدار برای حسابداری لازم است؛ عنوان نمایشی کافی نیست. مالیات و تخفیف را در همان سفارش ذخیره کنید تا گزارش سود بعداً از روی حافظه ساخته نشود. تا این‌ها روی Staging با یک SKU واقعی کار نکنند، مرچنت زرین‌پال را به تولید نبرید.

مبلغ را از سفارش ذخیره‌شده وریفای کنید نه از سبد مرورگر. فروشگاهی مبلغ را از فرم می‌گرفت؛ یک خریدار با تغییر فیلد سفارش را ارزان تمام کرد.

کال‌بک، وریفای و تکراری‌نبودن

پرداخت وقتی قطعی است که verify سمت سرور موفق باشد، نه وقتی مرورگر به صفحه تشکر رسیده. کال‌بک ممکن است دو بار بیاید، دیر برسد، یا کاربر صفحه را ببندد؛ پس عملیات باید idempotent باشد: همان authority یا شناسه درگاه فقط یک‌بار سفارش را پرداخت‌شده کند. سفارش را با مبلغ ذخیره‌شده وریفای کنید نه با مبلغ فرم. پشتیبانی زرین‌پال بدون آن به حدس می‌افتد. صف را برای کارهای بعد از پرداخت — ایمیل، صدور فاکتور، کاهش قطعی موجودی — بگذارید تا کندی ایمیل، تراکنش را دو بار نکند. محیط sandbox را با مبلغ واقعی اشتباه نگیرید اما سناریوی موفقیت، انصراف و timeout را هر سه تست کنید. KGSM این مسیر را در دموی مرحله‌ای با دو کلیک پشت‌سرهم روی پرداخت نشان می‌دهد تا دوباره‌ثبت دیده شود.

کال‌بک دوبار رسید و دو فاکتور برای یک authority صادر شد. کال‌بک را تکراری‌نپذیر بنویسید تا دو کلیک دو پرداخت نسازد.

امنیت مبلغ، مرچنت و بازگشت

مرچنت و دسترسی درگاه فقط در .env تولید باشند و در مخزن نروند. صفحه بازگشت را با توکن حدس‌ناپذیر بسازید تا کسی با عوض کردن query، سفارش دیگران را پرداخت‌شده نکند. HTTPS اجباری است؛ درگاه روی HTTP اعتبار شما را هم پیش بانک خراب می‌کند. مبلغ صفر یا منفی را در اعتبارسنجی سفارش ببندید. اگر چند درگاه دارید، نام درگاه را روی همان رسید ذخیره کنید تا مغایرت بانکی قابل پیگیری باشد. نقش پشتیبانی باید بتواند رسید را ببیند اما مبلغ سفارش پرداخت‌شده را ویرایش نکند. برای سئو صفحات محصول، موجودی و قیمت باید همان منبع پنل باشند؛ سئو روی صفحه کالای ناموجود با دکمه پرداخت، نارضایتی و نرخ خروج می‌سازد. اگر اپ هم می‌فروشد، همان API سفارش را به اپلیکیشن موبایل بدهید تا درگاه دوم روی سبد جدا ساخته نشود.

موجودی را با مهلت رزرو قفل کنید و بعد از انقضا آزاد کنید. رزرو موجودی نبود و دو مشتری آخرین عدد یک کالا را خریدند.

برگشت وجه، مغایرت و عملیات روز بعد

فروش آنلاین بدون مسیر لغو و برگشت، تیکت‌های بی‌انتها می‌سازد. وضعیت برگشت را در سفارش بگذارید و شناسه تراکنش درگاه را کنارش نگه دارید تا حسابدار دو بار دستی واریز نکند. مغایرت روزانه: لیست پرداخت‌شده سامانه با تسویه زرین‌پال باید یک گزارش داشته باشد؛ اختلاف را همان روز ببندید نه پایان ماه. سفارش پرداخت‌شده بدون آیتم، یا آیتم بدون پرداخت، دو پرس‌وجوی سلامت هستند که باید در پنل مدیر چشمک بزنند. اطلاع‌رسانی پیامک را بعد از verify بفرستید نه بعد از کلیک دکمه. KGSM آموزش پنل را با یک سفارش تست، یک ناموفق و یک برگشت می‌دهد تا پشتیبانی هفته اول قفل نشود. نگهداری یعنی به‌روزرسانی SDK، بررسی تغییر API درگاه، و پشتیبان قبل از کمپین. برای رفتن زنده، از تماس یک سناریوی SKU و هزینه ارسال بفرستید تا برآورد روی «فقط دکمه زرین‌پال» ننشیند.

صفحه تشکر قبل از verify ایمیل زد؛ پرداخت ناموفق بود و پشتیبانی گیج شد. لاگ خام درگاه را برای پشتیبانی نگه دارید.

مرچنت را در مخزن و Staging مشترک نگذارید. کمپین جمعه بدون گزارش مغایرت، یکشنبه را با ده پرداخت بی‌سفارش تمام کرد.

برگشت وجه فقط در پنل زرین‌پال بود؛ حسابدار دوباره به مشتری واریز کرد. گزارش مغایرت روزانه را قبل از کمپین تبلیغاتی روشن کنید.

پیامک موفقیت را بعد از verify بفرستید نه بعد از کلیک. فروشگاهی مبلغ را از فرم می‌گرفت؛ یک خریدار با تغییر فیلد سفارش را ارزان تمام کرد.

کال‌بک دوبار رسید و دو فاکتور برای یک authority صادر شد. برگشت وجه را وضعیت سفارش کنید نه فقط یک واریز دستی.

چک‌لیست اجرا

• مبلغ را از سفارش ذخیره‌شده وریفای کنید نه از سبد مرورگر.
• کال‌بک را تکراری‌نپذیر بنویسید تا دو کلیک دو پرداخت نسازد.
• موجودی را با مهلت رزرو قفل کنید و بعد از انقضا آزاد کنید.
• لاگ خام درگاه را برای پشتیبانی نگه دارید.
• مرچنت را در مخزن و Staging مشترک نگذارید.
• گزارش مغایرت روزانه را قبل از کمپین تبلیغاتی روشن کنید.
• پیامک موفقیت را بعد از verify بفرستید نه بعد از کلیک.
• برگشت وجه را وضعیت سفارش کنید نه فقط یک واریز دستی.

سناریوی واقعی 1

فروشگاهی مبلغ را از فرم می‌گرفت؛ یک خریدار با تغییر فیلد سفارش را ارزان تمام کرد.

مبلغ را از سفارش ذخیره‌شده وریفای کنید نه از سبد مرورگر.

سناریوی واقعی 2

کال‌بک دوبار رسید و دو فاکتور برای یک authority صادر شد.

کال‌بک را تکراری‌نپذیر بنویسید تا دو کلیک دو پرداخت نسازد.

سناریوی واقعی 3

رزرو موجودی نبود و دو مشتری آخرین عدد یک کالا را خریدند.

موجودی را با مهلت رزرو قفل کنید و بعد از انقضا آزاد کنید.

سناریوی واقعی 4

صفحه تشکر قبل از verify ایمیل زد؛ پرداخت ناموفق بود و پشتیبانی گیج شد.

لاگ خام درگاه را برای پشتیبانی نگه دارید.

سناریوی واقعی 5

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

مرچنت را در مخزن و Staging مشترک نگذارید.

سناریوی واقعی 6

برگشت وجه فقط در پنل زرین‌پال بود؛ حسابدار دوباره به مشتری واریز کرد.

گزارش مغایرت روزانه را قبل از کمپین تبلیغاتی روشن کنید.

صفحات مرتبط KGSM

ادامه را در KGSM و خدمات طراحی سایت، برنامه‌نویسی و توسعه نرم‌افزار ببینید. برای برآورد محدوده نسخه اول از فرم تماس استفاده کنید.

وقتی این نکته به تیم زنده می‌رسد باید قانون اجرایی باشد نه اسلاید: مبلغ را از سفارش ذخیره‌شده وریفای کنید نه از سبد مرورگر. برایش مالک و تاریخ بازبینی بگذارید تا در اولین هفته شلوغ فراموش نشود.

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

وقتی این نکته به تیم زنده می‌رسد باید قانون اجرایی باشد نه اسلاید: موجودی را با مهلت رزرو قفل کنید و بعد از انقضا آزاد کنید. برایش مالک و تاریخ بازبینی بگذارید تا در اولین هفته شلوغ فراموش نشود.

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

وقتی این نکته به تیم زنده می‌رسد باید قانون اجرایی باشد نه اسلاید: مرچنت را در مخزن و Staging مشترک نگذارید. برایش مالک و تاریخ بازبینی بگذارید تا در اولین هفته شلوغ فراموش نشود.

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

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

وقتی این نکته به تیم زنده می‌رسد باید قانون اجرایی باشد نه اسلاید: برگشت وجه را وضعیت سفارش کنید نه فقط یک واریز دستی. برایش مالک و تاریخ بازبینی بگذارید تا در اولین هفته شلوغ فراموش نشود.

وقتی این نکته به تیم زنده می‌رسد باید قانون اجرایی باشد نه اسلاید: فروشگاهی مبلغ را از فرم می‌گرفت؛ یک خریدار با تغییر فیلد سفارش را ارزان تمام کرد. برایش مالک و تاریخ بازبینی بگذارید تا در اولین هفته شلوغ فراموش نشود.

وقتی این نکته به تیم زنده می‌رسد باید قانون اجرایی باشد نه اسلاید: کال‌بک دوبار رسید و دو فاکتور برای یک authority صادر شد. برایش مالک و تاریخ بازبینی بگذارید تا در اولین هفته شلوغ فراموش نشود.