USDT payment webhooks that your backend can trust

BoltUtil sends signed webhook payloads with order ID, status, network, amount, confirmations, and transaction hash after payment confirmation.

Start accepting USDTRead API docs
Built for
HMAC-SHA256 signatures
Built for
Retry logs
Built for
Order-level payloads
Verify a BoltUtil webhook in Node.js
import crypto from 'node:crypto'
import express from 'express'

const app = express()

app.post('/webhooks/boltutil', express.raw({ type: 'application/json' }), async (req, res) => {
  const timestamp = req.get('X-Bolt-Webhook-Timestamp') || ''
  const received = req.get('X-Bolt-Webhook-Signature') || ''
  const rawBody = req.body.toString('utf8')
  const expected = crypto
    .createHmac('sha256', process.env.BOLTUTIL_WEBHOOK_SECRET)
    .update(`${timestamp}.${rawBody}`)
    .digest('hex')

  const recent = Number.isFinite(Number(timestamp)) && Math.abs(Date.now() - Number(timestamp)) < 300_000
  const wellFormed = /^[0-9a-f]{64}$/i.test(received)
  const valid = recent && wellFormed && crypto.timingSafeEqual(
    Buffer.from(received, 'hex'),
    Buffer.from(expected, 'hex')
  )
  if (!valid) return res.sendStatus(401)

  const event = JSON.parse(rawBody)
  await fulfillOnce(event.externalOrderId, event.txHash)
  return res.sendStatus(204)
})

Webhook delivery flow

Best for teams that need automatic account activation, balance crediting, order fulfillment, or membership upgrades after payment.

  1. 01

    Configure an HTTPS webhook URL and keep its webhook secret only on your server.

  2. 02

    Create a payment order with a notify URL or use the merchant-level default webhook.

  3. 03

    BoltUtil detects, matches, and confirms the USDT transfer before creating the delivery event.

  4. 04

    Read the timestamp and signature headers, then compute HMAC-SHA256 over timestamp + "." + the exact raw body.

  5. 05

    Record the verified event and fulfill idempotently by external order ID and transaction hash.

  6. 06

    Return 2xx after durable processing; inspect delivery logs or resend safely if delivery fails.

Verifiable delivery

Every callback carries a timestamp and HMAC-SHA256 signature that your backend can verify against the unmodified request body.

Order and chain evidence

The payload includes the external order ID, status, network, amount, transaction hash, confirmations, and destination address.

Retry-safe operations

Delivery logs and resend support work with idempotent handlers so a temporary endpoint failure does not require duplicate fulfillment.

Integration notes

What matters before production

Webhook handlers must be idempotent

A payment notification can be retried, resent manually, or received after your server recovers, so fulfillment should only happen once per external order ID.

Signature verification should use the raw body

Parse JSON only after computing HMAC over the exact request body, otherwise formatting changes can break verification.

A 2xx response means your server accepted the event

Return a successful HTTP status only after your system has safely recorded the event or queued reliable internal processing.

Questions merchants ask before going live

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

How is a BoltUtil USDT webhook signed? +

BoltUtil computes HMAC-SHA256 over the timestamp, a period, and the exact raw request body. The timestamp and hexadecimal signature are sent in the X-Bolt-Webhook-Timestamp and X-Bolt-Webhook-Signature headers.

Why must verification use the raw request body? +

Parsing and re-serializing JSON can change whitespace or field formatting. Verify the bytes received from BoltUtil first, then parse the trusted payload.

Can the same payment webhook be delivered more than once? +

Yes. Retries and manual resends are normal recovery mechanisms. Make fulfillment idempotent using the external order ID and transaction hash.

What should my webhook endpoint return? +

Return a 2xx response only after the verified event is durably recorded or the local order update succeeds. A non-2xx response is treated as a failed delivery.

Launch a cleaner USDT payment flow

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

Create free account