یکپارچه سازی درگاه پرداخت یک فرآیند خیلی حساس در توسعه وب هست کوچکترین اشتباه در جریان داده (Data Flow) می تواند باعث خطا ها و باگ های امنیتی یا تراکنش ناموفق شود و یا می تواند باعث شود اطلاعات ناقص یا اشتباه در دیتابیس سیستم ما ذخیره شود
در این پست، فرآیند استاندارد یک تراکنش مالی را از اولین درخواست کاربر (یعنی کلیک رو دکمه پرداخت) تا تایید نهایی و بازگشت به کلاینت را بررسی میکنیم .
چرخه تراکنش مالی :
1. درخواست شروع تراکنش (initiation) :
کاربر (سمت کلاینت) : کاربر در سایت یا اپلیکیشن روی دکمه پرداخت کلیک میکند
سرور (Server) : سرور اطلاعات اولیه پرداخت (مبلغ و توکن شناسایی (merchant-id) و callback و ... ) رو به درگاه پرداخت ارسال میکند
درگاه پرداخت (Payment Gateway) : درگاه پرداخت اعتبارسنجی انجام می دهد و بعد از تایید یک شناسه یکتا موقت (Authority) به صورت پاسخ به سرور برمی گرداند
طبق تصویر این بخش مربوط به فرآیند 1 و 2 و 2.1 هست و منظور از callback ادرسی هست که درگاه پرداخت اطلاعات را بعد از پرداخت یا کنسل کردن توسط کاربر به آن ارسال میکند
نکته : در این مرحله شما باید به عنوان یک توسعه دهنده اطلاعات تراکنش را به صورت موقت در دیتابیس خود ذخیره کنید
2. ریدایرکت کردن کاربر به درگاه پرداخت (Redirect) :
سرور پس از دریافت Authority باید کاربر را به در گاه پرداخت امن بفرستد یا به اصطلاح ریدایرکت کند تا کاربر بتواند پرداخت خود را انجام دهد
سرور کاربر را به درگاه پرداخت با آدرس گفته شده در مستندات همراه با Authority ارسال میکند و کاربر را به آن ریدایرکت میکند یعنی به صورت :
http://example.com/{Authority}
کاربر به درگاه پرداخت امن هدایت می شود و اطلاعات خود را وارد می کند
3. بازگشت به سایت (Callback) :
بعد از تکمیل پرداخت توسط کاربر (پرداخت موفق ، پرداخت ناموفق ، کنسل شدن) درگاه پرداخت وضعیت را به سایت callback که مشخص کردیم ارسال می کند
درگاه پرداخت یا یک متد GET یک درخواست به آدرس Callback که به درگاه داده شده ارسال میکند که داخل آن وضعیت Status و Authority در قالب Query Parameters ارسال می شود مثلا ادرس :
http://localhost:8000/api/callback?Status=OK&Authority=authority
در مسیر زیر در سرور خودمون اطلاعات را پردازش میکنیم
4. تایید تراکنش (verify) :
صرفا دریافت وضعیت در callback برای تایید پرداخت کافی نیست چون این درخواست قابل دستکاری هست پس سرور باید یک درخواست به درگاه پرداخت بزند
سرور یک درخواست تایید با متد Verify به درگاه پرداخت ارسال می کند و همراه با آن مبلغ و Authority را میفرستد
درگاه پرداخت اطلاعات تراکنش را بررسی میکند و برای سرور می فرستد
سرور تمام اطلاعات بررسی می کند و اطلاعات را در دیتابیس ذخیره میکند (در اینجا بر اساس وضعیت موارد ذخیره می شود )
5. هدایت کاربر به سمت کلاینت (Client-side Redirect) :
سرور بر اساس وضعیت پرداخت شما را به صفحه مربوطه در کلاینت هدایت می کند و اینجا دیگه کاربر در درگاه پرداخت نیست و به پنل خودش در سایت یا اپلیکیشن (صفحه مربوطه) هدایت می شود
این فرآیند اصلی کار در ارتباط با درگاه های پرداخت هست ساختار اصلی همه درگاه های پرداخت به این صورت هست فقط در جزئیات آنها تفاوت هایی وجود دارد
نکته :
اگه به عنوان یک توسعه دهنده می خواهید از درگاه پرداخت در اپ خودتون استفاده کنید حتما سعی کنید مستندات مربوط به درگاه مربوطه را با دقت بخوانید و به جزئیات کامل دقت کنید چون اشتباه در محاسبات میتواند ضرر های بزرگی را به شما بزند این بخش قلب تپنده سایت شما محسوب می شود و خیلی حساس هست.
اگر به یادگیری گیت هم علاقمند هستید این دو مقاله من تفاوت merge و rebase و چطور با Git Squash تاریخچه پروژه راتمیز نگه داریم هم در این مورد شاید بتواند کمکی به شما بکند
