Verify the raw body
Re-serializing JSON changes the signed bytes. Validate timestamps and use constant-time signature comparison before parsing.
Payment integration
Payment confirmed. Notify your system.
Receive USDT / USDC payment results through signed webhooks. Order IDs, amounts, currency, network and transaction details reach your backend for reconciliation and fulfillment.
Steps to follow
Signed notifications, recorded processing
For activating plans, delivering products or crediting accounts after payment. This is a verification flow illustration, not a complete deployable handler.
01 Configure an HTTPS endpoint and retain the webhook secret on your server.
02 BoltUtil generates and delivers a signed event after payment confirmation.
03 Read timestamp and signature headers; verify the unmodified body before JSON parsing.
04 Validate the local order and payment, persist and deduplicate; respond with 2xx after durable acceptance.
BoltUtil checks payments and sends signed callbacks. Your server verifies signatures and order status, deduplicates events, then delivers goods, activates service or credits accounts.
Integration notes
What matters before production
Process each order once
Retries and manual resends can duplicate notifications. Use order IDs, transaction associations and transactional state or unique constraints.
Inspect delivery outcomes
Compare response codes, timeouts and error records. Repair the endpoint and resend within your permissions. A successful response is not proof of product delivery.
X-Bolt-Webhook-Timestamp: <timestamp>
X-Bolt-Webhook-Signature: <hex signature>
signed_content = timestamp + "." + raw_body
expected = HMAC_SHA256(signed_content, webhook_secret)
Verify timestamp + constant-time signature comparison
→ Parse JSON and validate local order / payment
→ Persist notification and process once
→ Return 2xx after durable acceptanceVerification flow illustration, not a complete handler. Use the webhook secret, not the API request-signing secret.
Read API docsPayment integration
Questions merchants ask before going live
Must a customer pay again when a webhook fails?
No. Check the original confirmed payment and repair notification delivery or handling. Callback failure does not justify charging the customer again.
Does BoltUtil hold the payment?
No. Customers transfer directly to your configured wallet. BoltUtil checks orders and payments without custody or access to private keys, seed phrases or withdrawal authority.
Do all networks support USDT and USDC?
TRON supports USDT only. Other networks support the configured USDT / USDC versions. Availability depends on enabled channels and merchant wallets; use the API and checkout response as the source of truth.
Can I fulfill when a customer returns?
returnUrl is navigation, not payment evidence. Use a verified callback or trusted server-side status query, check the order and fulfill once.
How are payment differences handled?
Free merchants can view their own review records. Qualifying manual-transfer differences can create review records; verify ownership when several orders are candidates. Active membership is required to accept or reject an association. Acceptance confirms payment and triggers the configured callback.
Can customers connect a wallet without entering the amount?
Yes. Wallet checkout prepares the recipient, token and complete payable amount on supported networks and devices. Customers review and confirm in their wallet. First use may require unlocking, connection approval or a network switch. QR codes and copied addresses remain available for manual transfer; both methods require on-chain confirmation.
Launch a cleaner USDT / USDC payment flow
Create orders, monitor transfers, and notify your backend without asking customers to send screenshots.