چرخه‌ی پرداخت: از اتوریزیشن تا تسویه
چرخه‌ی پرداخت، توالی ثابتی است که هر پرداخت از لحظه‌ی تأیید تا نشستن وجه در حساب پذیرنده طی می‌کند: اتوریزیشن، کپچر، کلیرینگ، تسویه و پرداخت به پذیرنده. هر مرحله دقیقاً یک کار انجام می‌دهد و پول پس از هر مرحله در وضعیتی متفاوت است. بیشتر مردم پرداخت کارتی را رویدادی واحد در لحظه‌ی لمس کارت تصور می‌کنند، در حالی که زنجیره‌ای است؛ و تقریباً هر آنچه در پرداخت‌ها درست یا غلط پیش می‌رود، به این دلیل است که این مراحل جدا از هم‌اند، نه هم‌زمان.
شناخت این زنجیره تفاوت میان پرداختی است که خودش مغایرت‌گیری می‌شود و یک تیکت پشتیبانی. پس یک بار آن را از ابتدا تا انتها و به ترتیب مرور کنیم.
اتوریزیشن: یک بلوکه، نه انتقال
اتوریزیشن یک پرسش است، نه یک جابه‌جایی. وقتی کارت لمس می‌شود، درخواست به صادرکننده می‌رسد و او بررسی می‌کند حساب وجود دارد، وضعیتش سالم است و برای مبلغ موردنظر موجودی یا اعتبار کافی دارد. اگر چنین باشد، یک بلوکه ثبت می‌کند، یعنی پول را کنار می‌گذارد تا دو بار خرج نشود، و یک کد اتوریزیشن برمی‌گرداند. هنوز هیچ پولی جابه‌جا نشده است. پذیرنده اکنون وعده‌ای در دست دارد مبنی بر این‌که وجه معتبر است، آن هم در بازه‌ای که شبکه‌ی کارتی تعیین کرده است. اتوریزیشن را می‌توان پیش از دریافت هر وجهی لغو کرد (void) و اگر استفاده نشود خودش منقضی می‌شود. به همین دلیل موجودی کارت در لحظه‌ی پرداخت کم می‌شود اما ردیف صورت‌حساب بعداً قطعی می‌شود: آنچه کم شده بلوکه است، نه هزینه‌ی نهایی. اتوریزیشن می‌تواند کاملاً رد هم بشود، به دلیل موجودی ناکافی، قانون ضدتقلب یا کارت منقضی، و یک gateway خوب میان ردِ نرم که ارزش تلاش دوباره دارد و ردِ قطعی که نباید دوباره امتحان شود تمایز می‌گذارد. چون بلوکه تعهد صادرکننده به معتبر بودن پول است، پذیرنده می‌تواند فقط بر پایه‌ی کد اتوریزیشن کالا را تحویل دهد، پیش از آن‌که حتی یک ریال از حساب مشتری خارج شده باشد.
کپچر: تبدیل بلوکه به مطالبه
کپچر یعنی پذیرنده بگوید «همین حالا دریافت کن.» بلوکه را به درخواستی واقعی برای دریافت پول تبدیل می‌کند. کپچر می‌تواند کامل باشد، جزئی (مبلغ نهایی کمتر از مبلغ اتوریزشده، مثلاً کالای ارسال‌شده‌ای که از پیش‌اتوریزیشن ارزان‌تر درآمده)، یا با تأخیر (اتوریزیشن هنگام سفارش، کپچر هنگام ارسال). اتوریزیشن و کپچر در یک مرحله، حالت پیش‌فرض صندوق فروشگاه است؛ اتوریزیشن اول و کپچر بعد، روشِ هتل‌ها، پمپ‌بنزین‌ها و مارکت‌پلیس‌هاست، چون هنگام ارائه‌ی کارت مبلغ نهایی را نمی‌دانند. فاصله‌ی میان اتوریزیشن و کپچر درزی عمدی و مفید است؛ جایی که پذیرنده تصمیم می‌گیرد واقعاً چقدر دریافت کند.
کلیرینگ: دسته‌ای که مغایرت‌گیری می‌کند
پرداخت‌های کپچرشده یکی‌یکی و بلادرنگ تسویه نمی‌شوند. آن‌ها در فایل‌هایی جمع می‌شوند و به‌صورت دسته‌ای میان بانک پذیرنده (acquirer) و شبکه‌های کارتی مبادله می‌شوند؛ این همان کلیرینگ است. در این مرحله تراکنش‌ها تطبیق داده می‌شوند، مبالغ خالص می‌شوند و کارمزد شبکه و interchange اعمال می‌شود تا همه بر سر این‌که چه کسی چقدر به چه کسی بدهکار است توافق داشته باشند. کلیرینگ کار مغایرت‌گیری است، نه جابه‌جایی پول: مجموع‌های توافق‌شده‌ای تولید می‌کند که مرحله‌ی بعد روی آن‌ها عمل می‌کند. ساختار آن هم دسته‌ای است، و این دلیل واقعی آن است که پرداختی که پشت صندوق آنی به نظر می‌رسید، چند روز طول می‌کشد تا به‌صورت وجه نقد بنشیند. این محدودیت کامپیوترها نیست؛ شبکه‌ها طوری ساخته شده‌اند که هزاران مؤسسه را به‌طور کارآمد با هم خالص کنند و به‌جای ارسال یک انتقال برای هر قهوه، هر دوره یک بار مجموع‌های توافق‌شده را مبادله کنند.
اتوریزیشن یک وعده است، کپچر یک مطالبه، و تسویه تنها مرحله‌ای است که پول واقعاً جابه‌جا می‌شود. خلط این سه، راهی است که یک کسب‌وکار درآمدی را ثبت می‌کند که هنوز ندارد.
تسویه: جابه‌جایی واقعی پول
تسویه جایی است که وجه واقعاً میان بانک‌ها دست‌به‌دست می‌شود. شبکه با استفاده از مجموع‌های خالص‌شده در کلیرینگ، پول را از صادرکنندگان به بانک‌های پذیرنده منتقل می‌کند و هر مؤسسه موقعیت خالص خود را تسویه می‌کند، نه تک‌تک تراکنش‌ها را. تسویه تا یک تاریخ ارزش (value date) انجام می‌شود، یعنی روزی که وجه واقعاً در دسترس است؛ برای همین پرداخت‌ها ریتم T+1 یا T+2 دارند: پول واقعی است، اما طبق تقویم شبکه می‌رسد، نه ساعت مشتری. هر آنچه پیش از این مرحله بود، حسابداری بود؛ اینجا همان جاست که ثبت‌های دفتر کل به موجودی قابل خرج تبدیل می‌شوند. مؤسسه‌ای که در خالص بدهکار است پرداخت می‌کند و مؤسسه‌ای که طلبکار است دریافت می‌کند. چون محاسبه خالص است، مبالغی که واقعاً میان بانک‌ها جابه‌جا می‌شود کسری از ارزش ناخالص پرداخت‌های آن روز است، و همین شبکه‌ای با میلیون‌ها تراکنش را به تعداد قابل‌مدیریتی از جابه‌جایی‌های تسویه تبدیل می‌کند.
پرداخت به پذیرنده: از بانک پذیرنده تا حساب شما
تسویه پول را به بانک پذیرنده می‌رساند؛ پرداخت آن را به پذیرنده منتقل می‌کند. بانک پذیرنده طبق یک زمان‌بندی، روزانه، هفتگی یا بنا به درخواست، موجودی انباشته‌ی پذیرنده را به حساب بانکی او واریز می‌کند، پس از کسر کارمزد پردازش و هر ذخیره‌ای که برای بازپرداخت‌ها و اختلاف‌ها نگه داشته شده است. این همان عددی است که کسب‌وکار واقعاً می‌بیند، و نقطه‌ای که مغایرت‌گیری یا کار می‌کند یا اذیت می‌کند: پرداخت یک رقم خالص برای تراکنش‌های بسیار است و تطبیقش با سفارش‌ها یک کار مستقل است. gatewayای که هویت هر سفارش را تا انتها حمل می‌کند، این کار را ساده می‌کند؛ gatewayای که چنین نمی‌کند، هر پرداخت را به یک صفحه‌گسترده تبدیل می‌کند. جریان gateway ما، /products/gateway، طوری ساخته شده که هر پرداخت با سفارش‌های تشکیل‌دهنده‌اش مغایرت‌گیری شود.
کریپتو کجا یک پل اضافه می‌کند
پرداخت با کریپتو یا استیبل‌کوین جای این زنجیره را نمی‌گیرد؛ فقط یک مرحله‌ی تبدیل به ابتدای آن اضافه می‌کند. به‌جای بلوکه‌ی اتوریزیشن صادرکننده، پرداخت روی زنجیره (on-chain) تأیید می‌شود: مشتری یک انتقال را امضا می‌کند و قطعیت با افزوده‌شدن تأییدیه‌ها توسط شبکه حاصل می‌شود، نه با تأیید بلوکه توسط یک بانک. پس از تأیید، یک off-ramp کریپتو را به فیات تبدیل می‌کند و از آنجا پول وارد همان مسیر کلیرینگ، تسویه و پرداختی می‌شود که هر پرداخت دیگری طی می‌کند. تازگی فقط به همان مرحله‌ی اول محدود است و نیمه‌ی دوم عمداً ساده و معمولی می‌ماند. قاعده‌ی طراحی همین است: تسویه را عادی نگه دارید و سازوکار تازه را فقط جایی بگذارید که ناگزیر است، چون خزانه‌داری، مغایرت‌گیری و حسابرس پایین‌دست نباید بتوانند تشخیص دهند پرداخت از کجا شروع شده است. این‌که چند تأییدیه به‌معنای قطعیت باشد انتخابی سیاستی است، نه قانون زنجیره: آستانه‌ی بالاتر سرعت را با اطمینان بیشتر در برابر بازسازی زنجیره (reorganisation) معاوضه می‌کند و off-ramp تا عمقی که ریسک‌پذیری تعیین کرده صبر می‌کند و بعد فیات را وارد مسیر تسویه می‌کند.
چرا این درزها در عملیات اهمیت دارند
بازپرداخت، برگشت و اختلاف هر کدام به مرحله‌ای مشخص وصل می‌شوند و تشخیص درست مرحله، کل ماجراست. پیش از کپچر لغو کنید، یک اتوریزیشن را void کرده‌اید: هیچ پولی جابه‌جا نشده و چیزی برای بازگرداندن نیست. پس از تسویه لغو کنید، بازپرداخت صادر کرده‌اید: پرداختی تازه در جهت مخالف، با چرخه‌ی خودش. چارج‌بک از طریق کلیرینگ به عقب برمی‌گردد تا مبلغ تسویه‌شده را پس بگیرد. اگر همه را یک «لغو» یکدست بدانید، دفتر کل منحرف می‌شود؛ اگر آن‌ها را عملیاتی روی مراحل متمایز بدانید، هر مورد یک حرکت درست و قابل حسابرسی دارد. واژگان این حوزه، یعنی اتوریزیشن، کپچر، کلیرینگ، تسویه و تاریخ ارزش، در /glossary گردآوری شده است.
تنها ایده‌ای که ارزش به خاطر سپردن دارد: پرداخت زنجیره‌ای از وضعیت‌هاست، نه یک رویداد. اتوریزیشن رزرو می‌کند، کپچر مطالبه می‌کند، کلیرینگ توافق می‌کند، تسویه جابه‌جا می‌کند و پرداخت تحویل می‌دهد؛ و بخش کریپتو فقط یک مرحله‌ی تبدیل به ابتدای آن می‌چسباند. پول تا پیش از تسویه یک وعده است و پس از آن یک واقعیت، و کسب‌وکاری که پیش از واقعیت آن را ثبت کند، پولی را می‌شمارد که هنوز ندارد. بدانید پرداخت در کدام وضعیت است، تا باقی عملیات پرداخت دیگر مبهم نباشد.
سیستمی برای ساختن دارید؟
مسئله را بگویید. با یک معماری و یک برنامه برمی‌گردیم.