Cards, and the identity that travels with them
A card is not merely a way to move money. It carries a legal name, an address that has to match, a phone number that receives codes, and a right of reversal that lasts for months. Every one of those facts changes how a host has to treat you.
What a card brings with it
None of this is the host being nosy. It is the instrument.
The name is not optional
Card networks require a cardholder name, and merchants are expected to keep it with the transaction. A host taking cards therefore knows who you are, whatever the sign-up form implies about privacy.
Address verification links you to a place
The billing address is checked against issuer records, so a mismatch means a decline. Your home or office address ends up in the merchant record next to a list of the servers you run.
Strong authentication adds a phone
Additional verification steps route through a device your bank already associates with you. Three identifiers now describe one hosting account.
The statement line is a disclosure
Whoever reads the statement sees the merchant. For a shared card, a company card or a joint account, that is a small unwanted broadcast every month.
Stored cards are standing authority
Automatic renewal is convenient until it is a price increase you did not read about, or a service you cancelled in a panel that did not cancel the mandate.
Chargebacks explain most host behaviour
Once you understand that a card payment can be reversed up to a hundred and twenty days later, the rest of a card-taking host’s policy stops looking arbitrary.
Fraudulent orders are a solved problem for the fraudster and an unsolved one for the merchant. A stolen card buys ten instances, they are used hard for a fortnight, the real owner disputes the charge, and the host loses the money, the fee and the transit reputation in one movement.
Everything downstream follows: manual review queues for orders that look unusual, identity checks on refunds, geographic restrictions, and a support desk with authority to suspend first. It is a rational response to the instrument, and it is why so many hosts that genuinely wanted to stay light on data ended up asking for documents anyway.
Card against coin, mechanically
| Card-only host | Crypto through OxaPay | |
|---|---|---|
| Identity attached to a payment | Legal name, billing address, frequently a phone number | None |
| Time to settle | Authorised instantly, captured later | One to three confirmations for most assets |
| Reversal risk to the host | A chargeback up to a hundred and twenty days later | None once the chain confirms |
| Refunds | Back to the card, over several days | Back in the asset you paid, inside a seven day window |
| Common failure mode | Declined by an issuer that dislikes cross-border merchants | A fee spike, or a payment sent on the wrong network |
| Renewal | A stored card charged automatically | A balance you top up, or an invoice you pay each cycle |
| Accounting | Fits every expense system ever written | Someone has to reconcile a chain against an invoice |
| Price movement between paying and spending | None | Yours to manage |
| Assets accepted | One currency, one instrument | Around thirty assets across the major chains |
When a card-only host is the better choice
Several of these are about your colleagues rather than your servers.
Expenses and reimbursement
If a finance system needs a card receipt to reimburse you, crypto turns a €54 invoice into a conversation. Convenience has a value, and the value here is measured in emails you did not have to send.
No practical access to crypto
In some countries obtaining and moving coin is awkward, taxed oddly, or restricted outright. A card that already works beats an instrument you have to acquire first.
You want renewals to happen without you
Stored cards renew silently, which is exactly what you want for infrastructure you would rather not think about. Our top-up balance is close, but somebody still has to fund it.
Volatility is a real cost to you
Holding an asset between purchase and spend is a small position whether you want one or not. If that is unacceptable, stablecoins reduce it and a card removes it.
How payment actually works here
The flow is short, and the whole of it happens without a human on our side reading anything about you.
- 01
Choose an asset
Bitcoin, Monero, Ethereum, Litecoin, USDT on four chains, and roughly two dozen others. Pick whichever is cheapest to move on the day; the network fee is shown before you commit to anything.
- 02
Send once, to one address
The address is valid for that invoice alone, with the exact amount already calculated. Underpayments are matched and the shortfall is shown, so a fee surprise does not lose your money.
- 03
Confirmations clear
Most assets settle within one to three confirmations. The dashboard tracks it live and you are free to close the tab; the invoice does not need you watching it.
- 04
The server exists
Provisioning fires on the settlement webhook, and root credentials arrive by mail a median of 47 seconds later. Nothing waits for a review queue, because there is no review queue.
Balance top-ups behave the same way and are the sensible option if you run several small instances. Pay once, spend it down, and stop watching the mempool at every renewal.
Questions
Around thirty, through OxaPay, across the major chains, including Monero and USDT on four networks. The live list sits in the checkout, because assets get added and occasionally removed.
No. That is not a philosophical position, it is the mechanism that keeps sign-up down to an email address, since any card or bank rail would drag identity back in with it.
An underpayment is credited and the invoice shows the remaining amount, so you can top it up. Overpayments land in your account balance and pay the next invoice, or are returned on request.
Only until settlement, in order to match a payment to an invoice. Once settled, the reference is purged and the invoice record carries no chain data.
Coin in, server out
Thirty-odd assets, a single address per invoice, and the network fee shown before you send anything. Root credentials land a median of forty-seven seconds after the chain confirms.