Understand the setup before you connect it.

Onboarding scope#

We begin with the merchant’s checkout, wallet controls, accounting needs, and requested methods. Availability and scope are confirmed before provisioning.

The written scope identifies hosting, endpoint capacity, monitoring, support, and merchant responsibilities. Shared and dedicated infrastructure are different arrangements.

Do not send seed phrases or private keys. Any wallet or node access must be reviewed against the specific configuration and minimum required permissions.

Payment method references#

This reference covers native Bitcoin, Lightning, and seven USDT adapter configurations. It is not a list of methods currently enabled for every merchant.

Software capability, enabled deployment, successful testing, and merchant availability are separate checks. Confirm all four before accepting payments.

Exact contract, mint, decimals, issuer or bridge provenance, and confirmation policy must match the selected asset. Do not substitute a similarly named token.

Lightning requires a separately assessed wallet or node, incoming liquidity, permissions, and recovery process. It is not an on-chain watch-only address mode.

Adapter model#

The reference EVM adapter uses JSON-RPC, configured contract allowlists, and transfer logs. EIP-681 payment links encode the selected chain and amount.

TRON has a chain-specific API adapter. Solana uses SPL token accounts and its own commitment and payment-link behavior.

Adapter support does not establish endpoint reliability or a completed merchant integration. Verify the selected deployment and its operating policy.

Asset matching#

Match the configured contract or mint and network, not the token symbol. Record decimal precision and amount conversion.

An issuer-native asset and a bridged representation can have different dependencies. The issuer registry must actually list the exact address before it is described as issuer-native.

Aliases and additional mints require explicit review and configuration. A legacy reference is not permission to enable an asset.

Receiving and wallet controls#

A Bitcoin on-chain watch-only setup can derive receiving addresses from an extended public key while signing keys remain with the merchant.

The USDT receive adapter uses configured public destinations, address pools, or supported public-key derivation. This statement does not describe every component in a payment setup.

The EVM reference derives receiving addresses below m/44'/60'/0'/0/n from an account-level public key. Confirm wallet compatibility and recovery before use.

Solana token account ownership and token-account preparation need separate checks. EVM derivation rules do not apply to SPL accounts.

Lightning wallets, hot wallets, and connected node permissions can enable spending. Document who controls them, the permissions granted, and the backup and recovery plan. Never send seed phrases or private keys through the enquiry form.

Payment links#

An EVM token payment link can encode the contract, chain ID, receiving address, and base-unit amount. Validate it with the intended wallet.

If a wallet or exchange does not support a token link, display the address, asset, network, and amount explicitly. A plain address QR does not encode all of those details.

Test the complete customer path, including fees, exchange withdrawal delays, underpayments, expiry, and any unsupported wallet behavior.

Operating boundaries#

USDT is centrally administered and its value may deviate from the US dollar. Bridged assets can add separate bridge, issuer, or administrator dependencies.

Endpoint capacity, outages, inconsistent history, reorganization handling, and monitoring need an operating policy. Confirm the quoted hosting arrangement.

Set a network-specific confirmation policy; Lightning settlement uses its own invoice and node evidence. Detection is not fulfilment.

Refunds are separate authorized outgoing payments. Define the actor, wallet, fees, and customer terms; the receive adapter does not itself fulfil the order or settle a dispute.

Contract and mint reference#

These identifiers describe the reference configurations. They are not receiving addresses and must never be used as a payment destination. Verify the exact asset, provenance, decimal precision, and deployed configuration before enabling a method.

Confirmation thresholds are part of the deployment policy. An explorer can show a transfer; it cannot establish that your invoice has been reconciled or your order should be fulfilled. Read the source and verification guide for the evidence to check.