Is your gateway actually non-custodial?
Nearly every crypto payment gateway calls itself non-custodial, including several whose own terms describe holding funds. The label has stopped carrying information. The mechanics still do, and you can test them from the outside with three questions. This page is the test, written to be run against any gateway, including the one publishing it.
Question one: who controls the address your customer pays?
Almost every gateway shows the customer a fresh address per payment, so a unique address proves nothing. Ask where it came from. If it derives from material you supplied, an extended public key you exported, an account you own, a contract whose destination you can verify, control is yours. If the platform generated it from its own keys, control is theirs, whatever happens next. Onboarding tells you the answer quickly: a gateway that never asked for wallet material of yours cannot be deriving addresses from it.
Question two: where does the address forward?
Some flows receive at a platform address and immediately forward onward to your wallet. That is better than a balance, and it is still a window: for the span between receipt and forward, the platform's systems hold your revenue, its screening can pause it, and its failure would strand it. The test is to follow one real payment on a block explorer. Count the hops between your customer's wallet and yours, and ask who controlled each stop. Zero intermediate hops, or hops through a contract that can only pay you, pass. Hops through platform wallets do not, however briefly.
Question three: is there a withdrawal step?
The bluntest tell in the industry. If the dashboard has a balance page and a withdraw button, the platform is holding funds, whatever the homepage says. Corollaries count too: withdrawal fees, withdrawal minimums, settlement schedules, and terms that discuss inactivity charges or balance conversions all describe things that can only exist where a platform holds money. A genuinely non-custodial gateway has nothing to put behind a withdraw button, and its terms have nothing to say about holding, because there is no holding to govern.
The four models your answers map to
| Model | Receives at | Forwards | Withdrawal step | What it is |
|---|---|---|---|---|
| Direct derivation | Address derived from the merchant's own key material or account | Nowhere. The address is the destination | None | Non-custodial |
| Forwarding contract to merchant treasury | Per-payment contract address, destination fixed to the merchant's wallet at creation | Only to the merchant's wallet, enforced by the contract | None. Sweeps are automatic and cannot be redirected | Non-custodial, verify the contract |
| Forward-then-payout | Platform-controlled deposit address | Onward to the merchant's saved payout wallet, by the platform's systems | None visible, but the platform controls the funds in transit | Custodial during the window |
| Pooled hot wallet / merchant balance | Platform-controlled address | Into pooled platform wallets, credited to an internal balance | Merchant-triggered withdrawal or scheduled settlement | Custodial |
Hybrids are common: a gateway can run different models on different chains, or offer a custodial balance as an option next to a non-custodial default. Run the test per flow you will actually use, not per brand.
Words to search for in the terms of service
Marketing pages assert. Terms of service admit. Search a gateway's terms for these words and read the sentences around them: balance, withdrawal, settlement, held, custody, omnibus, pooled, convert, dormant, inactivity. Language about funds being held on your behalf, pooled with other users, or convertible by the platform describes custody in the operational sense regardless of the label attached. The absence test works too: a non-custodial gateway's terms will instead talk about wallet material you provide, addresses derived from it, and what happens if the service stops watching, because those are the only powers it has.
Common questions
- Why do custodial gateways call themselves non-custodial?
- Sometimes the default flow forwards funds onward quickly and the marketing rounds the window down to zero. Sometimes different documents were written at different times for different products. Either way the fix is the same: test the mechanics with the three questions rather than trusting any label, positive or negative.
- Is a fast forwarding window really a custody problem?
- It is a smaller one, and still one. During the window the platform's screening can hold the payment, its outage delays your money, and its insolvency reaches funds in transit. Whether that risk matters at your volumes is your call. The point of the test is that you should know the window exists before deciding it is fine.
- How do I verify a forwarding contract only pays me?
- Ask the gateway to show you. A well-built one documents how the per-payment contract fixes your wallet as the destination, lets you derive the addresses independently, and ships recovery tooling that works without its servers. If the answer is trust us rather than a verifiable mechanism, treat the claim accordingly.
- Does this test apply to NoHoldPay too?
- Yes, deliberately. Run it: payment addresses derive from wallet material you supply, forwarder contracts are compiled with your treasury as the only destination, no page shows a customer-funds balance and no withdraw button exists (the only balance in the product is the prepaid fee credit you top up yourself), and the terms govern watching rather than holding. The product pages document each mechanism so the answers are checkable rather than asserted.
Background reading: custodial vs non-custodial gateways for the full model comparison, and the NoHoldPay architecture page to run this test against us.