رازهای پشت‌صحنه پرداخت دیجیتال؛ از کاربر تا بانک مرکزی

مقدمه: چرا نقشهٔ پرداخت برای وکلا و مشاوران مهم است؟

اهمیت شناخت بازیگران

پشت هر پرداخت آنلاین ساده، زنجیره‌ای از بازیگران وجود دارد: کاربر → پذیرنده → بانک صادرکننده → بانک پذیرنده → شرکت پرداخت (PSP).

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

تأثیر بر دعاوی، قراردادها و رگولاتوری

در دعاوی تراکنش‌های ناموفق، آگاهی از نقشهٔ پرداخت مشخص می‌کند که دعوا باید علیه چه کسی طرح شود: بانک، پذیرنده یا شرکت پرداخت.

همچنین در قراردادهای فین‌تک یا در تحلیل سیاست‌های کارمزدی و تنظیم‌گری، داشتن نقشهٔ کامل End-to-End Flow نه تنها ابزار حقوقی بلکه ابزار استراتژیک برای مذاکره است.

بازیگران اصلی در اکوسیستم پرداخت

۱. کاربر (Payer / Payee)

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

۲. پذیرنده (Merchant)

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

۳. شرکت‌های پرداخت (PSP / PayFac)

واسطه‌هایی هستند که زیرساخت پذیرش تراکنش را فراهم می‌کنند. در ایران PSPها با مجوز شاپرک فعالیت می‌کنند. مثال: زرین‌پال یا شرکت پرداخت ملت.

۴. بانک صادرکننده (Issuer)

بانکی که کارت بانکی را برای مشتری صادر کرده است. این بانک مسئول کسر وجه از حساب مشتری است. مثال: مشتری با کارت ملت خرید می‌کند → بانک ملت نقش Issuer دارد.

۵. بانک پذیرنده (Acquirer)

بانکی که حساب پذیرنده نزد اوست و وجوه نهایی به آن منتقل می‌شود. مثال: اگر فروشگاه حسابش نزد بانک ملی باشد، بانک ملی Acquirer است.

۶. شبکه‌های پرداخت و تسویه

نقش «جاده» بین بانک‌ها و PSPها را ایفا می‌کنند. در ایران شتاب (Switch ملی) و شاپرک (شبکه پایاپای) وظیفه انتقال پیام‌ها و مدیریت تراکنش‌ها را دارند. در سطح بین‌المللی Visa و MasterCard همین کار را انجام می‌دهند.

۷. رگولاتور و نهادهای ناظر

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

جریان پول در پرداخت الکترونیک (Money Flow)

مسیر حرکت پول از لحظه کلیک پرداخت تا تسویه در حساب پذیرنده معمولاً سه فاز دارد: Authorization ← Clearing ← Settlement.

Authorization (احراز و رزرو) — بررسی کافی بودن موجودی/اعتبار، اعتبارسنجی کارت و صدور پاسخ مجاز/غیرمجاز. نتیجه: کد مرجع تراکنش
Clearing (پایاپای اطلاعاتی) — تبادل دسته‌ای اطلاعات تراکنش‌ها بین شبکه/بانک‌ها برای محاسبه خالص بدهکار–بستانکار. نتیجه: فایل‌های کلیرینگ
Settlement (تسویه وجوه) — انتقال واقعی پول بین حساب‌های بین‌بانکی/پذیرنده طبق نتایج کلیرینگ. نتیجه: واریز به پذیرنده

گام‌به‌گام: از سبد خرید تا واریز به حساب پذیرنده

۱) آغاز تراکنش

کاربر در درگاه/کارت‌خوان مبلغ را تأیید می‌کند؛ داده‌های کارت به شبکه ارسال می‌شود. Focus: صحت داده

۲) Authorization

بانک صادرکننده موجودی/اعتبار را چک می‌کند؛ در صورت OK مبلغ رزرو می‌شود. Outcome: Auth Code

۳) Clearing

شبکه پرداخت تراکنش‌ها را به‌صورت دسته‌ای پردازش و خالص بدهی‌ها را محاسبه می‌کند. Batch Files

۴) Settlement

بر مبنای کلیرینگ، انتقال واقعی وجه بین بانک‌ها انجام و به حساب پذیرنده واریز می‌شود. Net Transfer

تفاوت جریان پول: درگاه کارت، کارت‌به‌کارت، کیف‌پول

A) پرداخت درگاه کارت

مسیریابی از پذیرنده → PSP/شبکه → Issuer → پاسخ Auth
Clearing روزانه/دوره‌ای در شبکه؛ سپس Settlement به حساب پذیرنده
ویژگی: کارمزدهای MDR/Interchange مطرح است

B) کارت‌به‌کارت

انتقال آنی بین دو کارت؛ نقش پذیرنده به‌صورت مستقیم وجود ندارد
عموماً پس از احراز هویت/رمز پویا، انتقال فوری به مقصد
ویژگی: برای فروش کالا/خدمت ریسک تطبیقی و مغایرت بالا

C) کیف‌پول الکترونیک

شارژ کیف‌پول (on-ramp) ← پرداخت از موجودی داخلی ← تسویه دوره‌ای به پذیرنده
Clearing/Settlement درون‌سیستمی + تسویه نهایی بین‌بانکی
ویژگی: کاهش کارمزدهای تراکنش خرد، انعطاف در Refund/Partial

نکات عملی برای دعاوی و قراردادها

مرز مسئولیت را بر اساس فازها مشخص کنید: خطای Authorization (Issuer/PSP)، تأخیر در Clearing/Settlement (شبکه/بانک پذیرنده)، تسویه‌نشدن (Acquirer/توافق تسویه).
شواهد تراکنش (کد مرجع، لاگ درگاه، فایل کلیرینگ، رسید تسویه) را در قراردادها به‌عنوان ادله قابل استناد صراحتاً ذکر کنید.
در SLA تسویه، زمان‌بندی کلیرینگ/تسویه، استثناها، و جریمه تأخیر را دقیق بنویسید.
برای Refund/Chargeback، فرایند، زمان‌بندی، بار اثبات، و مدارک لازم را مرحله‌بندی کنید.

جریان داده و پیام‌های تراکنش (ISO 8583 & Data Flow)

علاوه بر جریان پول، هر پرداخت شبکه‌ای یک جریان داده دارد؛ این داده‌ها در قالب پیام‌های استاندارد (اغلب ISO 8583) بین پذیرنده، PSP، سوئیچ، بانک صادرکننده/پذیرنده ردوبدل می‌شود و در دعاوی و قراردادها اهمیت ادله‌ای دارد.

داده‌ها دقیقاً چه چیزهایی هستند؟

الف) داده‌های هویتی پرداخت

PAN (شماره کارت ماسک‌شده)، تاریخ انقضا
Cardholder Auth (PIN/OTP/EMV)
Merchant ID/Terminal ID

ب) داده‌های تراکنشی

مبلغ، ارز، کد عملیات (Processing Code)
تاریخ/زمان ارسال (Transmission DT)
کد مرجع (STAN/RRN/Auth Code)

پ) داده‌های سیستمی/ریسکی

POS Entry Mode، Channel، EMV Tags (55)
Risk Scores، Velocity، AVS/CVV Result
کد پاسخ (Response Code)

کلیات ISO 8583 — پیام چیست و چطور خوانده می‌شود؟

اجزای کلیدی

MTI (Message Type Identifier): نوع پیام — مثل 0100 درخواست احراز، 0110 پاسخ احراز.
Bitmap: تعیین می‌کند کدام فیلدها در پیام حضور دارند.
Data Elements (DEs): فیلدهای داده مانند:
DE2: PAN DE3: Processing Code DE4: Amount DE7: Transmission DT DE11: STAN DE37: RRN DE38: Auth Code DE39: Response Code DE41: TID DE42: MID DE55: EMV Data

زوج پیام نمونه — Authorization

درخواست (MTI=0100)

DE2=**** **** **** 1234
DE3=000000 (Purchase)
DE4=000000010000 (100.00)
DE7=0824153045
DE11=746281
DE14=2806
DE22=051 (Chip+PIN)
DE25=00
DE32=627412
DE35=Track2 (masked)
DE37=124578901234
DE41=TID12345
DE42=MID67890
DE55=EMV TLV...

پاسخ (MTI=0110)

DE7=0824153047
DE11=746281
DE37=124578901234
DE38=9F3A2C (Auth Code)
DE39=00 (Approved)
DE41=TID12345
DE42=MID67890

نکته ادله‌ای: برابری STAN/RRN بین درخواست و پاسخ، و کد پاسخ (DE39) برای اثبات مجاز/نامجاز بودن تراکنش حیاتی است.

کدهای پاسخ (Response Codes) — چند نمونه رایج

Approved — مجاز

Do not honor — رد توسط صادرکننده

Insufficient funds — موجودی ناکافی

Issuer inoperative — اختلال در صادرکننده

System malfunction — نقص سامانه

حریم خصوصی و امنیت داده — چه باید درج در قرارداد/سیاست‌ها شود؟

حداقل‌گرایی داده (Data Minimization): PAN باید ماسک شود؛ ذخیره CVV ممنوع؛ نگهداری EMV Tagها فقط در حد ضرورت.
رمزنگاری/امضای پیام (HSM, PIN Block, MAC): اطمینان از تمامیت و محرمانگی؛ مستندات HSM و کلیدها را در پیوست‌های فنی قرارداد درج کنید.
Logging & Retention: لاگ‌های Auth/Clearing/Settlement با زمان‌بندی نگهداری مشخص؛ دسترسی مبتنی بر نقش؛ Chain of Custody برای ارزش ادله‌ای.
Data Subject Rights: در پرداخت‌های ترکیبی با کیف‌پول، مسیر پاسخ‌گویی به درخواست‌های کاربر (دسترسی/حذف/اعتراض) را صریح بنویسید.
Incident Response: الزامات اعلان رخداد نشت داده، زمان‌بندی، مرجع اعلام و قالب گزارش؛ جریمه تأخیر.

نقاط ریسک داده‌ای و کنترل‌ها

Intercept/Replay: استفاده از TLS قوی، Nonce/Time-based Checks، محدودیت مجددارسال.
Data Leakage در پذیرنده/PSP: Tokenization، حذف داده‌های حساس از لاگ اپلیکیشن، ممیزی دوره‌ای.
Mismatch Auth/Settle: کنترل همسانی STAN/RRN، تطبیق دسته‌ای کلیرینگ با لاگ درگاه.
Weak Key Management: چرخش کلیدها، Dual Control/Split Knowledge، مستندات PCI DSS.
Privacy Breach: ماسک‌کردن PAN، Pseudonymization، حداقلی‌سازی EMV/Track.

یادداشت حقوقی: در قراردادهای SLA/DPAs، شاخص‌های صحت داده (مثلاً نرخ مغایرت مجاز، RTO/RPO) و الزامات Audit را الزام‌آور کنید.

کارمزدها و مدل‌های درآمدی (Interchange, MDR, Split Fees)

هر تراکنش پرداخت، علاوه بر جریان پول، دارای جریان کارمزد است. شناخت اجزای کارمزد برای تنظیم قرارداد، تحلیل دعاوی و طراحی قیمت‌گذاری حیاتی است.

۱) اجزای اصلی کارمزد

Interchange Fee (بین‌بانکی)

سهمی که به بانک صادرکننده (Issuer) می‌رسد؛ معمولاً درصدی از مبلغ + مبلغ ثابت. ریسک/احراز هویت/نوع کارت اثرگذار است

MDR (Merchant Discount Rate)

کل نرخی که از پذیرنده کسر می‌شود (در مدل‌های پذیرنده‌پرداخت). می‌تواند شامل Interchange + شبکه + PSP باشد.

Scheme/Network Fees

کارمزدهای شبکه (شتاب/شاپرک یا Visa/Mastercard) بابت سوییچ، پایاپای و خدمات شبکه.

PSP/PayFac Fees

سهم شرکت پرداخت/تسهیل‌گر بابت درگاه، ریسک، پشتیبانی، ابزارها و گزارش‌دهی.

۲) مدل‌های قیمت‌گذاری رایج

الف) Blended (نرخ ترکیبی) — یک نرخ ثابت٪ برای پذیرنده، ساده اما شفافیت کمتر روی اجزا.

ب) Interchange++ — پذیرنده دقیقاً Interchange + Network + حاشیه PSP را می‌پردازد؛ شفاف، اما پیچیده‌تر.

ج) Tiered (طبقه‌بندی‌شده) — نرخ‌های متفاوت بر اساس MCC، ریسک، مبلغ، کانال (Card Present/Not Present).

د) Flat + Fixed — درصد ثابت + مبلغ ثابت به‌ازای هر تراکنش (برای تراکنش‌های خرد مفید است).

هـ) Zero-MDR/یارانه‌ای — پذیرنده مستقیم نمی‌پردازد؛ هزینه از بودجه/یارانه/شبکه تأمین یا در جای دیگر بازیابی می‌شود.

۳) مثال عددی تقسیم کارمزد (Split) — گام‌به‌گام

فرض: مبلغ تراکنش = 1,000,000 ریال | مدل Blended با MDR = 1.5% + مبلغ ثابت 500 ریال

MDR درصدی: 1,000,000 × 1.5% = 15,000 ریال
مبلغ ثابت:                                  500 ریال
کل کارمزد کسرشده از پذیرنده:         15,500 ریال

تقسیم فرضی

Issuer (Interchange): 9,000
Network/Switch: 2,500
PSP/PayFac: 4,000

خالص واریزی به پذیرنده

1,000,000 − 15,500 = 984,500 ریال

نکته: در مدل Interchange++ به‌جای MDR واحد، هر جزء به‌صورت جدا روی صورت‌حساب پذیرنده می‌آید.

۴) Refund / Chargeback و اثر بر کارمزد

Refund کامل/Partial: تکلیف بازپرداخت کارمزدها را مشخص کنید (بازگشت بخشی از MDR؟ مبلغ ثابت برگشت‌ناپذیر؟ زمان‌بندی تسویه معکوس).
Chargeback: کارمزد رسیدگی، مستندسازی، پنالتی‌های شبکه و بار اثبات را در SLA/ضمائم فنی بنویسید.
Settlement Netting: بازپرداخت‌ها در چرخه بعدی از تسویه‌های آتی تهاتر می‌شود—نحوه نمایش در گزارش را شفاف کنید.

۵) Surcharging / Discounting و شفافیت قیمت

اگر پذیرنده قصد افزودن کارمزد به مشتری (Surcharge) را دارد، محدودیت‌های قانونی/بخشی را بررسی و در قرارداد تصریح کنید.
برخی حوزه‌ها فقط Cash Discount را مجاز می‌دانند؛ سازوکار اطلاع‌رسانی به مصرف‌کننده را روشن کنید.
نمایش قیمت نهایی به مشتری در صفحات Checkout الزام شفافیت و کاهش ریسک شکایت است.

۶) نکات عملی: تراکنش‌های خُرد، کیف‌پول و سیاست‌های کارمزدی

پرداخت‌های خرد: مدل‌های Flat+Fixed را طوری تنظیم کنید که مبلغ ثابت بلعنده ارزش تراکنش نشود؛ سقف/حداقل تنظیم کنید.
کیف‌پول: کارمزد روی مسیرهای On-Ramp/Off-Ramp و تسویه‌های دوره‌ای جداگانه تعریف و در گزارش‌ها تفکیک شود.
یارانه/صفر-کارمزد: اگر پذیرنده مستقیم نمی‌پردازد، منبع جبران (بودجه/تبلیغ/Cross-Subsidy) و دوام آن را شفاف کنید.

۷) چک‌لیست قراردادی کارمزدها (برای وکلا/مشاوران)

تعاریف شفاف: MDR، Interchange، Network، Fixed Fee، حداقل کارمزد ماهانه، Rolling Reserve.
فرمول دقیق و مثال عددی: ضمیمه قیمت‌گذاری با سناریوهای مبلغی مختلف (خُرد/کلان/اقساط/کیف‌پول).
SLA تسویه: زمان‌بندی Clearing/Settlement، استثناها، جریمه تأخیر، مستندات گزارش.
Refund/Chargeback: مسئولیت‌ها، مهلت‌ها، مدارک لازم، کارمزد رسیدگی/پنالتی شبکه.
تطبیق و ممیزی: دسترسی به لاگ‌ها و فایل‌های کلیرینگ برای تطبیق کارمزد؛ حق بازرسی شخص ثالث.
تغییرات کارمزدی: مکانیسم اطلاع‌رسانی، دوره اعتراض/فسخ، محدودیت‌های افزایش یک‌طرفه.
Cross-border/FX: نرخ تبدیل، کارمزد تبدیل، زمان تسویه ارزی، ریسک نوسان.

۸) دیاگرام متنی تقسیم کارمزد (نمونه)

[Amount] 1,000,000
   │
   ├─ MDR 1.5% + 500  →  15,500  (Total Fee)
   │     ├─ Interchange (Issuer) → 9,000
   │     ├─ Network/Switch      → 2,500
   │     └─ PSP/PayFac          → 4,000
   │
   └─ Net to Merchant  → 984,500

یادداشت: تغییر MCC، کانال (کارت‌حاضر/غایب)، نوع کارت، و ریسک می‌تواند هر سه جزء را تغییر دهد.

نقشهٔ ریسک در چرخهٔ پرداخت

چرخهٔ پرداخت علاوه بر جریان پول و داده، سرشار از ریسک‌های عملیاتی، حقوقی و تطبیقی است. شناخت این ریسک‌ها برای وکلا، مشاوران کسب‌وکار و مدیران ریسک حیاتی است.

۱) ریسک‌های عملیاتی

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

مثال: فروشگاه اینترنتی در روز بلک‌فرایدی با خطای PSP مواجه شد؛ ده‌ها مشتری پول پرداخت کردند اما سفارش ثبت نشد → دعوای حقوقی میان پذیرنده و PSP.

۲) ریسک‌های حقوقی

تراکنش ناموفق با کسر وجه: مشتری علیه بانک یا پذیرنده اقامه دعوا می‌کند.
مسئولیت داده: افشای PAN یا CVV در لاگ‌ها → نقض حریم خصوصی.
ابهام قراردادی: عدم تعیین دقیق SLA تسویه یا Refund.

مثال: کاربری پولش کسر شد اما بلیت هواپیما صادر نشد؛ دادگاه با بررسی کد مرجع تراکنش، PSP را مسئول جبران دانست.

۳) ریسک‌های تطبیقی (Compliance)

عدم رعایت KYC/AML: جریمه‌های سنگین برای پذیرنده و PSP.
تحریم‌ها و محدودیت‌های ارزی: بلاک‌شدن تراکنش‌های بین‌المللی.
تطابق PCI DSS: در صورت عدم رعایت استاندارد، خطر نشت داده و جریمه شبکه‌های کارت.

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

۴) نقشهٔ ریسک (Risk Map)

نوع ریسک	نمونه	پیامد	راهکار کنترلی
عملیاتی	قطع شبکه PSP	از دست‌رفتن اعتماد مشتری	Redundancy + SLA
حقوقی	کسر وجه بدون سرویس	دعوای مشتری علیه بانک/PSP	SLA + مستندات شفاف
تطبیقی	نبود KYC	پولشویی + جریمه	سیاست AML و مانیتورینگ

مطالعهٔ موردی: تراکنش واقعی از خرید آنلاین تا تسویه

سناریو: مشتری از فروشگاه آنلاین «کتاب‌فروش» یک کتاب به مبلغ 1,000,000 ریال خریداری می‌کند. درگاه توسط PSP «پرداخت‌یار» ارائه شده، حساب پذیرنده نزد بانک «ملی» (Acquirer) است و کارت مشتری از بانک «ملت» (Issuer).

۱) خط زمانی تراکنش (Timeline)

T0 — Checkout: مشتری دکمه «پرداخت» را می‌زند؛ درخواست به PSP ارسال می‌شود.
T1 — Authorization (0100/0110): Issuer احراز می‌کند؛ پاسخ 00 (Approved) همراه با Auth Code.
T2 — Clearing (Batch): تراکنش در فایل کلیرینگ روزانه شبکه ثبت می‌شود.
T3 — Settlement: مطابق نتایج کلیرینگ، وجه خالص به حساب پذیرنده واریز می‌شود.
T4 — گزارش‌ها: لاگ درگاه، گزارش PSP، فایل کلیرینگ، رسید تسویه در دسترس می‌ماند.

۲) اسنپ‌شات داده‌های تراکنش (نمونه)

درخواست احراز (MTI=0100)

DE2=**** **** **** 1234
DE3=000000 (Purchase)
DE4=000000100000  (1,000,000 IRR)
DE7=0824201525     (Date/Time)
DE11=746381        (STAN)
DE22=051           (Chip+PIN)
DE37=240824015251  (RRN)
DE41=TID-KETAB01
DE42=MID-KETAB-STORE

پاسخ احراز (MTI=0110)

DE11=746381
DE37=240824015251
DE38=9F3B1C    (Auth Code)
DE39=00        (Approved)
DE41=TID-KETAB01
DE42=MID-KETAB-STORE

نکته ادله‌ای: تطبیق STAN و RRN بین درخواست/پاسخ + کد پاسخ 00، مبنای اثبات مجاز بودن تراکنش است.

۳) لاگ‌های پذیرنده و PSP

[Checkout] OrderID=BK-34921 Amount=1000000
[PSP-Redirect] MID=KETAB-STORE TID=KETAB01
[Auth-Resp] RRN=240824015251 Auth=9F3B1C RC=00
[Order-Update] Status=Paid Capture=Success

نکته عملی: ثبت OrderID کنار RRN/AuthCode ارتباط بین سامانه فروش و شبکه پرداخت را مستند می‌کند.

۴) کارمزد و تسویه (گزارش عددی)

جزئیات کارمزد (Blended)

Amount: 1,000,000 IRR
MDR: 1.5% = 15,000
Fixed: 500
Total Fee: 15,500
Net to Merchant: 984,500

تسویه به پذیرنده

Clearing: همان روز ساعت 23:30
Settlement: روز بعد ساعت 10:45
واریزی: 984,500 ریال به IBAN پذیرنده

۵) سناریوی اختلاف (Dispute): «کسر وجه شد، سفارش ثبت نشد»

مشتری مدعی است پول از کارت کسر شده، اما سفارش در سایت ثبت نشده. در بررسی:

کد پاسخ Issuer = 00 (مجاز) → پرداخت موفق سمت شبکه
لاگ پذیرنده خطای Order-Write Timeout را نشان می‌دهد → اشکال اپلیکیشن/DB
فایل کلیرینگ تراکنش را در دستهٔ موفق ثبت کرده است.

تحلیل مسئولیت

احراز و کسر وجه صحیح بوده (Issuer/PSP OK)
عدم ثبت سفارش ناشی از خطای پذیرنده → تعهد به ایفای سرویس یا Refund

راهکار عملی

صدور Refund فوری یا ارسال کالا
ایجاد Idempotency Key در Callback پرداخت
الزام Write-Ahead Log و Queue برای ثبت سفارش

۶) بسته ادله (Evidence Pack) برای حل اختلاف

مدرک	هدف	مالک/مسئول
RRN/STAN/AuthCode + RC	اثبات موفقیت احراز	PSP/Issuer
فایل کلیرینگ	ثبت در پایاپای	Network/Acquirer
لاگ پذیرنده (OrderID لینک‌شده به RRN)	شناسایی خطای اپلیکیشن	Merchant
رسید تسویه	اثبات واریز وجه خالص	Acquirer

توصیه قراردادی: در SLA/ضمائم فنی، ساختار و فرمت ادله، مهلت ارائه و کانال رسمی تبادل را الزام کنید.

۷) اگر سناریو عوض شود چه؟ (What‑If)

RC=51 (موجودی ناکافی): مسئولیتی بر عهده پذیرنده/PSP نیست؛ پیام «ناموفق» باید صحیح نمایش یابد.
RC=91 (اختلال صادرکننده): تراکنش «نامشخص»؛ مکانیسم Retry/Timeout و ثبت وضعیت معلق ضروری است.
Refund Partial: در تسویه دوره بعدی تهاتر می‌شود؛ نمایش شفاف در گزارش‌های مالی الزامی است.
Chargeback: مدارک پذیرنده (تحویل/Proof of Service) و مسیر اعتراضی طبق مقررات شبکه.

جمع‌بندی و نقشهٔ نهایی End-to-End Flow

همه‌چیز از کلیک مشتری روی دکمه پرداخت شروع می‌شود و تا تسویه خالص در حساب پذیرنده ادامه پیدا می‌کند. در این میان پول، داده و کارمزد سه خط موازی‌اند که بازیگران مختلف روی آن نقش‌آفرینی می‌کنند.

نقشهٔ متنی جریان (Money + Data + Fees)

[User]  ----(Card Data + Amount)---->  [Merchant/PSP]
   │
   │   (ISO8583: MTI=0100 Request)
   ▼
[Network (Shaparak/Visa)]  ---->  [Issuer Bank]
   │                                │
   │   (ISO8583: MTI=0110 Response) │
   │<-------------------------------┘
   │
   ├──> Authorization OK (AuthCode, RC=00)
   │
   ▼
[Clearing] (Batch, Netting)
   ▼
[Settlement] (Funds Transfer)
   ▼
[Acquirer Bank] ----> [Merchant Account]

┌───────── Fees Split ─────────┐
 Interchange (Issuer)   → 9,000
 Network/Switch         → 2,500
 PSP/PayFac             → 4,000
 Net to Merchant        → 984,500
└──────────────────────────────┘

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

نکات طلایی برای دعاوی و قراردادها

همیشه کدهای مرجع تراکنش (RRN/STAN/Auth) را به‌عنوان ادله حقوقی ذخیره کنید.
SLA تسویه باید شامل مهلت دقیق Clearing/Settlement و جریمه تأخیر باشد.
Refund و Chargeback را با فرآیند، زمان‌بندی، مسئولیت‌ها و کارمزد رسیدگی مشخص کنید.
مدل کارمزدی (Blended/Interchange++/Flat) را به‌صورت شفاف و با مثال عددی در قرارداد بیاورید.
برای دعاوی محتمل (کسر وجه بدون سرویس، تاخیر در تسویه، مغایرت کلیرینگ) بسته ادله و مرجع رسیدگی پیش‌بینی کنید.

چرا این نقشه برای وکلا و مشاوران حیاتی است؟

چون در هر اختلاف مالی، این نقشه مسیر را مشخص می‌کند: چه کسی مسئول است، چه داده‌ای باید ارائه شود و چه کارمزدی قابل مطالبه یا دفاع است. داشتن این نقشه = داشتن نقشه گنج برای دعاوی، تنظیم قراردادهای پرداخت و تحلیل ریسک.