The one question that defines the category
Every crypto payment gateway answers one question, whether or not its marketing page says so out loud: when a customer pays, whose wallet does the money land in first? There are only two possible answers — a wallet the processor controls, or a wallet the merchant controls directly — and almost everything a merchant actually cares about follows from which one it is. Payout timing, counterparty risk, what happens if the processor has a bad month, even how the gateway can charge its own fee — none of these are separate features you evaluate independently. They're downstream consequences of one design decision made long before you signed up.
That decision has a name: custodial versus non-custodial. It's worth understanding both sides plainly, including the parts a vendor on either side of it would rather not emphasize.
The custodial flow, honestly described
In a custodial setup, a customer's payment doesn't go to the merchant. It goes to a wallet the processor controls — commonly a pooled address shared across many merchants, not one dedicated to any single business. From there, the processor may convert the payment to a stablecoin or fiat balance, and at some later point — daily, weekly, or on whatever schedule the processor sets — it pays the merchant out from that pool, usually minus its fee.
Stated neutrally, that arrangement has real consequences worth naming rather than glossing over:
- The processor is now a counterparty holding your revenue. Between the moment a customer pays and the moment you're paid out, that money is legally and technically the processor's to hold — not yours.
- Payouts can be delayed, gated, or reviewed. A minimum payout threshold, a KYC review triggered by unusual volume, or simple processing lag can all sit between "customer paid" and "you actually have the money."
- The pooled wallet is a concentrated target. It holds many merchants' funds at once, which makes it a meaningfully more attractive thing to attack than any single merchant's own wallet would be.
- Their regulatory status becomes your problem. If the processor's license, banking relationship, or standing with a regulator changes, your access to funds sitting in their custody can change with it — a risk you're exposed to indirectly, without having agreed to it directly.
None of this makes the model illegitimate — plenty of merchants make this trade deliberately, for reasons covered below. But it is a trade, and it's one most comparison pages describe in terms of convenience without naming what's given up for it.
The non-custodial flow
The other model removes the pooled wallet and the payout step entirely. In a non-custodial setup, the customer's payment goes directly to a wallet the merchant already owns and controls — on-chain, in one transaction, with no intermediate stop. That's the model Zyrvix runs on. Every invoice you create carries a pay-to address that resolves to your own registered TON wallet, and when a customer pays, the transfer lands there directly, the same way any TON transfer between two wallets does.
With the pooled wallet gone, the gateway's job shrinks considerably. It doesn't hold funds, convert them, or decide when to release them, because it's never in possession of them in the first place. What's left is bookkeeping and observation: issuing an invoice with a unique memo, watching the chain for a transfer that matches it, and telling your system the moment that happens. There is no payout step in this model — not a fast one, not a slow one — because the money was never anywhere else to pay out from. For the full mechanics of how that matching actually works, see how to accept TON payments.
How to verify this instead of trusting it
"Non-custodial" is a claim any gateway can put on a landing page. The useful version of this article isn't asking you to believe Zyrvix's version of it — it's showing you how to check, in about thirty seconds, without needing to trust anyone's copy.
Every invoice Zyrvix creates returns a pay_to_address field — the exact wallet the payment is headed to. That address is the same one you registered as your own. Take it, along with the transaction hash from any payment, and paste both into any public TON block explorer. You'll see the transfer moving straight from the customer's wallet to yours, with nothing in between — no pooled contract, no intermediate hop, no second transaction a day later moving the funds again. The chain is public specifically so this doesn't have to be taken on faith.
The honest tradeoffs
A fair comparison doesn't stop at "non-custodial is safer" — it has to account for what the model gives up, because there is a real cost, and it shows up before you ever accept a payment.
The first is how the fee gets paid. A custodial processor can simply subtract its cut from the funds passing through its own wallet before paying you the rest — it holds the money, so deducting from it is trivial. A non-custodial gateway structurally can't do that, because it never holds your money at any point; there's nothing in its possession to deduct from. Zyrvix's answer is a prepaid TON balance: you fund an account balance ahead of time, and the invoice fee is charged against it as invoices are created. That is real onboarding friction a custodial competitor doesn't have to ask a merchant for — worth stating plainly rather than burying in the fine print. Current rates and how the balance works are on the pricing page, along with what that fee really works out to once you factor in canceled and expired invoices.
The second is currency. Because the payment moves directly from customer wallet to merchant wallet with nothing in the middle, there's no step where the gateway could insert a conversion even if it wanted to. You receive TON, and you hold TON. If your business needs fiat on the other end, that conversion is something you handle yourself — it isn't quietly done for you the way it can be in a custodial flow that already has your funds in hand.
Both of these are the direct, structural flip side of the trust-model advantage above — not separate complaints, but the same design choice viewed from its other consequence. Removing the counterparty removes what the counterparty was doing for you, too.
Which model fits which merchant
Neither model is universally correct — they fit different merchants. Custodial makes sense for a business that wants to think about crypto as little as possible: no wallet to secure, funds arrive as fiat or a stablecoin balance, and the tradeoff of a counterparty holding funds temporarily is an acceptable price for that convenience.
Non-custodial fits a different merchant — one that's already comfortable holding and securing a wallet, wants funds to settle directly with no counterparty in between, and doesn't need an automatic fiat conversion layered on top. Zyrvix is built for that second merchant only, and it's worth saying plainly rather than implying: if what you actually want is a processor that also converts to fiat and cuts you a check, this isn't the right product for that, and no amount of feature-page framing should talk you into thinking otherwise. If direct, verifiable, wallet-to-wallet settlement is what you're after, that's exactly what this is built to do.