Accept USDT on TON: Payment Options for Your Website
Accepting USDT on TON on a website requires more than displaying a wallet address. A working checkout must connect a payment to an order, verify what arrived, handle exceptions and deliver the purchase once. It also needs a settlement process that leaves you with money you can use.
This guide compares a hosted gateway, Crypto Pay's service-balance model and a self-hosted processor. It then works through a monthly cost model, a break-even calculation and a practical order lifecycle. The aim is to help a merchant choose an integration that fits both its customers and the team that will operate it.
Documentation reviewed on 4 November 2026. Provider descriptions refer to the linked official sources. All cost scenarios below are illustrative planning assumptions, not provider quotations, measured network fees or a promise of savings.
Start with the route the money will take
Before comparing products, write a one-sentence requirement: “A customer pays USDT on TON from a wallet, and our store receives USDT on TON in a merchant-controlled wallet.” That is different from accepting a payment inside a custodial service and withdrawing a service balance later.
Also specify the average order size, expected monthly order count, settlement frequency and the person responsible for payment incidents. A store with twenty orders a month has a different operating problem from a platform crediting thousands of deposits daily.
TON's payment documentation distinguishes provider-operated processing from software you run or build yourself. A merchant backend usually still needs to connect payment events to its own business records. TON payment-processing overview.
Use these questions to narrow the decision:
- Can customers pay from the wallets they already use, or must they first fund a service account?
- Where is the balance held between payment and settlement, and who controls withdrawals?
- What happens when a customer pays the wrong amount or returns after an invoice expires?
- Who will investigate a paid order that has not been delivered?
The best first integration is one whose normal flow and exception handling your team can explain clearly.
Three ways to accept payments
| Model | Example to investigate | Main decision | What your team still owns |
| Provider-operated gateway | NOWPayments | Supported payment and settlement route | Order records, integration, customer support and reconciliation |
| Service-balance payment API | Crypto Pay by Crypto Bot | Whether customers and merchant accept the service's account model | Invoices, fulfillment, account access and withdrawal planning |
| Processor on your infrastructure | Bicycle | Whether infrastructure and wallet operations belong in your team | Hosting, monitoring, keys, recovery and the store integration |
The examples illustrate different operating models; the table is not a ranking of price or security. Evaluate the route you will actually enable, including any optional custody or conversion settings.
NOWPayments: evaluate the complete gateway route
NOWPayments documents USDt on TON support and describes enabling that currency and configuring a payout wallet. Its pricing page currently displays a 1% service fee. Neither statement establishes the complete cost or eligibility of your particular checkout. USDt on TON announcement, NOWPayments pricing.
Request a concrete demonstration: create an invoice for your typical basket, pay in USDT on TON, inspect the resulting payment status and check what reaches the configured settlement destination. Establish whether conversion occurs, which minimum amounts apply and which charges are paid by the customer or merchant. Confirm the terminal success status your integration should act on in the official API documentation.
A gateway is a useful starting point when the team wants to outsource blockchain monitoring. The store still needs reliable order handling. For example, if a notification arrives while your database is unavailable, the payment must remain discoverable after the database recovers. Include that case in your acceptance test instead of testing only a successful browser checkout.
Crypto Pay: account for the service balance
Crypto Pay is the payment system associated with Crypto Bot. Its policy describes a centralized system of transfers between internal balances. Paying a USDT invoice there is therefore a different route from sending an on-chain transfer directly to a merchant-controlled TON wallet. Funding and withdrawing that balance are separate steps to evaluate. Crypto Pay policy.
The API documents invoice creation, an order payload, expiry controls, invoice queries and payment webhooks. These are useful building blocks for associating a payment with an order. Check the current account tariff, supported withdrawal network, availability for your business and the full customer journey before selecting it. Crypto Pay API.
This model may suit an audience already comfortable with Crypto Bot. For an audience arriving with a self-custody wallet, an additional account or funding step can change the experience substantially. Measure completion of a real test checkout; an inexpensive integration that customers cannot complete does not solve the store's problem.
Bicycle: plan for operating the processor
TON's Bicycle setup guide describes a self-hosted processor with per-user deposit addresses, USDT deposits and withdrawals, wallet sweeps and payment notifications. The application still maintains the relationship between those deposits and its own orders. Read the current setup guide together with the upstream project's documentation. Bicycle setup on TON Docs.
The operational question is who will keep that system correct after launch. Assign ownership for software updates, database backups, wallet recovery, fee funding, monitoring and failed withdrawals. The documented hot wallet is managed by the processor; manual transfers outside that workflow can make its recorded state inconsistent. Bicycle operating instructions.
A useful readiness exercise is to describe recovery from a lost server without moving any real funds: where are the backups, which secrets are required, and how will you verify balances before resuming withdrawals? If those answers are missing, budget the work before choosing self-hosting for an apparent fee saving.
Calculate the cost beyond the advertised percentage
Separate customer costs from merchant costs. A wallet may charge the customer for sending a payment; your processor may separately charge for collection, conversion or settlement. Count each expense once and record who pays it.
For a merchant budget, use:
Monthly payment cost = payment volume × processing rate + per-order costs × paid orders + fixed operating costs + setup cost allocated to the month.
Include the fees you actually incur when moving funds to the destination where you need them. If you settle in batches, divide the total batch cost by the relevant orders for reporting; do not mistake that average for the blockchain's fee on every individual payment. Keep refunds, currency conversion and exceptional support work visible as additional lines when they apply.
Worked example: a store with a $25 average order
The following three models use invented assumptions so the arithmetic is transparent. They are not price quotes for NOWPayments, Crypto Pay or Bicycle. For this exercise only, 1 USDT is valued at $1. Customer-paid sending fees, taxes, product costs, conversion costs and unusual incidents are excluded. Real settlement proceeds can differ.
| Assumption | Gateway model A | Service-balance model B | Self-hosted model C |
| Average paid order | $25 | $25 | $25 |
| Processing percentage | 1% | 3% | 0% external processing fee |
| Other merchant cost allocated per order | $0.05 | $0.05 | $0.10 |
| Monthly operations allocation | $30 | $30 | $300 |
| Setup allocation | $0 in this simplified comparison | $0 in this simplified comparison | $1,200 spread over 12 months: $100/month |
| Total fixed monthly allocation | $30 | $30 | $400 |
The $300 operating assumption for model C could represent $60 for infrastructure and monitoring plus eight hours of maintenance at $30 per hour. It is a planning example, not a staffing benchmark. Models A and B also require initial integration work; enter your own setup estimate instead of the zero used here. The per-order amounts are bookkeeping assumptions, not estimates of TON gas.
At 1,000 paid orders, monthly payment volume is 1,000 × $25 = $25,000. The calculation for model A is $25,000 × 1% + 1,000 × $0.05 + $30 = $330. For model C it is 1,000 × $0.10 + $300 + $100 = $500.
| Paid orders per month | Payment volume | Model A cost | Model B cost | Model C cost |
| 100 | $2,500 | $60 | $110 | $410 |
| 1,000 | $25,000 | $330 | $830 | $500 |
| 3,000 | $75,000 | $930 | $2,430 | $700 |
At 100 orders, model A consumes 2.4% of payment volume even though its processing rate is 1%. At 1,000 orders, its effective share falls to 1.32%. Fixed operating costs are being spread across more orders. Model C moves in the other direction relative to A: its larger fixed allocation matters less as volume grows.
These figures represent payment-related costs, not the store's profit. Subtracting them from turnover does not account for goods, delivery, payroll, taxes or customer acquisition. A real comparison should also include the cost of failed checkouts and the availability of the people who maintain the integration.
When does self-hosting break even in this example?
Let N be monthly paid orders. At the assumed $25 average basket, model A costs $0.30 × N + $30: $0.25 in percentage fees and $0.05 in other allocated costs per order. Model C costs $0.10 × N + $400.
Setting those equal gives N = ($400 − $30) ÷ ($0.30 − $0.10) = 1,850 orders, or $46,250 in monthly payment volume. Both models then cost $585. Below that volume, A is cheaper under these assumptions; above it, C is cheaper.
This is a comparison of monthly costs including the chosen setup allocation, not a promise that the initial cash investment is recovered in twelve months. Changing the basket size, support hours or provider rate changes the answer. If the per-order saving is zero or negative, growing volume alone will not produce a break-even point.
Why small payments need a separate calculation
Suppose your merchant cost is 1% plus an allocated $0.10 per payment, before fixed monthly expenses:
| Order amount | Merchant payment cost | Effective share of the order |
| $5 | $0.15 | 3.0% |
| $25 | $0.35 | 1.4% |
| $50 | $0.60 | 1.2% |
A fixed cost can matter more than the percentage on a low-priced product. Evaluate smaller baskets separately instead of applying the average order calculation to everything you sell. Before bundling purchases or changing settlement frequency, check whether the change fits customer needs and your cash requirements.
If you need to receive a target amount after a percentage fee and a fixed charge, the arithmetic is gross amount = (target net amount + fixed charge) ÷ (1 − percentage rate). For a $25 target, 1% and $0.10, the result is approximately $25.353535. That calculation helps with budgeting; any customer-facing price must follow your pricing policy, applicable rules and the processor's supported precision.
Build an order lifecycle that survives real customers
Keep the payment record separate from the delivery record. A customer can have paid successfully while an email service or warehouse integration is temporarily unavailable. If both facts are represented by one ambiguous “completed” flag, support cannot tell what needs fixing.
A practical sequence is created → awaiting payment → paid → fulfillment pending → fulfilled. Add explicit paths for expiry, manual review and refunds. These are example store states; map them carefully to your provider's actual statuses.
Create the invoice on the server
Store the order ID, expected amount, asset, network, recipient or provider invoice ID, creation time and expiry. Bind those values to the order before presenting the payment screen. Reopening checkout should retrieve the same unpaid invoice or clearly replace it according to a defined rule.
The browser must not be able to choose a lower payable amount by changing a request field. Recalculate the order total from trusted product and pricing data. Keep API tokens on the backend, and retain enough payment metadata to answer a support ticket without asking for a wallet's recovery phrase.
For direct processing, validate the token's master contract and the intended recipient instead of trusting a ticker or logo. Tether lists its supported protocols and contract information; TON's jetton guide explains token-wallet verification. Tether supported protocols, Jetton payment processing.
USDT on TON uses six decimal places: 25 USDT = 25,000,000 base units. Use integer base units or an appropriate decimal library, with a defined rounding policy. Do not assume every token has the same precision. USDT configuration and units.
Confirm the incoming payment independently
A wallet connection proves neither that the customer paid nor that the intended transfer completed. TON Connect provides the wallet interaction; its documented transaction result includes a signed message. Your backend must establish the final payment outcome. TON Connect guide.
For direct blockchain processing, check the receiving side and the relevant token transfer. A successful sender transaction alone does not establish that the recipient accepted the operation. TON's explorer guide explains how one operation can span multiple transactions. Investigating TON transactions.
With a provider, authenticate notifications using its documented method and confirm the invoice, asset, amount and success state against server records. Crypto Pay, for example, documents a webhook signature and invoice queries. Reconcile unresolved invoices periodically so a missed webhook does not leave a paid customer waiting indefinitely. Crypto Pay notification verification.
Deliver once, even when notifications repeat
Treat repeated notifications as an ordinary integration case. Store a stable payment identifier with a uniqueness constraint, then update the order and enqueue fulfillment as one database operation where possible. The fulfillment worker should also accept an order-level idempotency key so a retry does not send another item or extend a subscription twice.
For example, an invoice for order
WEB-1042 may be reported three times after a temporary timeout. The first valid report changes the order to paid. Later reports should return the existing result. If delivery fails, retry delivery for WEB-1042; do not ask the customer to pay again.Avoid deduplicating only by amount or by a timestamp. Different customers can legitimately pay the same amount at almost the same moment. Conversely, one order can involve multiple incoming payments when you explicitly support a top-up after a short payment.
Decide how exceptions will be handled
Write these policies before launch. A customer should see a useful status while an exception is reviewed, and staff should know which actions they can take.
| Situation | Example | Suggested handling |
| Underpayment | 24.50 USDT arrives for a 25 USDT invoice | Hold fulfillment; request the missing amount only if the integration supports matching a top-up |
| Overpayment | 30 USDT arrives for a 25 USDT invoice | Record the full receipt and handle the excess under a documented policy |
| Late payment | Funds arrive after expiry | Review the payment against stock and current order terms; do not silently discard it |
| Duplicate payment | The customer pays twice | Record both receipts but fulfill the order once; review the extra receipt separately |
| Wrong asset or network | A different token or chain is used | Route to support; establish whether recovery is technically possible before promising it |
| Missed notification | Payment exists but the order is still waiting | Recover through reconciliation and the usual idempotent fulfillment path |
Choose a clear rule for each amount rather than silently treating a small shortfall as “close enough.” If you allow a tolerance, specify its size, currency and scope in the business logic. Keep the difference in your records so the payment ledger remains explainable.
For an expired invoice, preserve the original quote and timestamp. Whether you can still supply the item is a business decision separate from whether money arrived. Payment processing should expose both facts to the person resolving the case.
Plan settlement, refunds and support
Record the relationship between each order, its payment and any later settlement or refund. A daily reconciliation can compare your store's paid orders with provider records or observed deposits, then account for fees, withdrawals and remaining balances. Investigate unexplained differences instead of adjusting the ledger just to make the totals match.
Settlement frequency is a trade-off. More frequent settlement can reduce the balance left with a service, while batching can reduce some operating costs. Use your own cash requirements, withdrawal minimums and account terms to set the policy. Do not assume that a wallet balance is immediately available as money in a bank account.
For a refund, verify the original order, refundable amount, asset and destination through an authenticated support flow. The sending address may belong to an exchange or payment service, so returning funds automatically to that address is not always the right procedure. Do not accept a replacement destination solely because an unsolicited message supplies one.
Store the refund's own identifier and prevent the same refund request from being executed twice. Tell the customer which amount is being returned and how any applicable fee is handled. Keep the original payment record intact and add the refund as a related event rather than overwriting the purchase history.
A useful support request asks for the order reference and a transaction or invoice reference. It never asks for a private key or recovery phrase. Your internal view should show payment status, delivery status and the last action taken so a second staff member can continue the investigation.
A website checkout does not replace Telegram Stars
Telegram requires Telegram Stars for digital goods and services sold inside bots and Mini Apps. A website's USDT payment integration is not a general substitute for that in-app requirement. Define where the sale takes place and follow the rules for that surface. Telegram digital-goods payment documentation.
If your business has both a standalone website and a Mini App, design the payment routes deliberately. The customer-facing product and support policies should make the applicable payment method clear. Do not present a wallet connection as permission to use cryptocurrency for every Telegram purchase.
A practical launch plan
Begin with one asset, one network and one supported settlement route. Test the provider's sandbox or the appropriate test environment first. Test assets are not real USDT, and a successful simulation does not prove that a mainnet account, withdrawal route or minimum amount is configured correctly.
Then run an authorized, low-value end-to-end production trial: create an order, pay it, verify the receipt, deliver it and exercise the supported refund procedure. Record expected and actual amounts. Include at least one mobile wallet journey and one desktop journey relevant to your audience.
Before opening checkout broadly, test duplicate notifications, a temporary backend outage, underpayment, expiry and a delivery failure after payment. Confirm that each case reaches a clear status and that the responsible person can resolve it from the available records.
During the first week, track created invoices, paid invoices, fulfilled orders, unresolved payments, settlement totals and support requests. A large gap between invoice creation and payment deserves a customer-experience investigation; it is not automatically evidence of a blockchain problem. A gap between payment and fulfillment points to a different part of the system.
Common questions
Can I start with a wallet address and manual confirmation?
For a small pilot, you can assess whether a manual workflow fits your operation. You still need reliable order matching and independent receipt verification. Several customers paying the same amount to one address can make matching ambiguous. Move to a defined invoice or deposit-address system before the volume exceeds what staff can reconcile accurately.
Do I need to build a custom smart contract?
Do not make that your starting assumption. Investigate whether a gateway or an existing processor meets the requirement. Choose a custom design only when you can identify the behavior the available approach cannot provide and can support its development and operation.
Is self-hosting automatically cheaper?
No. It removes some external processing charges while introducing operating costs and responsibilities. In the example above, self-hosting becomes cheaper than model A at 1,850 monthly orders under the chosen assumptions. Your own staffing, integration cost, order size and fee schedule determine your result.
What should customers see after sending a payment?
Show the order reference and the current server-confirmed state. Distinguish waiting for payment from waiting for delivery. Give customers a way to return to the same order and contact support, especially if they close the wallet or switch devices before the checkout page updates.
For wallet-side background, read How to Choose a TON Wallet as a Beginner. Browse the TON App catalogue for related products, then validate the exact payment route against the provider's current documentation and a complete test order.
