How a crypto invoice works — nineteen coins, one watcher, zero card steps

One invoice page, nineteen coins, exact-amount matching by a server-side watcher. Sentry from $7.50 ($6.00 annual-eff); VPS images ~60 seconds after credit.

Published 2026-08-30 · Updated 2026-10-14 · FYRHost Editorial · 19 min read

No card step is a design decision

The conventional checkout treats crypto as a spice — cards first, a Bitcoin door bolted on through a processor, KYC arriving with the processor's license. This flow inverts it: the invoice engine is the native path and the card step does not exist, which is not a limitation of ambition but the load-bearing wall of the whole privacy posture. A licensed processor between you and the rack runs identity checks regardless of what the host wants; remove the processor and the demand has nowhere to enter. Everything else on this page — the watcher, the rate lock, the single-use address — is engineering for a world where that middleman never existed.

The mechanism reads short: configure a plan in dollars, convert once at a live rate, bind the result to one asset on one network, and let chain confirmations do the authentication. Nineteen doors share the skeleton — BTC and XMR, the seven USDT rails, XRP, GRAM (TON) and the rest — and each invoice is a closed object: exact amount, exact address, exact depth, printed before any money moves. No transaction hash is ever pasted into a form, because the checkout never needs one; the standard playbook for crypto payment processing explains why single-use addresses are the discipline that makes matching trivial instead of heuristic.

Where it breaks: bringing card-era instincts to a chain-era instrument. Card payments are reversible, float on statements, and settle in a currency your bank names; a crypto invoice is final, exists only as an on-chain event, and settles in exactly the figure it printed. Every failure mode in this guide — underpayment, wrong chain, stale invoice — descends from treating the second instrument like the first. The flow rewards people who read the printed numbers once and send them precisely.

You can test the claim in one step: open the invoice page for any plan, pick any coin, and read what the page asks of you before it shows an address. No document upload appears between your click and the quote, and nothing in the fine print reserves the right to add one later — the flow is short because it was designed short, and the design is the disclosure.

Six fields, one credential: the order before the money

Before money moves, the form wants six answers and one credential, and the order matters to your privacy more than the fields do. Plan, billing term, one of forty locations, an OS image: those four are the server. The fifth is the identity step, and its smallness is the feature — an email string or an anonymous token, plus a password of at least 12 characters. The sixth is nothing: there is no name field, no address block, no phone. The account object that results is a credential, not a profile, and every artifact this guide discusses — invoices, tickets, servers — hangs from that credential and nothing else.

The mechanism has one dependency you own: the mailbox. Credentials mail, invoice codes and panel recovery all land there, so the address you type should be one you can still open next quarter — a long-lived inbox or an alias in front of one, dedicated to this host. The token-only signup variant exists for buyers who prefer no mailbox at all in the record. Pricing needs no field because the term decides it: entry Scout — 1 vCPU, 2 GB ECC, 40 GB NVMe on 1 Gbps — lists at $5.49 and runs $3.00 on the annual term, with the −20 percent applied to the USD total before any coin is chosen.

Write your credential down before you need it, and store it the way you store anything that cannot be reset by a support form: a password-manager entry, a printed card in a drawer, whatever you will actually find in month six. The desk can help you with almost everything except a lost mailbox plus a lost password — those 2 strings you own on both ends, and nobody else can hold them for you.

Where it breaks: treating the credential as disposable because it is small. A lost inbox plus a lost password is a lost account — the ticket desk verifies ownership with exactly the strings that exist, which is the email-or-token, the invoice code and the transaction ID. The second classic is misreading the token option as a second identity layer; it is a first identity layer, an alternative to the email string, and its record is shorter by exactly one mailbox.

Credential created and plan configured, the invoice page is where the interesting engineering lives — a watcher that reads public chains on your behalf.

How a watcher reads a public chain

The most common misimagination of crypto checkout is that someone reads your transaction and stamps it. Nobody does. A server-side watcher watches the public chain you paid on, for one address, at one amount, at one confirmation depth — all three printed on the invoice before you sent anything. When the chain produces an inbound payment matching the stored figure at the stored depth, the order credits; the process is arithmetic on public data, which is why it runs at 4 a.m. without a support shift and why you never paste a transaction hash into the checkout at all.

The mechanism leans on address discipline rather than heuristics. Each invoice gets an address created for it, used once, retired after credit — the pattern the payment-processing reference recommends for exactly this reason: matching an exact amount on a fresh address needs no fuzzy logic, no memo parsing, no reconciliation queue. The chains differ only in constants. Bitcoin balances probability against depth (2 confirmations here, 10–60 minutes of wall clock); Monero counts its privacy-preserving blocks (10, typically 2–20 minutes); XRP reaches finality in 3 ledgers; TON in 3 blocks. The Monero daemon interface and the TON documentation expose the same shape of primitives their chains' watchers consume.

Where it breaks: the address reuse instinct. A payment for an old invoice sent to a new invoice's address (or vice versa) creates an event that matches nothing, and no amount of ticket prose changes what the chain says happened. The single-use design means the recovery tool is attribution after the fact — the transaction ID in a ticket — not address recycling, which is permanently off the table.

Watch what this design does to your own habits: because the address is fresh and the amount is exact, there is nothing for you to configure, reference or remember. The invoice page is your complete instruction set — amount, address, depth — and the best thing you can do with it is read it once and follow it precisely.

The watcher reads chains; the rate lock is what it reads first. How a USD total becomes a fixed crypto figure is next.

The rate lock: stored amount beats live ticker

Buyers expect crypto pricing to be a gamble against the ticker; the invoice makes it a snapshot. Your plan prices in dollars — a Sentry at $7.50, a year at −20% — and the conversion to your chosen coin happens at creation, once, from a same-origin rate feed. While the invoice page sits open, the figure redraws every 60 seconds; the moment you click create, the stored amount becomes the invoice. Later moves in the market change nothing: not the credit threshold, not the provisioning clock, not the desk's matching logic. The stored figure is the whole contract.

The mechanism is worth internalizing because it explains two behaviors that look like bugs and are the design. First, a payment of the stored amount always credits, regardless of what the coin did after creation — the invoice deliberately does not re-price against you in a pump or a dump. Second, a stale invoice does not adapt: an order left unpaid for days is quoted against a market that has moved on, so the right move is a fresh invoice rather than a payment against an old figure. Dollar-pegged USDT exists precisely for buyers who want the lock to be a formality — the seven USDT rails keep the stored figure and the eventual value within cents of each other.

Where it breaks: underpayment by rounding. Wallets that "helpfully" round the sent amount down to a clean number produce a payment the matcher must treat as short, and short payments wait for a human rather than credit automatically. Send the printed figure to the last decimal — the invoice exists at that precision — and where fees are your concern, pick the rail by its fee floor (TRC-20 for cents-level transfers) instead of by shaving the invoice amount.

If you are paying a small invoice, make the lock work for you rather than against you: create the invoice when you are ready to pay, not as a bookmark, and pay the printed figure without re-checking the market afterward. The stored amount is your contract; the ticker stopped being your business the moment you clicked create — which is exactly the property that makes the invoice feel like a receipt instead of a bet.

Amount locked and address printed, the only clock left is the chain's own: confirmation depth, network by network.

Confirmations: each network sets its own depth

A crypto invoice does not wait for a human or a bank; it waits for physics, and each chain sells a different kind. Bitcoin reorganizes, so depth is probability: 2 confirmations here, landing anywhere from 10 to 60 minutes as the fee market breathes. Monero's blocks are private and quick: 10 of them, 2–20 minutes. XRP finalizes by consensus rather than mining: 3 ledgers, no destination tag required on this checkout, ETA 1–3 minutes. TON counts 3 blocks to credit. The depth and the ETA print on the invoice page before you pay — the number that governs your wait is on your own screen, not in a policy document.

The mechanism behind the differences is consensus design, and you pay for it in exactly one currency: patience. Proof-of-work chains buy reorganization resistance by waiting — each block buries the last deeper under work, and the transaction lifecycle reference shows why two confirmations is the pragmatic commercial depth on BTC. Consensus-final chains buy it by agreement — a closed ledger stays closed, which is why XRP's credit arrives in minutes and needs no hedging. Privacy chains split the difference: Monero's ten blocks clear inside most coffee orders while keeping amounts and counterparties off the public record entirely.

Where it breaks: if you import other hosts' folklore, you wait on depth that is a property of the invoice, not of your anxiety — a BTC payment at one confirmation sits uncredited by design even when an explorer calls it "confirmed" on the first pass. The inverse error is treating the ETA as a service-level agreement: the printed window is typical, the fee market is weather, and a payment that takes 90 minutes on a congested BTC hour has not stalled, it has been rained on.

Whichever depth your invoice prints, the behavior that serves you is identical: send once, then leave the chain alone. Depth is the chain's own business, the ETA on your page is its best estimate, and your invoice will credit the moment the arithmetic says so — at that hour, on that fee market, without your supervision.

Most invoices clear without a second thought. The section after the next one is for the rest — but first, the quiet half of the privacy claim: what this checkout never asks for, from anyone, at any invoice size.

What the checkout never asks for

The negative inventory is the privacy claim, stated as facts rather than adjectives. No identity document, no selfie, no phone number — at signup, at payment, at any spend threshold, at any tier up to dual-EPYC metal. No card, because the instrument does not exist in this flow. No wallet scoring: no chain-analysis product grades the coins that arrive, and the checkout's entire knowledge of your funds is an amount and a network. No EUR-denominated billing, because the invoice is priced in dollars and paid in the coin you picked. The absence list is the product; everything else is packaging.

The mechanism that keeps the list empty is upstream design, not downstream mercy. Identity demands enter commerce through licensed intermediaries — processors, banks, settlement rails — and this flow routes around all of them by construction: you pay the chain, the watcher reads the chain, the credit is arithmetic. What the design cannot do is reach backward into your history: an exchange that identified you when you bought the coins keeps that file on its own books, and a public chain prints the transfer forever. The checkout makes no claims about your past; it declines to add to it. The master FAQ keeps the edge cases — refunds, metadata windows, the 24h rule — in one scroll.

Where it breaks: reading no-KYC as an incantation instead of an inventory. The test you should run against any host's claim is mechanical: does the signup take documents at any step, does a card door exist anywhere, does the privacy page name which records exist. A shop that lists crypto but onboards through a processor has moved the KYC one company over; a shop that claims zero data is describing a fiction, because invoices and credentials must exist somewhere for the account to function at all.

The 3 failure classes you will meet in this guide share one cheap insurance policy: keep the invoice code and the transaction hash the moment they exist — 2 strings, one place — before you need either. Every recovery runs on those strings, and the cases that drag on are almost always the ones where you must go digging through an exchange's history pages for a hash after the fact.

Asked-nothing accounts still have paperwork — the benign kind. What the invoice engine records, credits and refunds is the accounting trail, next.

The accounting trail: invoices, balance credit, refunds

Every payment writes a small, legible record: the invoice code, the plan and term it priced, the asset and network, the transaction ID the chain published, the timestamp of credit. That record is what support sees, what the panel shows, and — deliberately — all it shows. The annual term writes the same record once a year instead of twelve times: the −20 percent applies to the USD total first, the discounted figure converts at the live rate, and one payment covers twelve months. Upgrades write new records rather than editing old ones, which is why the trail reads like a ledger and not a word processor.

The refund mechanism has a default worth knowing before you need it: unused time credits the account balance by default, and an automatic refund to the chain is not the default action — chain refunds are worked explicitly by ticket, invoice code attached, because pushing funds back on-chain is an operation with its own fees and its own finality. Credit balance, by contrast, is instant and internal: it rides the account, pays the next invoice, and never touches a chain. Cancelling a plan mid-term, changing a tier — the VPS-versus-dedicated sizing page covers when that makes sense — all resolve through the same balance-first path.

Where it breaks: expecting a chargeback. There is no card network to dispute through, no reversible rail underneath; the remedy ladder is ticket, then balance, then explicit chain refund, in that order, and buyers who price that in at purchase time make calmer customers. The second break is expecting the invoice record to be anonymous to the world: the chain leg is public by nature — a USDT-TRC-20 transfer is readable by anyone, forever — while the invoice record on this side stays behind the account. The refund policy page states the windows and the 48-hour processing commitment in plain numbers.

Read your own trail once a term: the panel's invoice list is the complete history of what you paid, when, and on which rail, and it reconciles cleanly against your wallet's export because both sides reference the same on-chain events. 10 minutes at renewal time tells you what your infrastructure actually costs you — the number most budgets guess and most dashboards never quite show.

Records, credits, refunds — the boring machinery that makes the interesting machinery trustworthy. When an invoice does not clear, though, the machinery hands the case to you; the recovery playbook is the last technical section.

Underpaid, overpaid, wrong chain: recovery without panic

3 ways an invoice sticks — underpaid, overpaid, wrong chain — and all three share the same first move: stop before sending anything else. Underpayment — the watcher waits for the exact stored figure and keeps waiting; the case is a ticket with the transaction ID, and operations either completes the gap on the same invoice or advises a fresh one. Overpayment — the credit still lands, matched by amount-plus-address, and the surplus resolves through the balance-and-ticket path from the accounting section. Wrong chain — the wrapped-token class: a payment sent as a token on a network where your invoice address does not exist. That last one is not a delay to recover from but a loss to diagnose before sending, which is why every coin-specific guide on this shelf opens with the native-asset check.

Rehearse the recovery once before you need it, so your fingers know the order: copy the invoice code, copy the transaction hash, open the ticket, paste both, describe what you expected. 5 steps, about 2 minutes, no improvisation — the difference between a case that closes on the first reply and one that teaches you how support queues age.

The mechanism of recovery is attribution, and the transaction ID is its entire toolkit. The desk can match any payment to any invoice given the hash — which transaction, which address, which amount — but every additional blind transfer adds a second event to attribute, and the classic compounding error is the "corrective" resend: a second payment to the same address that doubles the problem while solving nothing. Addresses stay single-use; no invoice ever gets recycled into a new attempt. One hash, one ticket, one round-trip is the pattern the queue rewards.

Where it breaks, final form: diagnosing by feeling instead of by explorer. The two-minute version is mechanical — the wallet shows a hash or it does not. No hash: the send never left, and the queue is on the sending exchange's side. Hash with a success status: the payment landed, and any mismatch is on the invoice-matching side, which is ticket territory with the ID attached. Hash with a failure status: the chain itself rejected the payment, and the explorer's result code says why. The ticket walkthrough lists the exact fields to paste; nothing else in the flow rewards improvisation.

The invoice, in the order to run it

The whole flow, run as a timeline. Configure: plan and term against the workload first — storage tiers for disk-shaped jobs, metal for whole cores — because the catalog's arithmetic prices the decision for you in advance, from the $3.00 entry tier to the top of the virtual line; then one of forty locations, then an OS image. Identify: an email or token plus a password of at least 12 characters, in an inbox you keep. Create the invoice: pick one asset on one network from the nineteen doors — XMR when the rail should leak least, USDT-TRC-20 when cents-level fees and a stable quote matter, XRP or TON when speed is the point — and the rate locks the moment you click.

Pay: send the exact printed figure to the exact printed address in one transfer — native asset, destination tag when the invoice shows one, no rounding, no second send. Wait the printed depth: 2 confirmations for BTC across 10–60 minutes, 10 blocks for XMR inside 2–20 minutes, 3 ledgers for XRP, 3 blocks for TON. If anything reads wrong, the hash is the diagnosis and the ticket with the ID is the cure; if it reads right, provisioning starts on a clock that ignores coins — VPS and storage boxes image about 60 seconds after the credit, dedicated metal 2–4 hours through racking with IPMI handed over last.

Then the paper trail, already written: the invoice code in your panel, the transaction ID on the chain, the balance-first refund path if a term ends early, and a records inventory that never grew a name field. The USDT walkthrough, the XRP walkthrough and the Monero guide retell this same timeline in each rail's dialect, and the ninety-second version of everything lives in the FAQ. If you ever switch rails mid-project, the TON walkthrough tells you the same story for TON's UQ… addresses, and none of what you learned changes. The flow rewards exactly one behavior — read your printed numbers once, send them precisely — and it has run that way for every invoice since the first.