The listicle problem
Search for "best crypto payment gateway" and almost everything on the first page is the same shape: a numbered list, a comparison table, five-star ratings across a handful of criteria, a winner. Some of those lists are written by independent research sites. Some are written by one of the gateways in the list, on its own domain, scoring itself near the top of every column. Either way, the format hides more than it reveals — a star rating tells you someone's conclusion, not the reasoning behind it, and by the time you're comparing row three against row seven you're evaluating someone else's weighting of criteria you never got to see spelled out.
This isn't that list. There's no ranking here, no scorecard, and nothing gets rated against a named competitor — not because a comparison wouldn't be useful, but because a vendor grading its own product against rivals it also gets to name is exactly the kind of claim you should be skeptical of by default, this piece included. What follows instead is the set of questions worth asking about any crypto payment gateway, with enough explanation of why each one matters that you can apply it yourself — to this product, to whatever you're currently using, or to whatever else you're weighing it against.
Start with custody
Of every criterion here, custody is the one that actually determines most of the others. When a customer pays, does the money land in a wallet the gateway controls first, or in a wallet you control directly? That single answer shapes payout timing, counterparty risk, how the gateway is even able to charge its own fee, and what happens to your revenue if the gateway itself has a bad month — none of which are independent features to weigh separately once you know which model you're looking at.
This deserves more depth than a paragraph — see custodial vs non-custodial crypto payment gateways for both flows described honestly, including what each model costs you. The short version worth carrying into every section below: ask where the money goes first, and don't accept "your funds are safe" as an answer about where it physically lands.
Fee structure — read past the headline rate
Every gateway prints a percentage somewhere on its pricing page, and that number is almost always the best-case rate — what you pay on an invoice that gets created, paid, and closed out cleanly. It is not automatically what you pay on average, because not every invoice takes that path. The question worth asking isn't "what's the rate," it's "what's the rate on an invoice that doesn't complete" — one a customer opens and abandons, or one you cancel yourself. Most comparison pages don't mention this at all, which is itself a signal: if a gateway's documentation doesn't say what a canceled or expired invoice costs, that's worth asking directly before you integrate, not after your first month of abandoned checkouts.
There are, broadly, three ways a gateway can handle this. It can charge the full rate regardless of outcome. It can fold the cost into a wider spread somewhere else, so it never shows up as its own line item. Or it can charge upfront and refund down when an invoice is canceled or expires unpaid — the model the real cost of crypto payment gateway fees covers in full, including why a non-custodial gateway ends up preferring charge-then-refund over a lower rate upfront. Whichever model a gateway you're evaluating uses, the point isn't which one is objectively best — it's that you should be able to find the answer in writing, and that a gateway with nothing to hide here usually says so plainly rather than leaving it for you to discover.
Asset scope — narrow-but-verifiable vs broad-but-opaque
Gateways differ enormously in how many chains and assets they support, and more isn't automatically better. A gateway that supports a dozen chains and thirty assets is promising a dozen different matching pipelines, a dozen different sets of finality and reorg assumptions, and — if it's also custodial — a dozen different pools of funds it's holding on your behalf at any given moment. A narrower gateway is making a different trade: fewer assets your customers can pay with, in exchange for a system simple enough that its correctness claims are actually checkable rather than taken on faith.
Neither trade is universally right — it depends on whether your customers need asset variety more than you need a small, auditable surface. What matters when evaluating this criterion is whether a gateway is honest about which trade it made and why, rather than listing supported assets as an unqualified feature count. Why Zyrvix runs on TON only is one worked example of that reasoning stated out loud, including the specific stablecoin question this kind of scope decision inevitably raises and how a narrow-scope gateway should answer it — directly, with real tradeoffs named, not with a vague roadmap gesture.
Auditability — can you check the claim, or only trust it
Every gateway's marketing page makes claims: non-custodial, secure, reliable webhooks, bank-grade this, enterprise-grade that. Almost none of those words are independently checkable from the page they're written on. The useful version of this criterion isn't "does the gateway claim to be trustworthy" — every gateway does — it's "does the gateway give you a way to verify the claim yourself, without needing to trust its copy."
For custody specifically, that means being able to take a real invoice's payout address and a real transaction hash and check them against a public block explorer yourself, rather than reading an assertion. For webhooks, it means signed, documented delivery you can verify with your own code — not "we send webhooks," but a real signing scheme with real docs, ideally with working code samples rather than a paragraph describing the idea. Zyrvix's own approach to that second one is written up in webhook idempotency and signature verification — useful less as a pitch and more as an example of the level of detail this kind of claim should come with, whichever gateway you end up checking it against.
A gateway that's confident in its own claims tends to make them easy to check. One that isn't tends to stop at the assertion.
A checklist worth bringing to any evaluation
Pulling the four criteria above into something concrete — the specific questions worth writing down before you integrate with any gateway, this one included:
- Whose wallet does a payment land in first? Get a direct answer, not a description of "security."
- What does a canceled or expired invoice cost? If the fee page doesn't say, ask before you integrate, not after your first abandoned checkout.
- Which assets and chains, and why that set specifically? A long supported-assets list isn't automatically better than a short, deliberate one.
- Can you verify the load-bearing claims yourself? On-chain for custody, against real signed requests for webhooks — not just against the vendor's own copy.
- What does the gateway explicitly say it doesn't do? A vendor willing to name its own limitations plainly is a better signal than one whose page only lists capabilities.
Where Zyrvix fits, and where it doesn't
Running Zyrvix through its own checklist, plainly rather than as a pitch: custody is non-custodial and verifiable on-chain, per the article linked above. Fee structure is published, and cancellations and expirations are refunded down automatically rather than charged at the full rate — the specific behavior the fee-structure section above says most gateways don't disclose at all. Asset scope is deliberately narrow: TON only, for the auditability reasons covered above, with no other chains bridged in and no near-term plan to add them. Every non-custodial claim is checkable against a public block explorer, and every webhook is signed and documented with working code, not just described.
That combination fits a specific merchant: a crypto-native operator who already holds and secures a wallet, wants settlement to happen directly with no counterparty step in between, and doesn't need the gateway to touch fiat at any point. It does not fit a merchant who wants the opposite of several of those things, and it's worth naming those plainly rather than letting a reader find out mid-integration. Zyrvix does not convert to fiat or hold a balance you'd cash out through it — you receive TON and hold TON, by design, because there's no custodial step where a conversion could happen even if it wanted to. It does not do mass payouts to multiple recipients — it settles one invoice to one wallet, directly. And it does not ship e-commerce platform plugins today — a WooCommerce or Shopify store that wants a drop-in checkout button will need custom integration work rather than an install-and-go plugin, at least for now.
None of those are hidden gaps found the hard way after signing up — they're the direct, unavoidable consequences of the same scope decisions covered above, the same way every other gateway's limitations trace back to the trades it made. If the checklist above points you toward wanting fiat conversion, multi-recipient payouts, or a no-code plugin, this isn't the right product for that, and no amount of landing-page framing should talk you into thinking otherwise. If it points you toward direct, verifiable, wallet-to-wallet settlement on a single chain you can audit yourself, that's exactly what this is built to do — and now you have the questions to go check it, here or anywhere else you're comparing it against.