پرداخت یارپلاس را با درگاه‌های داخلی پیاده کردم. بعد از اتصال اولیه، بیشتر کار به وضعیت‌های نامشخص مربوط بود: پرداختی که پاسخش نرسیده، درخواست تکراری و اشتراکی که باید فعال شود.
تأیید تراکنش
برگشتن کاربر از درگاه برای ثبت پرداخت کافی نبود. سرور باید نتیجه را از درگاه استعلام می‌کرد و مبلغ و شناسه سفارش را با درخواست اولیه تطبیق می‌داد.
درگاه‌ها را پشت رابط مشترک PaymentProvider قرار دادم تا منطق اشتراک به جزئیات یک درگاه وابسته نباشد.
درخواست تکراری
یک درخواست ممکن است به‌دلیل قطع شبکه یا ارسال دوباره، بیش از یک بار برسد. برای هر درخواست پرداخت شناسه یکتا نگه داشتم. تأیید و فعال‌سازی اشتراک باید با اجرای دوباره همان درخواست، نتیجه قبلی را برگرداند؛ بدون ثبت پرداخت یا دسترسی جدید. این همان رفتار idempotency است.
شناسه تراکنش در پایگاه داده هم یکتا بود. برخورد با رکورد تکراری بخشی از مسیر پردازش بود.
وقتی پاسخ نمی‌رسد
گاهی پرداخت در درگاه انجام شده، اما وضعیت داخلی هنوز در انتظار می‌ماند. یک کار زمان‌بندی‌شده تراکنش‌های قدیمی را پیدا می‌کرد، وضعیتشان را از درگاه می‌پرسید و رکورد داخلی را تطبیق می‌داد.
این فرایند برای پیدا کردن پرداخت‌های موفقی بود که اشتراک متناظرشان فعال نشده بود.
تاریخچه و مبلغ
برای تغییر وضعیت‌ها رویداد جدا ثبت کردم: زمان ساخت درخواست، دریافت پاسخ، نتیجه تأیید و فعال‌سازی اشتراک. این تاریخچه برای بررسی مغایرت‌ها و پاسخ به کاربر به کار می‌آمد.
مبلغ را به‌صورت عدد صحیح و با واحد مشخص نگه می‌داشتم. تفاوت ریال و تومان باید در مرز اتصال به درگاه روشن باشد.
چیزی که زودتر اضافه می‌کردم
تطبیق تراکنش‌ها را از شروع پروژه اضافه می‌کردم. رسیدگی دستی به وضعیت‌های نامشخص وقت می‌گیرد و بررسی دوباره هر مورد هم آسان نیست.