→ بازگشت به نقشه‌های معماری
SPEC ۰۱ · مشخصات فنی سامانه

معماری درگاه پرداخت: سوئیچ‌های ترافیک بالا و دفترهای کل توزیع‌شده

۸ مهر ۱۴۰۵

[معماری سیستم][مقاله فنی][ISO 8583][Redis][دفترهای کل توزیع‌شده]
SLA تأخیر درگاه: کمتر از ۲۵۰ میلی‌ثانیه

درگاه پرداخت، مرز تبدیل پروتکل و مسیریابی میان سامانه پذیرنده، بانک پذیرنده، شبکه کارت و بانک صادرکننده است. سوئیچ با دسترس‌پذیری بالا به سازگاری قطعی، سقف تأخیر زیر یک ثانیه و جداسازی کامل وضعیت تغییرپذیر از واقعیت تغییرناپذیر تراکنش نیاز دارد.

حدود ثابت عملکرد سیستم

  • بودجه تأخیر سوئیچ: SLA رفت‌وبرگشت کمتر از ۲۵۰ میلی‌ثانیه
  • TTL قفل Idempotency: عمر کلید قفل Redis برابر با ۸۶٬۴۰۰ ثانیه
  • پروتکل سوئیچ: پیام مبتنی بر Bitmap در ISO 8583
  • الگوی ذخیره‌سازی: ثبت افزایشی واقعیت / رویداد در دفتر کل دوطرفه

۰۱. هدف معماری: مدل واقعیت در برابر وضعیت

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

پلتفرم پرداخت، اجرا را به وضعیت‌های گذرا و واقعیت‌های تغییرناپذیر تفکیک می‌کند:

  • وضعیت: مراحل تغییرپذیر چرخه عمر را نشان می‌دهد: Pending، Authorized، Captured و Settled. سامانه آن‌ها را در ذخیره‌ساز توزیع‌شده درون‌حافظه‌ای، با قفل‌گذاری خوش‌بینانه، کش می‌کند.
  • واقعیت: رویداد کسب‌وکار تغییرناپذیر با ثبت صرفاً افزایشی است: AuthRequested، FundsReserved و CaptureConfirmed. سامانه واقعیت‌ها را به‌صورت دائمی در دفتر کل دوطرفه می‌نویسد و امکان تغییر آن‌ها را نمی‌دهد.

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

نقشه شماتیک دفتر کل دوطرفه و تخصیص دومرحله‌ای موجودی

۰۲. سازوکار اصلی پروتکل

قفل Idempotency و قفل وضعیت

کاربر سرویس، توکن یکتای UUIDv4 را در سرآیند درخواست می‌فرستد. درگاه، فرمان اتمیک SETNX را روی خوشه Redis با TTL برابر با ۸۶٬۴۰۰ ثانیه، معادل ۲۴ ساعت، اجرا می‌کند. اگر کلید موجود باشد، سامانه درخواست تکراری را حذف می‌کند یا نتیجه کش‌شده اجرای قبلی را برمی‌گرداند. این کنترل جلوی تسویه تکراری را می‌گیرد.

مسیریابی پروتکل ISO 8583

درگاه‌های API، پیام ورودی JSON را به قالب دودویی مبتنی بر Bitmap در ISO 8583 سریال‌سازی می‌کنند. فیلدها در جایگاه استاندارد قرار می‌گیرند:

  • فیلد ۳: کد پردازش، شامل خرید، برگشت تراکنش و استعلام مانده
  • فیلد ۴: مبلغ تراکنش، به‌صورت عدد صحیح در کوچک‌ترین واحد پول با صفرهای پیشرو
  • فیلد ۱۱: شماره پیگیری ممیزی سیستم (STAN)
  • فیلدهای ۴۱ و ۴۲: شناسه پایانه و کد شناسایی پذیرنده کارت

بسته‌ها از تونل رمز‌شده IPsec VPN به پردازشگر بانک پذیرنده می‌رسند و باید دقیقاً از قالب قاب‌بندی دودویی بانک پیروی کنند.

اجماع توزیع‌شده و ACID

ذخیره‌ساز دفتر کل به سازگاری قابل‌ترتیب‌سازی در چند منطقه نیاز دارد. خوشه‌های شاردشده PostgreSQL یا CockroachDB از اجماع Raft استفاده می‌کنند. ثبت تراکنش، توازن دفتر کل دوطرفه را اعمال می‌کند: هر ثبت بدهکار باید ثبت بستانکار دقیقاً برابر داشته باشد تا اختلاف مالی در پلتفرم صفر بماند.

تخصیص بودجه تأخیر درگاه با هدف ۲۵۰ میلی‌ثانیه

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

  • برقراری اتصال TLS در ورودی: ۲۵ میلی‌ثانیه
  • قفل Mutex و امتیازدهی ریسک: ۳۵ میلی‌ثانیه
  • اخذ مجوز از میزبان اصلی بانک: ۱۴۰ میلی‌ثانیه
  • تسویه و ثبت قطعی در پایگاه داده دفتر کل: ۳۵ میلی‌ثانیه
  • بسته‌بندی پاسخ و ارسال خروجی: ۱۵ میلی‌ثانیه

۰۳. مقایسه توپولوژی: سوئیچ شاپرک و الگوی جهانی

بُعد معماری پذیرندگان جهانی (Stripe / Adyen) سوئیچ ایران (شاپرک / PSPها)
توپولوژی شبکه شبکه مش چندمنطقه‌ای با اتصال مستقیم به Visa و Mastercard. مسیریاب متمرکز پایاپای ملی که سوئیچ PSPهای مجاز را متصل می‌کند.
ذخیره‌سازی توکن مخازن امن PCI-DSS سطح ۱ با رمزنگاری کلید در چند ابر. تجهیزات اختصاصی ماژول امنیت سخت‌افزاری (HSM) در محل سازمان.
تبدیل پروتکل نقاط پایانی REST با سریال‌سازی پویا به پروتکل شبکه کارت. پیام دودویی با قالب ثابت ISO 8583 روی تونل‌های APN خصوصی.
کشف تقلب و کنترل ریسک امتیازدهی پویای یادگیری ماشین در لبه و احراز هویت بدون چالش با 3D-Secure 2.0. تأیید متمرکز بانک، فهرست‌های مسدودی ملی و الزام رمز پویای پیامکی.
تأخیر تسویه پایاپای پیوسته با دسته‌های پرداخت چرخشی T+2. چرخه‌های متمرکز پایاپای و تسویه دسته‌ای پایا و ساتنا.

۰۴. زنجیره پردازش تراکنش سوئیچ

  • ورودی: سامانه پذیرنده، درخواست POST را روی HTTPS با TLS 1.3 و کلید یکتای Idempotency آغاز می‌کند.
  • قفل کش: خوشه درون‌حافظه‌ای Redis، توکن را با SETNX اتمیک بررسی می‌کند. پردازش درخواست تکراری بلافاصله متوقف می‌شود.
  • سریال‌ساز: موتور تبدیل پروتکل، فیلدهای JSON را به پیام دودویی بسته‌بندی‌شده مبتنی بر Bitmap در ISO 8583 تبدیل می‌کند.
  • سوئیچ اصلی: بسته ISO از خطوط APN / VPN به میزبان کارت می‌رسد.
  • دفتر کل تسویه: سامانه پاسخ را از قالب انتقال خارج می‌کند، وضعیت تغییرپذیر را به‌روز می‌کند و ثبت بدهکار و بستانکار را به دفتر کل دوطرفه تغییرناپذیر می‌افزاید.
توپولوژی سوییچ پرداخت: خط لوله تبادل پیام‌های ISO 8583

۰۵. حالت‌های خرابی و تاب‌آوری عملیاتی

  • پایان مهلت پاسخ میزبان بانکی: اگر بانک پذیرنده بالادست ظرف ۱۵ ثانیه پاسخ ندهد، سوئیچ به‌صورت خودکار پیام برگشت ISO 8583 با شناسه نوع پیام MTI 0400 تولید می‌کند تا رفع مسدودی وجه کارت کاربر را تضمین کند.
  • مدیریت عمر قفل: عمر قفل توزیع‌شده Redis باید از طولانی‌ترین بازه تلاش مجدد بانکی، یعنی ۸۶٬۴۰۰ ثانیه، بیشتر باشد تا تلاش‌های تکراری دیرهنگام را پوشش دهد.