Crypto Payment Addresses 2026: One Per Order or Not

Two customers pay you ninety seconds apart and both payments land on the same address. Your gateway credits both, your order table can match one, and the second customer is in your inbox with a block explorer link you cannot argue with. How a processor hands out crypto payment addresses decides whether that can happen to you, and it is the column missing from every gateway comparison, including the ones the gateways write. We read the address documentation of nine processors on 12 October 2026.

There are three models in use, not one: a fresh address per order, a static address tied to a customer, and a hosted checkout where the address never reaches your server. Each has a failure mode written down in the provider's own reference, and one provider contradicts itself between its FAQ and its API docs. We quoted the wording where the wording is the finding and left a cell empty where nothing is published. Four providers are excluded rather than guessed at; the method note says why.

The three ways a gateway hands out crypto payment addresses

The useful axis here is not custody, which we covered in the no-KYC gateway comparison. It is what the address is keyed to: your order, your customer, or a webhook URL you wrote once and forgot.

Read the third column twice. Two of the nine key the address to something that is not the order: Apirone and BlockBee both key it to the URL you nominated for webhooks — a design choice most integrations discover in production.

Why one address per order is the default

The reason is older than crypto payment processing and it is attribution, not privacy. The Bitcoin wiki has described the attack for years: "Bitcoin transactions are public on the block chain", so "if a customer Alice sends you bitcoins then a malicious agent Bob could see that same transaction and send you an email claiming that he paid".

You cannot disprove Bob. The chain says the address received money, not who sent it, and neither claimant has to prove anything. The wiki is blunt: "this is why each customer must be given a brand new invoice", and invoice addresses "are not intended to be used more than once, and doing so has numerous problems associated".

Privacy is the second reason. Bitcoin Optech frames it from the receiver's side — "a receiver wants to give out a different address to each spender for privacy" — because a reused address publishes your takings to everyone who has ever paid it. Seven of the nine issue a fresh address by default; what that costs is the gap-limit section below.

BlockBee ties the address to your callback URL

BlockBee's endpoint is GET https://api.blockbee.io/{ticker}/create/ and it returns an address_in, documented as "the unique payment address your customer will send cryptocurrency to". Unique is doing a lot of work there. The callback parameter's own note says what it is unique to:

Now picture the obvious integration. You add one webhook route, https://shop.example/hooks/blockbee, point every order at it because that is how webhooks work everywhere else, and call /create/ per checkout. Every call returns the same address. Two customers pay it, your handler fires twice on one address, and you are back in the Alice-and-Bob problem.

Nothing in the response signals this. You get a valid address, a 200, and a working flow right up to the first concurrent order. The fix is in the quote — make the callback URL carry the order, not the endpoint — and BlockBee's hardening note adds "an unguessable value unique to each request (for example ?nonce=a1b2c3...)", which also stops forged webhooks.

For proof the URL is the primary key, read the error list. A 400 reading "Non multi_token address already created for another token" fires when you "try creating an address with the same callback URL for a different ticker". The URL owns the address, and the address owns a coin. Our BlockBee review covers the rest.

Your payout wallet is frozen at address creation

The same note carries a second rule, and this one costs money rather than support time. BlockBee forwards: funds land on address_in and are pushed to your address_out. That destination is fixed when the address is created, not when the payment arrives:

As an operational rule that says: rotating your treasury wallet does not re-point money already in flight. Change exchanges, move to a hardware wallet, respond to a key you no longer trust — and every address issued before the change keeps paying the wallet you just abandoned. Payment links in old emails, addresses saved by repeat customers, a QR code printed on an invoice.

There is no bulk re-point. The documented remedy is a new callback URL, which mints a new address, which means re-issuing every live payment instruction you have. Worth a line in whatever runbook covers a wallet migration or a compromised key.

Static crypto payment addresses, and the clock nobody mentions

Static crypto payment addresses are the opposite trade: one address per customer, reused indefinitely, with attribution handled by the fact that only one person was ever given it. CoinGate sells this and describes the model it replaces in its own words — under one-time addresses "a customer buys something, a payment address is generated, the transaction happens, and the address is discarded", where a persistent address lets clients "save it once, deposit to it whenever they need to, and every deposit is automatically detected and attributed". Right for balance top-ups and subscription billing; wrong for one-off checkout, because an address with no amount attached cannot say which order was paid. Three of the five publish no expiry at all:

OxaPay is the one to watch, and not only for having the shortest clock: its own documents disagree about whether the clock exists. The merchant FAQ says "a static address is an address that remains valid indefinitely and has no restrictions on the amount or time of use", while the API reference for the same feature carries the revocation note in the table. Both were live on 12 October 2026, and if you gave a dormant customer a saved address on the strength of the FAQ, the API page is the one that will be right.

Apirone sits at the other end: a unique address per call that is nonetheless permanent, good "for one-time payments or for periodic payments", with no expiry and no transaction cap. See the Apirone review for fees and custody.

The gateways that never hand you an address

Four of the nine do not give your server an address at all, and that is a feature. CoinGate's order endpoint returns a payment_url, a token and a blockchain_transactions array, and no address: the shopper goes to the invoice, "where shopper can see the payment amount, select the desired payment currency and complete the payment". The address cannot exist before that choice, because the coin is not yet known.

BitPay attaches the invoice to a clock: the url field is "web address of invoice, expires at expirationTime", and an unpaid invoice goes to expired once the "15 minute payment window has elapsed". Plisio returns a txn_id and an invoice_url, its white-label response adding a wallet_hash documented as "invoice hash" rather than a blockchain address.

Plisio also shows what currency selection does to your records: switch coin mid-payment and a fresh invoice is created, with the siblings moved to cancelled duplicate after payment. One order, several invoices, one of them paid. Reconcile on order_number and you will see rows you did not expect — the same lesson as our comparison of payment statuses across nine gateways: the gateway's object model is not your order model.

Twenty unpaid invoices and your wallet goes blind

BTCPay Server is the purest one-address-per-order design. It "generates a new address for every invoice" and "by default only requires an extended public key", so addresses come from a wallet you control and there is no processor to key anything to. It also carries the sharpest failure mode here, and the failure belongs to the model rather than to BTCPay.

Wallets do not scan an infinite number of derived addresses. Bitcoin Optech defines the bound plainly: gap limits are "the limits wallets set for how many addresses they'll derive from an HD wallet", after which a run of unused addresses stops the scan. BTCPay's FAQ puts a number on what your watch-only wallet is likely doing — external wallets "limit the amount (typically 20) of addresses without balance that they track on the blockchain".

Twenty unpaid invoices is not an edge case for a shop that offers crypto to every visitor. Abandoned carts are the normal state of checkout and each burns an address, so one bad afternoon can push your next real payment past the window your wallet looks at. The symptom — a customer with a confirmed transaction and a merchant who cannot see the money — is the dispute our guide to screening and stopped payments starts from, arriving by a different route.

BTCPay's internal wallet tracks a far larger gap, so read the balance there. If you must split takings, the FAQ records that two stores can share one extended public key and "BTCPay Server will do address rotation correctly and never re-use between the stores" — provided "this has to be done on the same instance". Two servers on one xpub is how you get collisions. More in our BTCPay Server review.

Memo chains, where a correct payment still disappears

On XRP, Stellar, TON, Cosmos and several exchange rails the address is not the whole destination. A shared address plus a tag identifies the recipient, so the tag is the attribution key — and a payment with the right address and the wrong tag arrived somewhere real and belongs to nobody. What providers publish about that moment varies more than anything else we read.

Three different contracts. OxaPay tells you the money is gone, which is honest and worth printing beside your XRP option. trybit keeps a human in the loop, better for the customer and worse for your support rota. BlockBee ignores the funds unless multi_token is on, and that flag is "available only for TRC20 and all supported EVM-based blockchains" — set it anywhere else and the API "won't throw an error. Instead it just ignores it".

The conclusion is small and boring: if you offer a tag chain, never let a customer copy the address without the tag, and do not offer one on a static wallet. trybit does not support static wallets on TON for a reason.

Two payments, one address: what gets credited

Every model above eventually meets a customer who pays twice, pays late, or pays the wrong amount. trybit publishes the most complete answer of the nine, so its rules make a usable baseline for what to expect anywhere:

Two of those four move money without telling your database. An overpayment credited at the gateway and absent from your orders table looks like theft from both ends until someone opens a block explorer.

Static wallets dissolve this class of problem by giving up on amounts. At trybit "any amount received in the currency tied to the wallet is automatically credited as a successful balance top-up", with all payments to the address "processed the same way, without creating a separate invoice for each transaction"; Cryptomus fires its url_callback "after each top-up of the wallet". A static wallet can never be short-paid, because nothing was owed on it — and can never be matched to a price either.

Watch the idempotency rules too. Cryptomus requires the order_id to be "unique within the merchant invoices/static wallets/recurrence payments", and on a repeat "we return its details, a new invoice will not be created". Plisio demands an order_number "unique… for each new store's order", with a return_existing flag choosing between an error and the existing record. Choose deliberately: silently returning the old address is what gives two orders one address.

Which model to pick, and what to log either way

What you sell decides it. One-off checkout wants an address per order, because the amount is the attribution. Anything with a balance — top-ups, deposits, prepaid credit, metered billing — wants a static address per customer. Subscriptions sit between and usually do better on a static address with your own invoicing on top.

Whichever you take, log four fields against every order: the address you issued, the identifier the gateway keyed it to (callback URL, track_id, order_id, identify), the coin and network, and the tag if the chain uses one. Store the address even when the gateway hosts the checkout — it arrives in the webhook, and it is the only field that joins your records to a block explorer in a dispute.

Then two checks nobody writes until the first incident. On your own extended public key, read the balance from the server that derives the addresses, not a phone wallet with a gap limit. And if your processor forwards funds, record that the payout address is pinned to every address already issued.

FAQ

Does a crypto payment gateway give every order its own address?

Usually, but two of the nine we read on 12 October 2026 key it to something else. BTCPay Server "generates a new address for every invoice", while BlockBee and Apirone key it to the callback URL you supply, so an integration that reuses one webhook route reuses one address. CoinGate, BitPay, Plisio and trybit host the checkout and reveal an address only after the customer picks a coin.

What happens if two customers pay the same crypto payment address?

Both arrive and neither is attributable, the oldest problem in merchant crypto. Because transactions are public, the Bitcoin wiki notes, a stranger can see someone else's payment to your address "and send you an email claiming that he paid". Chain data cannot separate them, only transaction IDs each payer supplies — which is why the wiki concludes "each customer must be given a brand new invoice".

Can I reuse a crypto payment address for the same customer?

Yes, and several gateways sell it as a feature. CoinGate's persistent deposit addresses give each client "a single, reusable blockchain address"; trybit's static wallet is "a permanent address… tied to a user"; Cryptomus keys a static wallet to your order_id. The trade is that a reused address carries no amount, so it suits balances, not one-off checkout.

Why did my wallet stop showing payments after about twenty invoices?

You hit your wallet's gap limit, not a payment failure. BTCPay Server's FAQ records that external wallets "limit the amount (typically 20) of addresses without balance that they track on the blockchain"; past that run the wallet stops "fetching the transactions, assuming no new transactions occurred" and "your external wallet won't show them". The funds are safe and spendable; read the balance from the instance that derives the addresses.

Do static crypto payment addresses expire?

At one provider, documented twice and differently. OxaPay's API reference says "static addresses with no transactions for six months will be revoked", and warns that too many unused ones mean "the system will prevent you" generating more; its merchant FAQ says a static address "remains valid indefinitely". Apirone publishes the opposite: its addresses "never expire" and are "permanently monitored". Cryptomus, trybit and CoinGate publish no expiry at all.

What happens if my customer forgets the destination tag or memo?

It depends entirely on the provider. OxaPay states that for XRP, if the destination tag is missing or wrong, "your funds may be permanently lost". trybit treats it as recoverable: "the decision on crediting it is made on a case-by-case basis, after contacting support". If you offer a tag chain, present the tag as part of the destination rather than an optional field.

Which address model should I use for subscriptions or balance top-ups?

A static address per customer, with your own invoicing on top. The flow a static wallet is built for is the one CoinGate lists — advertiser funding, trading-desk deposits, marketplace balances, hosting top-ups, enterprise billing. At trybit, "any amount received in the currency tied to the wallet is automatically credited" without a new invoice: exactly what you want for a balance and exactly what you do not want for a priced order.

Affiliate disclosure: Payyd earns a commission if you sign up to some providers linked on this page. That changes none of the parameters, quoted documentation or limits reported here, all of which come from the providers' own reference pages and can be checked below.

Sources

Primary documentation, read 12 October 2026:

• BlockBee: Create New Payment Address — callback-URL-as-ID, the frozen address_out, multi_token
• OxaPay: Generate Static Address — six-month revocation, the generation limit, the XRP tag warning
• BTCPay Server: Wallet FAQ — one address per invoice, the gap limit of 20, two stores on one xpub
• Bitcoin Optech: gap limits — the definition and the privacy motive
• Bitcoin Wiki: Address — the Alice-and-Bob attribution attack
• trybit: Static Wallets — identify, any-amount crediting, no TON support
• trybit: Payment Issues — duplicates, overpayment, late payment, missing MEMO
• Cryptomus: Creating a Static wallet — order_id uniqueness and repeat behaviour
• Apirone: Forwarding — unique addresses that never expire
• CoinGate: persistent deposit addresses — the discarded one-time address, and five use cases
• CoinGate: Create Order — payment_url and no address in the response
• Plisio: Create an invoice — order_number, return_existing, cancelled duplicate
• BitPay: Invoices — expirationTime and the 15-minute payment window

Method notes. Nine gateways counted; four excluded rather than guessed at — NOWPayments serves its API reference as a JavaScript-rendered Postman collection with no readable text, Blockonomics' documentation host did not resolve, Confirmo's /api returns 401, PassimPay's returns an entrypoint stub. Where a provider's FAQ and API reference disagree, both are quoted and dated.