یادداشت‌های میدانی

پذیرش کریپتو در نقطه‌ی فروش

پذیرش کریپتو در نقطه‌ی فروش یعنی مشتری پشت پیشخوان شما با یک دارایی دیجیتال پرداخت می‌کند، مثلاً استیبل‌کوینی مثل USDC یا کوینی مثل BTC، و شما، فروشنده، به یورو شارژ می‌شوید. دارایی‌ای که مشتری می‌فرستد و پولی که شما دریافت می‌کنید دو چیز متفاوت‌اند که یک قیمت‌گذاری در لحظه‌ی پرداخت آن‌ها را به هم وصل می‌کند. صندوق، دفاتر و حساب بانکی شما هیچ‌کدام نمی‌فهمند که کریپتو درکار بوده است. پایانه قیمت را به یورو نشان می‌دهد، مشتری یک کد را اسکن می‌کند و چند ثانیه بعد فروش به یورو بسته می‌شود، در همان ردیفی که اگر کارت بود ثبت می‌شد. کریپتو در نقطه‌ی فروش یک روش پرداخت است، نه تغییر در حسابداری، و همین‌طور نگه داشتنش کل مسئله‌ی مهندسی است.

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

مسئله‌ای که واقعاً باید حل شود

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

یک لمس: QR، قیمت قفل‌شده، یک ردیف یورو

جریان پشت پیشخوان را دنبال کنید. صندوقدار سبدی به مبلغ ۲۴٫۰۰ € را ثبت می‌کند. پایانه جمع کل را به یورو نشان می‌دهد و یک کد QR می‌سازد که درخواست را در خود دارد: مبلغ، نشانی مقصد یا فاکتور، و شناسه‌ی یک قیمت کوتاه‌مدت. مشتری آن را با کیف پول خودش اسکن می‌کند، دقیقاً می‌بیند چه چیزی را می‌فرستد و تأیید می‌کند. پایانه شبکه را برای آن انتقال زیر نظر می‌گیرد و با تأیید آن، رسید را به یورو چاپ می‌کند. از دید صندوقدار ریتم کار با کارت یکی است: جمع کل، ارائه، تأیید، رسید. هیچ‌کس پشت پیشخوان نشانی تایپ نمی‌کند یا موجودی‌ای را جز به یورو نمی‌خواند.

قرار دادن درخواست درون QR است که سپردنش به گوشی یک غریبه را ایمن می‌کند. مبلغ و مقصد با checksum در کد جابه‌جا می‌شوند، پس مشتری با اشتباه تایپ کردن نمی‌تواند به نشانی یا مبلغ اشتباه پرداخت کند؛ همان حرکتِ شناسایی-از-طریق-ساختار در سمت دریافت‌ها، این‌بار روی پیشخوان. کدی که اسکن می‌شود کدی است که درست است؛ فیلد متن آزادی وجود ندارد که بشود در آن اشتباه کرد.

تسویه به یورو، تا دفاتر هرگز کریپتو را نشناسند

بین دارایی‌ای که مشتری می‌فرستد و یورویی که فروشنده نگه می‌دارد، تبدیل قرار دارد و جای آن همه‌ی ماجراست. مشتری USDC یا BTC می‌فرستد؛ پلتفرم تبدیل می‌کند و حساب فروشنده را به EUR شارژ می‌کند. دفتر کل فروشنده فقط یک شارژ یورویی و یک ردیف کارمزد یورویی می‌بیند، همان شکلی که تسویه‌ی کارت دارد، چون دارایی در پلتفرم تبدیل می‌شود و در کیف پولی نمی‌ماند که فروشنده مجبور به مدیریتش شود. آخر روز دفاتر از اول تا آخر یورویی است. نه سبدی از کوین‌ها هست که ارزش‌گذاری شود، نه ارز دومی در حساب‌ها، و نه چیزی که صبح دوشنبه باید off-ramp شود.

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

نرخ قفل می‌شود، دنبالش نمی‌دوند

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

وقتی مشتری کند است یا پایانه آفلاین است

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

جایی که پایانه به gateway می‌رسد

پیشخوان، چهره‌ی حضوریِ همان پشته‌ی پذیرشی است که آنلاین کار می‌کند. یک لمس کریپتویی حضوری و یک checkout پرداخت-با-لینک در لایه‌ی زیرین یک رویداد واحدند، یعنی درخواست، پرداخت، تسویه‌ی یورویی و رسید، که فقط روی سطوح متفاوتی ارائه می‌شوند. پس فروشنده کریپتوی فروشگاه و سفارش‌های آنلاین را در یک جا، به یورو، با همان ردیف‌های کارمزد و همان خروجی‌ها تطبیق می‌دهد، به‌جای نگه داشتن دو دفتر که آخر ماه باید به هم منگنه شوند. پایانه در /products/pos است؛ سمت آنلاین همین ریل‌ها در /products/gateway؛ و واژگان، یعنی quote، settlement، acquirer و reconciliation، در /glossary تعریف شده‌اند.

مرز صادقانه

اگر هیچ‌کس پشت پیشخوان شما نمی‌خواهد با کریپتو پرداخت کند، پایانه‌ی کریپتویی راه‌حل مسئله‌ای است که ندارید؛ کارت بپذیرید و بروید سراغ کارتان. جای خودش را آنجایی پیدا می‌کند که سهم واقعی از مشتری‌های شما از قبل دارایی دیجیتال دارند و ترجیح می‌دهند خرجش کنند تا اینکه اول off-ramp کنند: بعضی مسیرهای گردشگری، بعضی جمع‌های بومی-آنلاین، بعضی مناطقی که استیبل‌کوین همان شکلی است که مردم پول قابل خرج نگه می‌دارند. در آن محیط‌ها رد کردن لمس یعنی رد کردن فروش. سازوکارهای بالا، یعنی QR، قیمت قفل‌شده، تسویه به یورو و قاعده‌ی تأیید-پیش-از-رسید، همان چیزی‌اند که اجازه می‌دهند آن فروش را بگیرید بی‌آنکه نوسان، ارز دوم یا یک پروژه‌ی حسابداری را هم بپذیرید. کریپتو دغدغه‌ی مشتری می‌ماند؛ یوروها مال شما.

سیستمی برای ساختن دارید؟

مسئله را بگویید. با یک معماری و یک برنامه برمی‌گردیم.