Coin in. Server out. No card field.
Payment is the reason sign-up can stay at one field. A card drags a legal name, a billing address and a bank along behind it, and nothing of the sort follows a transaction. Here is the whole mechanism, including the parts that occasionally go wrong.
Why there is no fiat option
This is not a philosophical position about money. It is arithmetic about what a card network demands of the merchant.
Taking cards means taking the acquirer’s rules with them, and those rules oblige the merchant to identify the cardholder, retain that identity, and produce it on demand during a chargeback. No version of that coexists with an email-only sign-up. We would be collecting names within a month of switching it on, and telling ourselves it was temporary.
Bank transfer is the same problem in a better suit. An incoming transfer carries a name, an account and a country whether anyone wants it to or not, and once that sits in our records it is discoverable by anyone entitled to ask. So we take none of it.
The trade is real and worth stating. Crypto is more work at the moment of payment, the rate moves while you are sending, and a mistyped amount needs a human to sort out. What it buys is a sign-up form that never asks who you are.
What you can pay with
About thirty assets. The list moves as chains get cheap or congested.
The live list is generated by the checkout when you open it, since assets get added and occasionally suspended while a chain is having a bad week. What follows is the shape of that list rather than a promise about any single ticker.
Bitcoin
On-chain, one confirmation below €200 and two above it. Fees are the reason most monthly customers pay with something else.
Monero
Ten confirmations, usually inside half an hour. The common choice among accounts that want the ledger private rather than merely pseudonymous.
Ethereum and the assets on it
One confirmation once the block is safe. Gas is whatever gas is that hour, and the invoice shows the network fee before you commit to anything.
Stablecoins on four chains
Cheap and quick most of the time. The checkout marks whichever chain is cheapest to move on the day, which is frequently not the one you expected.
Litecoin and about two dozen others
Small assets settle fastest and cost least to send. Paying €29 a month? This is the sensible part of the list.
How an invoice is built
- 01
You configure and click
Plan, city, image, term. Nothing is reserved at this point and nothing is charged.
- 02
An address is generated
Single-use, bound to that invoice alone, valid for a fixed window. It is never reused and it is discarded on our side the moment the invoice settles.
- 03
The rate is locked
The euro price converts at the rate shown, and that rate holds for the life of the window. Market movement in the meantime is ours to absorb.
- 04
You send once
One transaction, the exact amount, from wherever you like. What wallet it came from is not visible to us and not something we could ask about.
- 05
Confirmations clear
The dashboard follows the chain live. Close the tab if you want; the mail will find you.
- 06
Provisioning fires
On the settlement event rather than on a human noticing. Median time from settlement to root credentials is forty-seven seconds.
The payment window is fifteen minutes on fast chains and sixty on Bitcoin. Send after it closes and nothing is lost: the payment simply sits unmatched until somebody reconciles it by hand, which takes a ticket and usually under an hour.
Underpaid, overpaid, wrong chain
About one payment in four hundred arrives wrong in some way. None has ever been lost, and every fix below is mechanical rather than a favour.
Underpaid
The invoice stays open with the shortfall displayed. Send the difference to the same address inside the window and it settles. Miss the window and the amount lands in your account balance at the rate the original invoice quoted.
Overpaid
Anything above the total is credited to the balance automatically. Ask and it goes back instead, minus the network fee, to an address you give us.
Wrong chain
Recoverable in most cases, irrecoverable in a few. Send the transaction hash quickly and you get an honest answer about which of the two this is, usually within the hour.
Sent after expiry
Matched by hand from the hash. Median resolution is well under an hour during European daytime and somewhat longer overnight.
Rate moved mid-send
Not your problem. The invoice rate is the settlement rate in both directions, including the direction that costs us money.
Refunds, balance and renewals
The network fee comes out of a refund, because moving value costs what it costs and pretending otherwise would just mean pricing it in elsewhere. Everything else goes back untouched, and no part of the process asks you to prove who you are.
Balance is the sensible route above three or four instances. Pay once a quarter, let renewals draw down against it, and stop watching the mempool on the first of every month. It also removes the only real failure mode in crypto billing, which is a renewal invoice expiring while you are asleep.
Seven days, no reason
Any first order, refunded in full, in the asset you paid with, to an address you nominate. Requests are normally out the same working day and have never taken more than three.
Pro rata after that
Unused whole months on annual and biennial terms come back. Part-months and add-ons do not. Two paragraphs of terms rather than twelve.
Balance never expires
Top up once, spend it down across instances and renewals. Refundable on the same terms as the payment that funded it.
What the provider sees, and what we see
Settlement is handled by OxaPay. Being precise about the split matters more than reassuring you about it.
Two systems, two views, and no name in either of them.
Neither column reconstructs a person on its own, and the join between them is an invoice number rather than an identity. That is the entire design. It is also the reason a card is impossible here: a card puts a legal name in the left column, and there is no honest way to keep it out of the right.
| Item | Payment provider | Us |
|---|---|---|
| Your email address | Not passed to it | Held for the life of the account |
| Your name | Never collected | Never collected |
| The paying wallet or address | Visible to it, necessarily | Not stored after settlement |
| Transaction hash | Visible to it | Held until the invoice settles, then purged |
| Invoice amount and reference | Visible to it | Kept twenty-four months, with no identity attached |
| Which server you bought | Not passed to it | Held while the service exists |
| Your network address at checkout | Not passed to it | Not written to disk |
Questions about paying
For a €29 instance, whichever low-fee chain the checkout marks cheapest that day. At €749 for a GPU node the fee is noise, so use whatever you already hold and stop optimising.
Mechanically, yes; the chain does not tell us where value came from. Whether it is wise is a separate question, because the exchange knows exactly who you are even though we do not, and a withdrawal directly to an invoice address is a link between the two.
Somewhere between thirty seconds and half an hour, depending entirely on the chain rather than on us. Provisioning then starts on the settlement event and takes another forty-seven seconds at the median.
Yes. Every invoice downloads as a PDF carrying the amount, the term, the asset and the site. It also carries whatever you typed into the optional billing name field, including nothing at all.
The rate locks when the invoice is generated. You send the quoted amount in the quoted asset and the movement is ours, in whichever direction it goes.
Not while it costs an email-only sign-up. Show us a payment rail that does not require the merchant to identify the payer and we will look at it the same week.
Pick an asset and be done in a minute.
The configurator quotes the network fee before you commit, the rate holds for the window, and the credentials arrive while you are still watching the confirmation counter.