SaaS USDT payments: invoice renewal, prepaid balances and service access
SaaS USDT payments must connect a service invoice, a payment order and account access. Your application decides which plan to activate and how long to extend service after payment. UUGate supplies collection entries, status queries and callbacks; your subscription and entitlement rules remain in your SaaS.
Invoice payments or prepaid balances
Create a fixed-amount collection order for each monthly or annual service invoice; the customer actively pays the invoice amount. For usage-based consumption or prepaid accounts, bind a dedicated address to the member, credit confirmed top-ups, then apply your own consumption rules.
Invoice mode retains the invoice-to-orderNo relationship. Prepaid mode retains the member-to-bindKey, network and asset relationship. Design amount checks and fulfillment separately.
Generate a software invoice payment entry
Set the invoice amount, service plan and business validity period on your server, then use the collection order API. Save merchantOrderNo, orderNo, cashierUrl and expireAt so the customer can open online checkout from the invoice.
USDT currently supports TRC20 and BEP20. USDC supports BEP20 and SPL. The customer must use the invoice's specified asset and network. Your price is a business quote; a stablecoin parity policy is not a live FX quote or fiat conversion.
Activate or extend access after confirmation
Verify the collection callback, check merchant, order, network, asset, received amount and completed status, then update the account under the saved invoice rules. A unique payment record and database transaction prevent repeated callbacks from extending access twice.
Example: a monthly invoice priced at 20 USDT extends access by one service period after its payment order completes. This is a workflow example, not a UUGate plan price or customer case. Retain the invoice, payment record and entitlement change for business recovery or compensation.
Handle ongoing prepaid top-ups
Bind a dedicated address to the authenticated member. Credit each confirmed top-up using paidAmount and deduplicate each orderNo, not the member identifier.
Your SaaS owns consumption rules, insufficient-balance notices and service expiry. Reconcile chain wallet funds separately from the member's internal balance. See the wallet notification guide.
Renewal is not an automatic wallet debit
Paying a link is an active renewal; a permanent address does not authorize periodic debits from the customer's wallet. Current plugins do not provide recurring debits. The WHMCS adapter remains a test build and does not support automatic renewal debits.
Your application can implement scheduled invoicing, expiry reminders or charges against an already funded internal balance, with clearly explained rules. See the plugin guide for supported boundaries.
Recover missing callbacks and unusual payments
If a callback is absent, query the saved orderNo and restore business processing after verifying payment. Underpayment, overpayment, late receipt or an invoice cancelled during payment requires review rather than immediate activation. When creation times out without an order number, verify the result first; the same business reference does not guarantee idempotent retry.
- Unpaid orders, invalid signatures and mismatched amounts must not grant access.
- Duplicate callbacks create one payment record and one entitlement change.
- After a database interruption, inspect existing side effects before recovery.
- Validate invoices and ongoing top-ups separately; keep API Keys on the server.
Check capability and cost before integration
Choose a mode through the USDT API and dedicated address solution. Check plans, address quotas and network fees on pricing. Use the Node.js SDK or PHP / Laravel SDK for server-side signing and payment handling.