How to accept USDT payments on a website with Node.js

A production USDT checkout needs more than a wallet address. Create an order from Node.js, return checkout data to the browser, then fulfill only after a verified on-chain payment webhook.

Built for
Node.js server example
Built for
Direct wallet settlement
Built for
Signed webhook verification
Create a server-side USDT order in Node.js
import express from 'express'

const app = express()
app.use(express.json())

app.post('/api/checkout', async (req, res) => {
  const response = await fetch('https://api.boltutil.com/api/v1/order/create', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'X-Bolt-Key': process.env.BOLTUTIL_API_KEY
    },
    body: JSON.stringify({
      externalOrderId: req.body.orderId,
      amount: req.body.amount,
      currency: 'USDT',
      network: 'TRC20',
      notifyUrl: 'https://merchant.com/webhooks/boltutil',
      returnUrl: 'https://merchant.com/orders/complete'
    })
  })

  res.status(response.status).json(await response.json())
})

Node.js USDT payment integration steps

Use this pattern for SaaS subscriptions, digital delivery, invoices, account credits, or any website that needs an auditable USDT payment state.

  1. 01

    Create and persist a unique internal order ID before calling the payment API.

  2. 02

    Call the BoltUtil create-order endpoint from your Node.js backend and return the checkout URL to the browser.

  3. 03

    Show the exact USDT network and amount. A browser redirect is not payment proof.

  4. 04

    Verify the raw webhook body and signature, then fulfill idempotently by order ID and transaction hash.

  5. 05

    Store the confirmed transaction hash, network, amount, and fulfillment result for support and reconciliation.

Keep keys on the server

Create orders from Node.js so private API keys and local cart validation stay out of browser code.

Direct wallet settlement

Customers pay the configured merchant wallet while BoltUtil monitors the selected USDT network and reports confirmation.

Safe fulfillment

A signed server-to-server webhook lets your application activate access or delivery without trusting a customer redirect.

Integration notes

What matters before production

A redirect is not confirmation

Customers can return early or submit a transaction that fails. Use a verified webhook or server-side order-status query as the source of truth.

Network selection is part of checkout UX

USDT exists on multiple networks. Display TRC20, ERC20, BEP20, Polygon, or Solana clearly and match only the network chosen when creating the order.

Persist chain facts for support

Keep the external order ID, transaction hash, exact amount, destination address, and confirmation state for fast reconciliation.

Questions merchants ask before going live

These answers help developers, founders, and support teams understand the payment lifecycle before accepting real USDT payments.

Can I create a USDT order from browser JavaScript? +

Do not expose a private API key in browser code. Create orders from your Node.js server, validate the local cart or invoice there, and return only checkout data to the client.

When should my Node.js app grant access after payment? +

Grant access only after a signed webhook is verified or a trusted server-side status query confirms completion. A return URL is not payment evidence.

How do I avoid fulfilling the same order twice? +

Make fulfillment idempotent. Store the external order ID and transaction hash with a unique constraint or transactional state transition, then safely ignore duplicate deliveries.

Which USDT network should a Node.js checkout use? +

Choose the network your customers can reliably use and make it explicit. BoltUtil supports TRC20, ERC20, BEP20, Polygon, and Solana with the same order API.

Related resources

Launch a cleaner USDT payment flow

Create orders, monitor transfers, and notify your backend without asking customers to send screenshots.

Create free account