How to Accept Crypto Payments on a Website: USDT and TON (2026)

Why accept crypto payments in 2026

Crypto as a payment method solves three practical problems that classic card acquiring handles poorly. First — global customers. If your audience is spread across the world, there will always be countries where the buyer's card gets declined, familiar payment services are unavailable, and a bank transfer takes a week and costs half the order. A crypto wallet works the same everywhere: all the buyer needs is a smartphone and an internet connection.

Second — payment finality. Card payments come with chargebacks: a buyer can dispute a transaction weeks later, which for digital goods and services is a constant source of losses and disputes. A blockchain transaction is final: once the funds arrive and collect network confirmations, they are yours. For businesses with digital delivery — SaaS, content, services, in-game value — this changes the risk economics.

Third — speed and independence. Settlement takes minutes rather than banking days and does not depend on intermediaries' schedules. You also gain access to a crypto-native audience — people for whom a wallet is more familiar than a card. A whole economy has grown around them, from exchanges to ad networks that settle in cryptocurrency.

Which assets to accept: why USDT and TON

The first instinct is "accept Bitcoin", but for everyday payments it is inconvenient: confirmations are slow, fees are unpredictable, and the price is volatile enough for the order total to drift while the customer pays. For settlement a business needs different properties: stable value, fast confirmations and low network fees.

USDT (Tether) is a stablecoin pegged to the US dollar. For a store this means the invoice amount and the amount in the wallet are essentially the same dollar value: no per-minute rate recalculations and no explaining to accounting why identical orders brought different sums. USDT is issued on several networks, and the choice of network determines the speed and cost of a payment.

TON is a fast blockchain with low fees and short confirmation times, with a large user ecosystem around it — including wallets built into messengers. USDT on TON combines both advantages: stable dollar value plus cheap, fast transfers. There is a practical bonus for the integrator, too: native TON and USDT-on-TON live on the same network, so the gateway only has to watch one blockchain — less infrastructure, fewer points of failure.

A sensible starting configuration for most websites is to accept USDT-on-TON as the primary asset and native TON as a secondary one, adding anything more exotic only when customers actually ask for it.

Custodial processors vs a self-hosted gateway

There are two ways to accept crypto: plug in a third-party custodial processor or run your own gateway. The difference between them is fundamental — it is about who controls the money.

A custodial processor receives funds to its own addresses and shows you a balance in a dashboard. It is quick to start with, but the model has a price: a fee on every transaction and often another one on withdrawal; mandatory KYC/KYB and limits; and above all, custodial risk. While the funds sit with the service, it is not you who controls them: the account can be frozen under internal rules, the service can change its terms, pause withdrawals or shut down entirely. You get convenience by giving up control.

A self-hosted non-custodial gateway works differently: the software runs on your infrastructure, and buyers' funds go directly to addresses whose keys only you hold. The gateway server watches the blockchain and records incoming transfers, but physically cannot spend the money — there are no private keys on it. No intermediary means no intermediary fees, limits or freeze risk.

This is exactly the model we used to build Payora, a self-hosted crypto payment gateway: a single API, a ready-made checkout page and signed webhooks, with keys and funds staying with the owner. We will use it as the reference example for the mechanics below.

How acceptance works: from invoice to webhook

Reliable crypto payment acceptance is a pipeline with clear steps. Let's walk through it end to end.

1. Invoice creation. When a buyer chooses to pay with crypto, your server makes one HTTP request to the gateway API: amount, currency, order ID and a notification URL. The response contains an invoice with payment details and a link to the checkout page.
2. Unique address. A dedicated deposit address is allocated to the invoice — more on this below; it is the key element of the whole scheme.
3. Checkout. The buyer lands on a hosted payment page: amount, address, QR code and a countdown until the invoice expires. They pay from any wallet.
4. Detection and matching. The gateway spots the incoming transfer to the invoice address and checks the amount against the expected one, within an allowed tolerance.
5. Confirmations. After the required number of network confirmations the invoice moves to "paid" — the risk of a rollback is gone.
6. Signed webhook. The gateway sends your server a notification with the new status and a cryptographic signature. Your handler verifies the signature and performs the business action: ships the goods, credits the balance, unlocks access.

The core integration rule: the only source of truth about a payment is the signed webhook, not the buyer being redirected to a "thank you" page. A redirect can be forged or simply never happen: the user closes the tab, loses connectivity, or opens the URL by hand. A webhook arrives server-to-server and reflects the actual state of the invoice.

A unique address for every invoice

The most common failure of home-grown acceptance is payment matching. If every buyer pays to one shared address, the only way to tell who paid for what is to ask for a comment (memo) attached to the transfer. In practice, memos get lost: the wallet does not support the field, the user leaves it empty or makes a typo. Every such case is a manual support investigation and an order stuck "unpaid" while the money has actually arrived.

The solution is a unique address per invoice. For each new invoice the gateway deterministically derives a dedicated deposit address. Any transfer arriving at that address belongs to that invoice by definition: matching turns from a probabilistic task into an identity. No memos, no guessing by amounts, no manual reconciliation.

How the addresses are generated matters. In a correct scheme deterministic derivation is used: addresses are computed from public data, so the server needs no private keys for this — it stays read-only with respect to the funds. Derivation has a second virtue, recoverability: the address-to-invoice link can be recomputed at any moment from the original parameters instead of depending on a fragile lookup table.

This is how Payora implements acceptance for TON and USDT-on-TON: every invoice gets its own address, and the server only watches for incoming transfers.

Security: keys, signatures and idempotency

A payment pipeline handles money, so security here is not a set of add-ons but the shape of the architecture itself. Three principles should be treated as mandatory.

Private keys stay off the server

A server that physically has no keys cannot leak them — this is stronger than any perimeter defence. Even if the machine is fully compromised, there is nothing to steal: the gateway can only compute addresses and read the blockchain. If a processor asks you to upload a private key "for automation", treat it as a red flag.

Notifications are signed

A webhook is effectively the command "release the goods", and it must be unforgeable. Every notification is signed with a secret known only to the gateway and the store; the store's handler verifies the signature before trusting the payload. Without this, anyone who learns your handler's URL can send a fake "paid".

Processing is idempotent

Networks are unreliable: a notification may arrive twice, a handler may crash midway, a response may get lost. Crediting logic must be built so that re-processing the same event never results in a double credit. A simple recipe: record processed event IDs and credit strictly once.

Infrastructure measures complete the picture: separating the API, the checkout page and the admin panel across subdomains, the principle of least privilege, TLS everywhere and restricted access to the administrative part.

Underpayments, overpayments and the exchange rate

In crypto, the amount "exactly as invoiced" does not always arrive, and the maturity of a payment solution shows precisely in how it handles the edge cases.

Exchange rate. If the product is priced in fiat and paid in crypto, the amount must be fixed at invoice creation — and the invoice lifetime must be limited. Hence the countdown on the checkout page: it protects both the store (the rate cannot drift far from the fixed one) and the buyer (it is clear how much time is left). When the window closes, the invoice becomes "expired" and the order can safely be cancelled or recreated.

Allowed tolerance. Wallets round amounts, networks take fees, users mistype a digit. Demand the amount to the last decimal and you will get a stream of false "underpayments". The correct logic is a tolerance: a small deviation from the expected amount counts as a valid payment and the invoice closes.

Clear underpayments and overpayments. If noticeably less arrives, the invoice gets a dedicated "underpaid" status and the decision stays with the store: wait for the rest, refund, or close the order partially. If more arrives, the fact is recorded and reported to the store instead of being silently swallowed. The key principle: no real transfer may fall out of sight, and every one must map to a clear machine-readable state.

The checkout page: where conversion is decided

The payment moment is the most fragile point of the funnel: the buyer is parting with money in a system where a mistake cannot be undone. Any ambiguity on this screen converts into an abandoned invoice.

A good checkout reduces everything to the minimum that answers the buyer's three questions: how much to pay (the exact amount in the chosen asset), where to pay (an address with a copy button and a QR code for mobile wallets) and how much time is left (a countdown to invoice expiry). After the funds are sent, the screen must show a live status — "waiting for transfer", "transaction seen, waiting for confirmations", "paid" — so the person is not left guessing whether the money got through.

A practical takeaway for the integrator: do not build this screen yourself. A ready-made hosted checkout from the gateway solves two problems at once. First, it saves you the markup and the status-polling logic. Second — and more importantly — it improves security: the payment details are generated and displayed by the gateway itself, so there is no store-side code that could show the buyer a wrong address. The store simply redirects the person to the link returned by the API.

The legal side: what to check

Technically you can accept cryptocurrency from anywhere in the world; legally, everything depends on the jurisdiction — and that is not a boilerplate disclaimer. Regulation differs radically: in some countries crypto payments are explicitly allowed and described in law, in others holding is legal but settlement is restricted, elsewhere there are licensing, exchange or reporting requirements. The picture also keeps changing: rules from 2024 may be outdated by 2026.

The practical minimum to cover before launch: establish the status of crypto payments in the jurisdiction where the business is registered and in your customers' main countries; understand how received crypto is reflected in accounting and at which moment a tax obligation arises; keep complete records per invoice — amount, exchange rate at the time of payment, transaction hash. Deterministic invoice statuses and the gateway's dashboard history make this much easier: you have a machine-readable trail for every payment.

This article covers the engineering side and is not legal advice. Before launching crypto payment acceptance, consult a lawyer and an accountant familiar with your jurisdiction.

How to go live in one evening

How long does going live take? Built from scratch, it is months of work: a blockchain layer and network monitoring, address derivation, a status model, webhook signing and redelivery, a checkout page, a merchant dashboard. That is exactly why home-grown acceptance so often stays a "temporary" hack with no amount matching and no reliable notifications.

With a ready-made gateway the integration shrinks to two things on the website side:

• One request — create an invoice via the API at order checkout and redirect the buyer to the hosted checkout link from the response;
• One handler — receive the webhook, verify the signature, perform the action idempotently and respond with 200.

For a developer comfortable with HTTP that is literally one evening of work. We have walked this path in production: Payora, the gateway designed and built by our studio, already serves real integrations — for example, balance top-ups on a freelance marketplace, where crediting is bound strictly to the signed webhook.

If you want to accept USDT and TON on your website — from an online store to a SaaS — we will help you pick a configuration, deploy the gateway on your infrastructure and complete the integration end to end. Check out our services or get in touch — we will discuss the task and propose an architecture.

FAQ