Why the headline percentage misleads
Every crypto payment gateway prints a headline rate somewhere on its pricing page, and almost none of them tell you what it actually applies to. The number you see is the happy-path rate — what you pay on an invoice that gets created, paid in full, and closed out cleanly. That is not the same thing as what you pay on average, because not every invoice takes that path. Conversion spreads, withdrawal or payout fees, minimum-payout thresholds, and — the one almost nobody prints anywhere — what happens to the fee on an invoice that never completes at all. All of that sits outside the headline number, quietly widening the gap between the rate you were quoted and the rate you actually pay.
None of that makes the headline rate a lie, exactly. It's just a best-case number being used to answer an average-case question, and the difference only shows up once you look at what happens to the invoices that don't complete.
Abandonment is the norm, not the edge case
A crypto checkout that expires unpaid isn't a rounding error — it's a routine outcome. Customers open a checkout and get distracted, switch wallets partway through, decide against the purchase, or simply run out of time before the payment window closes. None of that is unusual, and none of it is free for the gateway to handle: the invoice still had to be created, still had to be watched on-chain for the length of its expiry window, and still had to be resolved one way or another when that window closed.
Most providers respond to that cost the simplest way possible: they charge the full rate regardless of outcome, or they widen their spread enough to absorb it invisibly. Either way, the merchant pays for abandonment — it's just folded into the same number as everything else, instead of being shown as its own line.
Zyrvix's model, plainly
Zyrvix runs a dual-rate model with exactly two numbers, both live and both shown below rather than assumed: the current invoice fee rate, charged in full the moment an invoice is created (see live pricing). If that invoice is later canceled by the merchant, or expires unpaid, the difference between the full rate you were charged and a lower net rate (see live pricing) is refunded back to your balance automatically. Not a support ticket, not a manual adjustment a merchant has to request — a ledger rule that fires the instant the invoice's status changes, every time, with no exceptions carved out.
To make that concrete: imagine a run of 100 invoices where 20 of them are abandoned — canceled or left to expire — and the rest complete normally. (The split itself isn't a claim about typical abandonment rates; it's just enough of a mix to make the math below worth looking at.)
Why charge, then refund — instead of a lower rate upfront
The obvious alternative would be to just charge the net rate upfront on every invoice and skip the refund step entirely. Zyrvix doesn't do that, and the reason is the same one that shapes the rest of how the platform handles money: the outcome of an invoice — whether it gets paid, gets canceled, or quietly expires — isn't knowable at the moment it's created. Charging the lower rate upfront and trying to collect the difference later if the invoice is paid would mean attempting to charge a merchant after the fact, with no guarantee there's still balance to cover it.
That's a bigger problem for Zyrvix than it would be for a custodial processor, because Zyrvix is non-custodial: payments move straight from customer wallet to merchant wallet, so there's never a moment where the platform is holding a transaction it could deduct a top-up fee from. Charging the full rate upfront and refunding the difference down only ever moves the ledger in the safe direction — crediting a balance back always succeeds. Collecting more from a balance that might not be there is the failure mode the whole design exists to avoid.
What's not in the bill
The other half of "the real cost" is everything a headline rate can hide by simply not mentioning it. None of the following apply here, and it's worth naming them individually rather than as a vague "no hidden fees" claim:
- No conversion spread — there is no conversion. Payments arrive in TON and stay in TON; there's no step where a currency swap could quietly take a cut.
- No payout fee — there is no payout. Funds go directly to the wallet you registered, on-chain, the moment a customer pays; nothing sits in a pooled account waiting to be paid out on a schedule.
- No per-transaction network markup — the invoice fee is the invoice fee. It isn't padded to also cover network costs on top.
TON in, TON out. What the invoice fee percentage buys is the actual work — issuing the invoice, watching the chain for a matching payment, notifying your system the moment one lands — not a markup layered on top of a currency move that isn't happening in the first place.
The honest column
A fee page that only lists what's not charged would be incomplete. Two real costs exist, and they're worth stating as plainly as everything above.
First, a small monthly base fee, auto-deducted from your balance (see live pricing). Second, a prepaid balance requirement: because Zyrvix never holds a transaction to deduct a fee from, it needs a balance to charge against instead, funded ahead of time. That's real onboarding friction a custodial processor — one that already holds your money before paying you out — doesn't have to ask a merchant for. It's a structural consequence of the non-custodial model, not an oversight, and it's worth saying plainly rather than leaving a reader to discover it at signup.
One more thing belongs in this column rather than buried: an invoice that expires unpaid is not free. It's refunded down to the lower net rate — never the full rate — but the net rate is still a real, nonzero cost. An abandoned checkout costs you something, just less than a completed one does. That's the honest version of the refund story, not "abandoned invoices cost nothing."