فاکتور پرداخت را مثل یک تعهد در نظر بگیرید
یک فاکتور پرداخت باید سفارش مشخص، دارایی، شبکه، آدرس دریافت، مبلغ و بازه اعتبار را توضیح دهد. این مقادیر باید وقتی مشتری صفحه را refresh می‌کند یا دوباره به تسویه‌حساب برمی‌گردد ثابت بمانند. قیمت را روی سرور محاسبه کنید و جزئیات سفارش توافق‌شده را حفظ کنید. اگر مبلغ شناسایی کوچک لازم است، آن را به‌صورت واضح در جمع کل بیاورید و توضیح دهید چرا باید کل مبلغ ارسال شود. از مشتری نخواهید پرداخت را از چند عدد نامرتبط بازسازی کند.
دارایی را راستی‌آزمایی کنید، نه فقط نماد آن را
یک ticker یکسان می‌تواند روی شبکه‌های مختلف یا روی قراردادهای توکن نامرتبط دیده شود. بنابراین سیستم راستی‌آزمایی به هویت شبکه تأییدشده و قرارداد توکن یا mint، به‌همراه گیرنده و مبلغ مورد انتظار نیاز دارد. هش تراکنش به‌تنهایی ثابت نمی‌کند دارایی درست رسیده است. برای پرداخت‌های توکنی، شواهد transfer در تراکنش موفق را بررسی کنید. محاسبات را در کوچک‌ترین واحدهای صحیح توکن نگه دارید تا گرد کردن اعشاری نتواند مبلغ تطبیق‌داده‌شده با فاکتور را بی‌سروصدا تغییر دهد.
تشخیص را از قطعیت نهایی جدا کنید
تراکنشی که دیده می‌شود، لزوماً آماده انجام تعهد نیست. سیاست‌های تأیید به شبکه و مدل finality آن بستگی دارند. Ethereum اطلاعات بلاک finalized را در اختیار می‌گذارد؛ TRON رسیدهای تراکنش solidified ارائه می‌کند؛ Solana به اپلیکیشن‌ها اجازه می‌دهد commitment از نوع finalized درخواست کنند. اتصال باید انتقال موفق واقعی را بر اساس سیاست انتخاب‌شده خود راستی‌آزمایی کند. تایمری که از اولین ظاهرشدن تراکنش شروع می‌شود، جایگزین این شواهد نیست. وضعیت انتظار را برای مشتری توضیح دهید، بدون اینکه زمان تکمیل تضمین‌شده نمایش دهید.
پردازش تکراری را بی‌ضرر کنید
workerها دوباره راه‌اندازی می‌شوند، ارائه‌دهندگان پاسخ‌ها را تکرار می‌کنند و کاربران refresh می‌زنند. به هر انتقال بلاکچینی یک هویت پایدار بدهید و settlement را برای تکرار ایمن کنید. ثبت transfer، علامت‌گذاری سفارش به‌عنوان پرداخت‌شده و اعطای دسترسی خریداری‌شده باید با هم موفق شوند یا سفارش را بدون تغییر باقی بگذارند. موقعیت اسکن را فقط پس از commit شدن این کارها جلو ببرید. وقتی یک تراکنش چند transfer دارد، index رویداد مرتبط را نگه دارید. این جزئیات جلوی آن را می‌گیرند که یک اعلان تکراری، همان خرید را دوباره تحویل دهد.
استثناها را پیش از انتشار طراحی کنید
انتقال‌های دیرهنگام، دارایی‌های پشتیبانی‌نشده، شبکه‌های اشتباه و مبالغ نادرست به وضعیت‌های صریح نیاز دارند. صفحه تسویه‌حساب منقضی‌شده نباید کسی را که قبلاً پرداخت کرده، به ارسال پرداخت دوم تشویق کند. شواهد را نگه دارید و برای مواردی که با اطمینان قابل تطبیق نیستند مسیر پشتیبانی فراهم کنید. تصمیم‌های بازیابی را از settlement خودکار جدا کنید. اگر چند اپلیکیشن از یک آدرس دریافت مشترک استفاده می‌کنند، تخصیص فاکتورهای آن‌ها باید هماهنگ شود؛ یکتایی فقط در داخل یک اپلیکیشن نمی‌تواند از تداخل با فاکتور اپلیکیشن دیگر جلوگیری کند.
سلامت عملیاتی را بخشی از تسویه‌حساب کنید
یک درگاه باید راهی برای ادامه‌دادن اسکن، تشخیص خرابی ارائه‌دهنده، اندازه‌گیری صف عقب‌مانده و شناسایی انتقال‌های حل‌نشده داشته باشد. ارائه‌دهندگانِ در دسترس نبودنی و خرابی‌های پایگاه‌داده را همان‌قدر عامدانه آزمایش کنید که پرداخت‌های موفق را آزمایش می‌کنید. فقط زمانی یک شبکه را ارائه کنید که پیکربندی و پایش آن آماده باشد. کلیدهای امضا را بیرون از سرویسی نگه دارید که فقط رسید را راستی‌آزمایی می‌کند و به آن‌ها نیاز ندارد. تجربه مشتری باید ساده باشد: یک فاکتور شفاف، وضعیت راستی‌آزمایی صادقانه، و قدم بعدی مفید وقتی بررسی انسانی لازم است.