Payment modes

Every payment needs a way to be told apart from every other payment. Which way that is comes from the chain, not from a setting you pick. Add a wallet and you get that chain's shape.

This page covers the three shapes, and the two settlement options that ride on top of them.

The three shapes

Per-payment forwarder (EVM, TRON, Solana)

Each invoice gets its own on-chain address. The customer pays there, and the funds reach your registered treasury.

• EVM and TRON. CREATE2 forwarder clones (EIP-1167 plus Solady CWIA). The treasury is welded into the bytecode at deploy.
• Solana. PDA forwarder. The treasury is read from your on-chain merchant state, never from caller input.

This is the only mode new EVM, TRON and Solana wallets accept. There is no shared-address alternative to choose between.

One-time onboarding per wallet: attest, then register your treasury. Your wallet signs one typed-data message and the platform broadcasts the transactions. Until you finish it, that chain does not appear as a payable option on your checkout, so complete the onboarding before you expect orders on it. After that, every invoice on the wallet gets a unique forwarder address, and the platform sweeps the funds to your treasury within about 5 minutes of confirmation. The platform pays the sweep network fee and bills it back at cost through Prepaid Credit. The forwarder's destination is fixed on-chain, so the platform can never redirect your funds.

Because every invoice has its own address, there is nothing to disambiguate. The customer pays the quoted amount and no amount adjustment is applied.

Two accounts may share one payout treasury. Unlike a receive address, a treasury and a control key can be used by more than one NoHoldPay account. Each account has its own on-chain merchant identity, which is folded into every forwarder address it derives, so the addresses customers actually pay can never collide between accounts even when both settle to the same treasury. If you run several accounts and want one payout destination, this is the supported way to do it.

One account plus a per-payment reference (XRP, Stellar, TON)

These three chains are account-based and have no forwarder equivalent, so every payment goes to the same address you registered. What tells invoices apart is a per-payment reference the customer includes with the transfer:

• XRP. A destination tag, shown on the checkout as an X-Address.
• Stellar. A reference shown as a muxed address (M...) or as a Memo ID.
• TON. A short text comment.

Funds land directly in your own account. There is nothing to sweep, and no onboarding step.

Since the reference does the matching, a customer who leaves it out or edits it can land in manual reconciliation instead of crediting the order straight away. As a backstop, native-coin invoices on these chains carry a small per-payment amount adjustment so two concurrent invoices never share an exact amount. The adjustment is deliberately aligned to the amount your customer sees, so the invoice total is exact and a wallet that rounds cannot break the match. Pay the amount shown, not a rounded version of it. USDT on TON has no amount fallback, so the comment is genuinely required there.

Two error codes belong to this shape. VOLUME_TOO_HIGH_FOR_STATIC_MODE means every amount slot for that coin is taken by concurrent open invoices. STATIC_AMOUNT_COLLISION is the narrower race where two invoices still land on the same exact amount. Both clear on their own as open invoices settle or expire, and you can raise the ceiling by adding another receiving address for the chain.

Both names carry the word STATIC for historical reasons. Error codes are a stable part of the API, so they are never renamed once shipped, even when the wording behind them moves on. Read them as belonging to the one-account-plus-a-reference shape described above. They cannot occur on any other chain.

The full matching rules are on each chain page: XRP, Stellar, and TON.

Bitcoin family and Monero (native per-payment derivation)

These chains give every payment a unique destination with no forwarder and no reference:

• Bitcoin, Litecoin, Bitcoin Cash, Dogecoin. A fresh address per payment, derived from your extended public key.
• Monero. A fresh subaddress per payment, derived from your private view key.

Funds land directly in your own wallet on every payment. The exact key format each chain expects is on its own page.

Direct settlement (funds land straight in your treasury)

Where your operator enables it, some payments settle directly into your registered treasury in one transaction, with no forwarder sweep step and no sweep fee. Funds arrive immediately. This is turned on per chain by your operator and is off until then.

These legs can settle directly:

• Gasless on EVM. When a customer pays gaslessly (see below), the signed transfer can go straight to your treasury instead of to the forwarder.
• Gasless on Solana. Solana gasless settles to your treasury. Where direct settlement is off for the chain, the gasless option is declined rather than pointed at a forwarder.
• Connected wallet on Solana and TRON. When a customer connects their wallet and signs the transfer themselves, it can go straight to your treasury. This path is customer-funded (they pay the network fee), not gasless.

The per-payment forwarder address still exists for the Scan / QR path, so a customer who pays by scanning still gets a unique address, and both are watched together. From your side, a directly-settled payment simply arrives faster and without a sweep fee. Nothing about the checkout changes for the customer, and you do not pick the route per payment. The system settles directly wherever it can.

Gasless (customer signs, platform pays gas)

Customers pay without holding the chain's gas token. They sign in their wallet, and the platform relay broadcasts the transfer. The signed message names your destination, so the relay can only pay the network fee, never redirect funds.

• EVM. x402 via EIP-3009 transferWithAuthorization. Stacks on the forwarder, and settles directly to your treasury where direct settlement is enabled.
• Solana. Sponsored fee-payer signing, where the relay signs the fee slot. SPL stablecoins only, and it requires direct settlement to be enabled for the chain. Native SOL is not eligible, since a customer sending SOL already holds SOL.
• TRON. GasFree (TIP-712 PermitTransfer via JustLend). Not yet available. TRON customers pay their own bandwidth or energy today.

Eligible tokens are limited to those whose contract implements the required signature standard. See Gasless USDC for the full eligibility list and setup.

Per-chain availability

Direct settlement is operator-gated and stays off until your operator turns it on for the chain.

Trust model

No shape gives the platform access to your funds.

• Per-payment forwarder. The contract or program reads your treasury from on-chain state set during onboarding. The platform's operator key can only push to that treasury, never anywhere else.
• Account plus reference, and native derivation. The customer pays your own address. The platform observes the chain and matches the transfer to an invoice.
• Direct settlement. The transfer is credited only from its own settlement transaction, and it can only land at the treasury you registered.
• Gasless. The customer's signature names your destination and the amount. The relay can only pay the network fee, not redirect funds.

See Trust Model for the full picture.