آموخته‌هایی از فین‌تک و یکپارچه‌سازی پرداخت‌ها
قابلیت پرداخت در برنامه محصول اغلب ساده به نظر می‌رسد: مبلغ را بگیرید، مشتری را به فراهم‌کننده بفرستید و پیام موفقیت نشان دهید. در محیط واقعی، این مسیر دیدنی تنها یک بخش سیستم است.
پول میان سیستم‌های مستقل جابه‌جا می‌شود. درخواست‌ها مهلت را از دست می‌دهند، مشتری صفحه را می‌بندد، فراهم‌کننده اطلاع‌رسانی را تکرار می‌کند و بانک یا درگاه ممکن است پس از پایان درخواست اصلی نتیجه بدهد. انجنیری مطمئن پرداخت با پذیرفتن این واقعیت‌ها آغاز می‌شود.
این مقاله اصول عمومی انجنیری از کار فین‌تک و پرداخت را بررسی می‌کند و هیچ سیستم محرمانه کارفرما، توافق شریک، طراحی خصوصی یا داده مشتری را شرح نمی‌دهد.
پرداخت را یک روند دارای حالت بدانید
انتقال مرورگر منبع قابل اعتماد حالت نهایی پرداخت نیست. مشتری شاید هرگز برنگردد و نشانی برگشت نیز بدون معامله تکمیل‌شده فراخوانی شده می‌تواند.
پرداخت را با حالت‌های روشن مانند ایجادشده، در انتظار، تأییدشده، تکمیل‌شده، ناکام، منقضی، برگشت‌داده‌شده یا لغوشده مدل می‌کنم. حالت دقیق به محصول و فراهم‌کننده وابسته است، اما هر انتقال باید منبع و قانون مشخص داشته باشد.
برنامه باید سابقه معامله خود و شناسه‌های فراهم‌کننده را برای بررسی بعدی نگه دارد. این سابقه بنیاد پشتیبانی، تطبیق حساب، بازپرداخت و تاریخچه بررسی می‌شود.
درخواست‌های تکراری را امن بسازید
دوباره‌کوشی در سیستم توزیع‌شده عادی است. کاربر دوبار دکمه می‌زند، موبایل پس از قطع ارتباط درخواست را تکرار می‌کند و فراهم‌کننده یک Webhook را چندبار می‌فرستد.
جلوگیری از اثر تکراری مانع ایجاد پیامد مالی تکراری می‌شود. درخواست یا عملیات تجارتی کلید ثابت می‌گیرد و سیستم تشخیص می‌دهد که همان هدف قبلاً پردازش شده است.
این محافظت باید اثر تجارتی را پوشش دهد، نه تنها پاسخ HTTP را. ساخت دو سفارش داخلی و گرفتن پول تنها برای یکی هنوز مشکل جدی سازگاری است.
هر پیام فراهم‌کننده را بررسی کنید
Webhook و Callback داده غیرقابل اعتماد اند. برنامه باید امضا یا روش هویت‌سنجی فراهم‌کننده، شناسه‌ها و مبلغ مورد انتظار را بررسی و رویداد نادرست یا غیرمنتظره را رد کند.
اسرار باید بیرون کود منبع نگهداری شوند، دسترسی محدود و تعویض‌شان ممکن باشد. گزارش‌ها باید بدون افشای اعتبارنامه، جزئیات کامل پرداخت یا معلومات حساس، بررسی ناکامی را ممکن سازند.
اسناد فراهم‌کننده بخشی از قرارداد یکپارچه‌سازی اند، اما تنها محافظ نیستند. اعتبارسنجی محلی و قوانین کسب‌وکار ضروری می‌مانند.
تجربه مشتری را از پردازش نهایی جدا کنید
مشتری به رابط روشن و پاسخ‌گو نیاز دارد، اما بخشی از کار پرداخت باید در پس‌زمینه انجام شود. بررسی، ساخت رسید، اطلاع‌رسانی، به‌روزرسانی تسویه و اجرای خدمات بعدی می‌توانند از صف استفاده کنند.
رابط باید حالت انتظار را صادقانه توضیح دهد. نشان‌دادن ناکامی به دلیل چند ثانیه تأخیر در تأیید باعث تلاش تکراری می‌شود. نشان‌دادن موفقیت پیش از بررسی نیز چیزی را وعده می‌دهد که سیستم تأیید نکرده است.
تجربه خوب حالت واقعی را بازتاب می‌دهد و گام بعدی را روشن می‌سازد.
برای تطبیق حساب طراحی کنید
حتی روند دقیق آنی به راهی برای مقایسه سوابق داخلی با فراهم‌کننده نیاز دارد. رویداد ممکن است دیر برسد، گم شود یا هنگام قطع خدمت پردازش گردد.
تطبیق بررسی می‌کند که دو سیستم درباره معاملات مهم توافق دارند. تفاوت باید به کار عملیاتی آشکار تبدیل شود، نه خطای خاموش داده. با توجه به فراهم‌کننده، این کار شامل جستجوی معامله، فایل تسویه، گزارش یا بررسی زمان‌بندی‌شده می‌شود.
روند باید تاریخچه را نگه دارد؛ اصلاح حالت نباید شواهد چگونگی اختلاف را پاک کند.
مالکیت ناکامی را تعیین کنید
هنگام ناکامی پرداخت، مشتری به راهنمای قابل فهم و تیم عملیات به معلومات قابل اجرا نیاز دارد. پیام عمومی خطا و Stack Trace به هیچ‌کدام کمک نمی‌کند.
ناکامی‌ها را در صورت امکان دسته‌بندی می‌کنم: اعتبارسنجی، موجودی ناکافی، رد فراهم‌کننده، ختم مهلت، هویت‌سنجی، تنظیمات، درخواست تکراری یا نتیجه نامعلوم. پاسخ عمومی امن و ساده می‌ماند و گزارش و داشبورد داخلی جزئیات بررسی را می‌دهند.
دوباره‌کوشی تنها برای عملیات قابل تکرار باشد. نتیجه نامعلوم پرداخت معمولاً پیش از تلاش دوباره برای برداشت به بررسی نیاز دارد.
عمل‌های مالی را قابل بررسی نگه دارید
ایجاد پرداخت، تغییر حالت، بازپرداخت، اصلاح دستی و عمل اداری باید تاریخچه بررسی مناسب داشته باشند. عمل‌های ویژه به صلاحیت سنجیده و در خطرهای بلندتر شاید به کنترول تأیید قوی‌تر نیاز دارند.
قابلیت بررسی از خدمات مشتری، پاسخ به رویداد، بازبینی مالی و حساب‌دهی پشتیبانی می‌کند و باید همراه روند طراحی شود، نه پس از مشکل از گزارش عمومی بازسازی گردد.
دامنه داده حساس را محدود کنید
امن‌ترین داده حساس پرداخت، داده‌ای است که برنامه هرگز دریافت یا ذخیره نمی‌کند. صفحه پرداخت میزبانی‌شده، Tokenization و گردآوری توسط فراهم‌کننده در صورت تناسب، میزان در معرض خطر بودن را کم می‌کنند.
نیازهای امنیتی و قانونی به روش پرداخت، کشور، فراهم‌کننده و مدل کسب‌وکار وابسته اند. تیم انجنیری باید الزامات را با متخصصان حقوقی، رعایت مقررات و امنیت تأیید کند و تصور نکند یکپارچه‌سازی صرفاً فعال کافی است.
انتزاعی با راه خروج بسازید
محصول ممکن است با خدمات محلی، درگاه جهانی، بانک یا چند فراهم‌کننده یکپارچه شود. قرارداد داخلی روشن پرداخت، جزئیات فراهم‌کننده را از سفارش، اشتراک یا کمک مالی دور نگه می‌دارد.
این انتزاع نباید وانمود کند همه فراهم‌کنندگان یکسان اند. باید برای قابلیت‌ها، حالت‌ها و روندهای عملیاتی ویژه هر فراهم‌کننده جا داشته باشد. هدف تفاوت کنترول‌شده است، نه رابط بیش از حد ساده‌ای که رفتار مهم را پنهان کند.
اطمینان اعتماد می‌سازد
کار فین‌تک و پرداخت تنها یکپارچه‌سازی API نیست؛ مدیریت حالت، امنیت، مدیریت ناکامی، تطبیق، قابلیت بررسی، عملیات و ارتباط صادقانه با کاربر است.
قوی‌ترین پیاده‌سازی زمانی قابل فهم می‌ماند که مسیر ایده‌آل خراب شود؛ دقیقاً همان زمانی که مشتری، تیم پشتیبانی و مالک کسب‌وکار بیشترین دقت را از نرم‌افزار می‌خواهند.