How to set up payment acceptance in TON: TON Connect, Jetton, automation

Why TON payment acceptance breaks in production

Accepting TON payments looks trivial: generate an address, show a QR code, wait for the transaction. In production, it turns out the network confirms payment asynchronously—the wallet state changes not when the button is clicked, but when the transfer gets into a block.

A classic case: the payment went through but confirmation never arrived—the indexer lagged, the webhook was lost during deployment, the handler crashed on an unexpected response.

The credit did not go through, the balance did not change, and a support request arrives before the transaction. A separate scenario is a stuck transfer: the fee is set below the current load, and the message hangs in the queue—neither confirmed nor rejected.

The address also "drifts": when generating a new address for each invoice, the address-to-order mapping is lost on service restart, wallet rotation, or in cache.

In TON Connect, the payer sends from their own wallet, and the incoming payment can be linked to the invoice only by the comment and message body.

Jetton adds a layer: what arrives is not a coin but a transfer with a payload, and without parsing that field, the payment cannot be matched to the order.

This leads to two expensive classes of failures: manual payment reconciliation and double crediting. Redelivery of a webhook or a handler retry credits the amount twice, and discrepancies are found in the statement only after the client complains.

We explain how this is closed: event-level idempotency, a cursor over incoming transfers, and alerts for confirmation delays.

What changes after implementation: speed, reconciliation, failures

The effect of implementation is measured not by the fact that a wallet is connected, but by how many payments the system closes on its own.

Before automation, every incoming payment was reconciled manually: the amount and transfer comment were matched to the order, and a stuck transfer was found only when the client wrote to support.

TON Connect with server-side transfer confirmation and a Jetton handler moves this work into code—engineers configure crediting by a network event, not by a statement.

Checklist we use to accept the result:

• Share of automatically credited payments — 95%+ of total. Only non-standard cases go to manual review: transfer without a comment, underpayment, payment to the wrong address.
• Payment confirmation time — crediting is configured for the required number of network confirmations; the order balance updates within tens of seconds instead of reconciliation once an hour.
• Reaction to a stuck transfer — a background watcher rechecks the status and raises an alert within minutes, not after the client contacts support.
• Share of manual operations — drops from a third of transactions to a few percent; accounting receives a ready journal with transaction-order-amount matching.
• Eliminated class of failures — crediting to someone else's invoice, duplication on resend, and a lost payment without a comment are closed by address-per-invoice and duplicate-credit protection by hash.
• Jetton on the same rails — token payments go through the same crediting pipeline, with correct accounting for decimals.

Integration options: TON Connect, Jetton, direct sending

The acceptance mode determines how much logic remains on the service side. Wallet connection delegates transaction signing to the client; a token transfer requires separate balance reconciliation; and direct sending to an address is the simplest scenario, but also the blindest.

Below is a comparison along three axes: what the payment service sees, what has to be confirmed manually, and what a refund looks like.

In practice, modes are combined: wallet connection handles the main flow, direct sending works as a backup channel, and token transfers are enabled only where settlement in the base coin is inconvenient.

One thing remains common—an in-house journal of incoming transactions with processing resistant to redelivery; otherwise one transfer turns into two credits.

How implementation proceeds: from audit to handover of procedures

We work in stages: first we record how payments arrive and where the fact of payment is confirmed, then we configure acceptance, then we test with real transfers and hand over the procedures.

We do not change the order—a skipped audit usually surfaces during testing, when redoing the scheme is more expensive.

Audit and scheme

1. Audit of payment flows. We analyze payment types—one-time, subscriptions, balance top-ups, refunds—and look at how the fact of payment is linked to the order in the accounting system.
2. Confirmation scheme. We agree on what counts as payment: a transfer record in a block, the number of confirmations, or an event from the wallet. This determines when the order status changes and the logic for cancellations with retries.
3. Matching payment to order. We choose the acceptance method—direct transfer to an address, wallet connection via TON Connect, or Jetton acceptance—and fix an identifier that will not be lost with parallel orders.

Setup and verification

• Setup of acceptance and automation. The service listens to the network, matches transfers to orders, and changes their status; separately, we configure rechecks for transactions that are not confirmed instantly.
• Test transfers. First a run in the test network, then real transfers of minimal amounts: success, underpayment, transfer without an identifier, resend. Each scenario is a row in the report with a status.

Acceptance and handover

• Acceptance. We compare order statuses with fund movements, check journals, notifications, and behavior when the node is unavailable.
• Handover of procedures. We provide monitoring instructions, the procedure for failures, reconciliation rules, and how to add new Jettons—the team supports payment acceptance on its own.

What remains with you: configuration, keys, documentation

We hand over not server access, but a reproducible set of artifacts: with it, your team accepts payments, changes parameters, and handles incidents without our involvement. Everything related to fund movement is documented in writing—verbal agreements do not work in payments.

• Acceptance configuration: environment files with the recipient address, list of accepted Jettons, amount limits, and number of network confirmations, with comments on what to change and when.
• Address scheme: which wallet is hot, where cold storage is, how withdrawals are configured, and where the fee goes.
• Key management: where private keys and mnemonics are stored, who has access to them, how rotation works, and what to do in case of compromise. Keys remain with you—we work on the test environment.
• Access policies: roles and least privileges, mandatory second confirmation for withdrawals, an operations log with the initiator and time.
• Reconciliation rules: how an incoming transaction is matched to an order, from what point payment is considered confirmed, and which discrepancies go to manual review.
• Documentation: payment flow diagram, description of TON Connect integration on the interface side, list of contracts with addresses, and procedures for working with the test network.
• Support instructions: ready scenarios for common requests—payment did not arrive, amount is less than expected, user closed the wallet before confirmation, stuck withdrawal.
• Change procedure: how a new configuration is deployed, where the previous version is stored, and how to roll back in one step.

Case study: manual reconciliation reduced, stuck payments eliminated

How it was

Before automation, TON payment acceptance looked like this: an operator opened a block explorer, searched for an incoming transfer, matched the transaction comment with the order number, and manually changed the status in the accounting system.

With a flow of several thousand orders per month, about 40% of credits went through manual handling, and outside working hours a payment waited for confirmation until morning.

Stuck payments—amount mismatch, typo in the comment, resend—reached 4-6% and were resolved in correspondence with support. Each such case required manual reconciliation against the journal and delayed closing the order.

What we changed and what we got

We connected TON Connect for wallet signing, and moved crediting to an indexer: the service listens to the network, reconciles incoming transfers with open invoices, and closes the invoice automatically.

For Jetton, we added reconciliation by the token's master contract address and its precision—without this, identical amounts in different tokens were merged.

Each invoice is assigned a unique identifier in the transfer comment, the record is idempotent by transaction hash, crediting occurs after the specified number of confirmations, and unprocessed cases go to a queue with retries and an alert to the on-call engineer.

The share of automatic confirmations grew to 97-99%: manual reconciliation remained only for disputed transfers—amount mismatch, payment without a comment, refund.

Average crediting time decreased from tens of minutes to 30-90 seconds and no longer depended on operators' schedules; the share of stuck payments fell below 0.3%.

How does a native transfer differ from a Jetton transfer?

In the TON network, a native transfer is the movement of the base coin: the fact of settlement coincides with the balance change.

To credit a payment, it is enough to wait for the transaction to be included in a block and for the required number of confirmations—there is no second contract call; the payment either went through entirely or did not go through.

Jetton is a token contract: the transfer goes as a message to the sender's token wallet, which debits the balance and notifies the recipient's wallet.

The confirmation boundary here is not the first transaction, but the notification itself: until the recipient's balance updates, the payment cannot be credited.

In practice, these are two different payment acceptance pipelines. For native, the service listens for incoming transactions to the address and confirms them by the number of blocks.

For Jetton, it either waits for a notification with a transfer comment or reconciles the token wallet balance and matches the transfer by identifier.

If the payment comes from an exchange, the comment is often lost—so in one pipeline we issue a unique address for each invoice, and in the other we require a mandatory comment.

Network fees also behave differently. In a native transfer, the sender pays gas; the recipient has nothing to reserve.

In Jetton, the sender pays twice—for the transfer and for notification delivery: if too little base coin is attached, the Jettons arrive but the notification does not, and the payment surfaces only during reconciliation.

Your token wallet needs a reserve of base coin; otherwise neither a refund nor a withdrawal will go through.

Refunds. For native, a refund is a regular transaction from the hot wallet: one fee, a predictable result. For Jetton, the refund goes from the token wallet, delivery fees are charged on the sender's side, and the refund amount may be less than the original.

Therefore, in both pipelines we build in idempotent reconciliation by transaction identifier and a queue of "stuck" payments, and we choose by scenario: native—where simplicity and mass payouts matter; Jetton—where the payment must be in a token tied to an external asset.

Common technical doubts and answers

Doubts at acceptance repeat time and again: how not to credit one transfer twice, what happens when the wallet address changes, which team members see operations, and how all this reconciles with current accounting.

These are the places where integration either keeps the flow running or starts requiring manual reconciliation—we address each one.

We changed the receiving address—will old payments be lost?

No, if addresses are stored in a directory rather than hardcoded into the logic. We maintain a registry of address-wallet-purpose mappings, history remains available, and a new address is connected without code changes. During the transition period, we poll both addresses in parallel.

How does this reconcile with current accounting?

The export is in a format your accounting system accepts: identifier, amount, purpose, status. Reconciliation is performed automatically, discrepancies go into a separate list with a reason rather than manual review. If accounting is in a closed environment, we provide a file or transfer data on a schedule.

Which employees will get access to operations?

Roles are configured with least privilege: accounting sees the export and statuses, support sees only a specific payment by order number, and withdrawal keys remain with one responsible person. Every action is written to the log, so both the author and time are visible.

Let's discuss the task: we will return with an estimate and work plan

To return with an accurate estimate rather than an "eyeballed" range, we need a small set of initial data about your acceptance scheme.

Production keys and access are not required at this stage—a description of how payments are set up now and what should be the result is enough.

• acceptance scheme: wallet connection via TON Connect in an app or on a website, payment by address, or transfer of Jettons;
• how the address for payment is generated: static, one per operation, with an identifier in the comment;
• where crediting confirmation comes from: your own node, a public block explorer, or provider notifications;
• what happens on underpayment, overpayment, transfer without a comment, and resend;
• volumes: number of payments per day and peak load, how many Jettons and addresses are served;
• accounting and reconciliation: export of operations, matching with the internal database, roles and employee access;
• limitations: where keys are stored, whether there are requirements for environment separation and operation auditing.

With this set, we return with a work estimate and implementation plan: sequence of stages, what we close first, where the checkpoints are, and what will be required from your side.

Describe the task in any convenient form—we will analyze the payment acceptance scheme and propose a solution.