گرفتن واریز

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

ساخت آدرس واریز

با دسترسی addresses و یک Idempotency-Key⁠:

import { romu } from "./romu.ts";

const res = await romu.post("/v1/addresses", {
  idempotencyKey: "address-user-1207",
  json: {
    wallet_id: "0192f19f-1d2c-7f3b-8a4e-6b7c8d9e0f12",
    group: "users",
    label: "vip-customers",
  },
});

• هر آدرس واریز روی همه‌ی شبکه‌های کیف پول کار می‌کند. این شبکه‌ها در networks پاسخ GET /v1/wallets می‌آیند.
• label مال شماست و در رویدادها برمی‌گردد.
• واریز را با address_id به مشتری وصل کنید. این همان id آدرسی است که برای آن مشتری ساختید. به label یا group تکیه نکنید، چون این‌ها نام نمایشی‌اند و عوض می‌شوند.
• برای ساخت چند آدرس با هم: ساخت چند آدرس واریز، تا 100 آدرس زیر یک کلید.
• سهمیه‌ی پلن آدرس‌ها را می‌شمارد، با آدرس‌های بایگانی‌شده. وقتی تمام شود، پاسخ 409 با quota_exceeded است (code برابر address_limit⁠) و چیزی ساخته نمی‌شود.
• اگر پاسخ 503 گرفتید، همان درخواست را با همان Idempotency-Key بفرستید. ممکن است آدرس ساخته شده و سهمیه مصرف شده باشد.

مسیر یک واریز

1. detected

   انتقال در یک بلاک دیده شد و رویداد deposit.detected رفت. هنوز قطعی نیست.

   reorgedبا reorg برگشت. برای این رویدادی فرستاده نمی‌شود.
2. confirmed

   به عمق لازم رسید و رویداد deposit.confirmed رفت.

شبکه	عمق تأیید
TRON	19 بلاک
BSC	15 بلاک

اعتبار کاربر را روی deposit.confirmed بگذارید.

مبلغ deposit.confirmed ممکن است از deposit.detected همان deposit_id بیشتر باشد، چون انتقال‌های کوچکِ منتظر را هم جمع می‌کند. همیشه مبلغ deposit.confirmed را اعتبار بگذارید. در این حالت tx_hash هش آخرین انتقال است و tx_hashes همه‌ی تراکنش‌ها را از قدیمی به جدید می‌دهد.

اگر همان انتقال پس از reorg در بلاک دیگری دیده شود، یک deposit.detected تازه با همان deposit_id می‌آید. پس کلید یکتای اعتبار کاربر را deposit_id بگیرید، نه event_id⁠.

چه چیزی رویداد ندارد

• واریز کمتر از حداقل هر دارایی ثبت نمی‌شود و اعلانی ندارد. پول روی آدرس می‌ماند. وقتی واریز بعدی موجودی جمع‌نشده‌ی آدرس را به حداقل برساند، کل موجودی یک‌جا ثبت می‌شود و deposit.confirmed با همان مبلغ می‌آید. انتقال کوچکی که پیش از این کار sweep شده باشد هم در این جمع حساب می‌شود. اگر انتقالی که جمع را کامل می‌کند خودش کمتر از حداقل باشد، deposit.detected نمی‌آید و فقط deposit.confirmed می‌آید.
• دارایی ناشناخته ثبت نمی‌شود و اعلانی ندارد.
• پولی که از کیف پول‌های خود سازمان می‌آید واریز نیست و هرگز اعتبار کاربر نمی‌شود.

این رویدادها را باید در تنظیم Webhook انتخاب کرده باشید. به دریافت Webhook نگاه کنید.

خواندن

• فهرست واریزها: با فیلتر کیف پول، آدرس، دارایی، وضعیت و زمان.
• موجودی هر آدرس.

پس از قطعی شبکه یا سرور شما، واریزهای باز را با این مسیر هم بخوانید. به Webhook به‌تنهایی تکیه نکنید.

sweep

sweep یعنی جمع کردن پول آدرس‌های واریز در آدرس sweep کیف پول. گروه بی قانون sweep نمی‌شود.

{
  "group_id": "01926e00-0000-7000-8000-000000000201",
  "base_version": 0,
  "enabled": true,
  "schedule": {"kind": "daily", "every_hours": 0, "hours": [2, 14], "timezone": "Asia/Tehran"},
  "min_amounts": [{"asset": "TRON_TRX", "amount": "10"}],
  "excluded_assets": []
}

schedule.kind	یعنی
interval	هر every_hours ساعت (1 تا 24)
daily	در ساعت‌های hours در منطقه‌ی زمانی timezone
manual	فقط با sweep همین الان

مقصد sweep را API تعیین نمی‌کند. مقصد فقط از کنسول و با تأیید عوض می‌شود. پایان هر sweep با رویداد sweep.completed می‌آید. sweep ناموفق رویداد ندارد و وضعیتش در تاریخچه‌ی sweep است.

ایستگاه کارمزد

برای جابه‌جایی توکن (مثل USDT) از آدرس واریز، آن آدرس باید سکه‌ی زنجیره داشته باشد. ایستگاه کارمزد کیف پولی است که این سکه را نگه می‌دارد و کمبود هر آدرس را می‌فرستد.

• هر سازمان یکی دارد و با کلید API ساخته یا عوض نمی‌شود. API فقط آن را می‌خواند: ایستگاه کارمزد.
• پیش‌فرض ساخت روی TRON: هر شارژ حداکثر 30 TRX و در 24 ساعت حداکثر 1,000 TRX.
• وقتی موجودی از آستانه پایین‌تر برود، رویداد fee_station.low یک بار فرستاده می‌شود. پس از برگشتن بالای آستانه دوباره فعال می‌شود.