مشتری می‌گوید «تتر را فرستادم»، اما سفارش هنوز در انتظار پرداخت است. برای فهمیدن این وضعیت، باید مسیر انتقال روی بلاکچین را از مسیر ثبت سفارش جدا کنیم. این راهنما مسیر فعلی پردازش پرداخت در رمزپال را توضیح می‌دهد.
۱. یک درخواست به یک سفارش وصل می‌شود
فروشگاه مبلغ USDT و آدرس بازگشت را برای رمزپال می‌فرستد. در پاسخ، شناسه پرداخت و لینک شروع دریافت می‌کند. شناسه باید کنار سفارش ذخیره شود تا بعداً روشن باشد کدام پرداخت متعلق به کدام خرید است.
لینک پاسخ امضا دارد. فروشگاه باید مشتری را به همان لینک هدایت کند، نه اینکه با کنار هم گذاشتن دامنه و شناسه، آدرس جدیدی بسازد. جزئیات فیلدها و خطاها در مستندات API آمده است.
۲. مشتری روی شبکه درست انتقال می‌دهد
صفحه پرداخت، مبلغ و آدرس دریافت را نشان می‌دهد. درگاه فعلی رمزپال تتر BEP20 می‌پذیرد. ارسال USDT روی شبکه‌ای دیگر، حتی اگر نام دارایی یا ظاهر آدرس مشابه باشد، همان پرداخت مورد انتظار نیست.
تأیید برداشت در صرافی هم لزوماً به معنی ثبت انتقال روی بلاکچین نیست. اگر پرداخت به تعویق افتاد، ابتدا ببینید صرافی یا کیف پول برای انتقال، هش تراکنش صادر کرده است یا هنوز آن را در صف نگه داشته است.
۳. رمزپال چه چیزهایی را بررسی می‌کند؟
در منطق پایش فعلی، انتقال‌های توکن به آدرس پرداخت خوانده می‌شوند. مقصد باید با آدرس همان پرداخت برابر باشد، توکن باید با قرارداد تنظیم‌شده تتر سازگار باشد و انتقال باید تأییدهای کافی شبکه را گرفته باشد.
مقدار خام توکن با توجه به تعداد رقم اعشار به مبلغ قابل خواندن تبدیل می‌شود. سپس مجموع واریزهای تأییدشده با مبلغ درخواست مقایسه می‌شود. مقایسه با محاسبات اعشاری انجام می‌شود تا خطای معمول اعداد ممیز شناور مبنای تصمیم پرداخت نباشد.
اگر مجموع کافی نباشد، پرداخت کامل اعلام نمی‌شود. اگر مبلغ مورد انتظار تأمین شده باشد، وضعیت به PAID می‌رسد. ثبت تراکنش نیز با هش بررسی می‌شود تا خواندن دوباره همان انتقال به ثبت تکراری آن منجر نشود.
۴. PAID با VERIFIED چه فرقی دارد؟
PAID یعنی مبلغ مورد انتظار در مسیر بررسی پرداخت شناسایی شده است. VERIFIED نتیجه تأیید از طریق API است؛ فروشگاه شناسه و مبلغ را می‌فرستد و نتیجه پرداخت را برای همان سفارش بررسی می‌کند.
در Callback شناسه پرداخت و اطلاعات لازم به سایت برمی‌گردد. اما نشانی بازگشت را می‌توان خارج از مسیر اصلی هم باز کرد. پس success=true در URL، به‌تنهایی اجازه تحویل سفارش نیست.
فروشگاه باید مبلغ را از سفارش ذخیره‌شده در سرور بخواند، شناسه را تطبیق دهد، Verify را فراخوانی کند و تنها پس از پاسخ موفق و VERIFIED سفارش را پرداخت‌شده ثبت کند. اگر این مسیر دوباره اجرا شد، نباید محصول یا اعتبار را دوباره تحویل دهد.
۵. اگر Callback به فروشگاه نرسد
ممکن است انتقال انجام شده باشد ولی به دلیل خطای سرور فروشگاه یا قطع ارتباط، نتیجه ثبت نشود. این وضعیت به معنی برگشت خودکار تتر نیست. پذیرنده باید پرداخت را در پنل و با Verify پیگیری کند و وضعیت سفارش را پس از تطبیق اصلاح کند.
در افزونه رسمی ووکامرس، بررسی نتیجه پرداخت پیش از تکمیل سفارش انجام می‌شود. کد عمومی افزونه مسیر Callback و بررسی نهایی را نشان می‌دهد.
۶. دریافت وجه با تسویه یکی نیست
بعد از شناسایی پرداخت، مبلغ در موجودی پذیرنده ثبت می‌شود. انتقال آن به کیف پول BEP20 ثبت‌شده شما، مرحله تسویه است. رسید شبکه، وضعیت پرداخت و وضعیت تسویه را جداگانه بررسی کنید. صفحه امنیت و نگهداری دارایی این مسیر را توضیح می‌دهد.
برای پیگیری چه اطلاعاتی لازم است؟
شناسه سفارش، شناسه پرداخت، مبلغ، شبکه و هش تراکنش معمولاً نقطه شروع مناسبی برای بررسی‌اند. این اطلاعات را در تیکت حساب مربوط بفرستید. رمز عبور، کلید API یا عبارت بازیابی کیف پول برای بررسی یک تراکنش لازم نیست.