We do not accept fiat. We do not use Stripe, PayPal, BitPay, Coinbase Commerce or any other payment processor. Invoices are generated by a BTCPay Server instance we operate ourselves, on infrastructure we control. Your payment confirms on-chain (or off-chain via Lightning) and the service activates.
# BIP-21 invoices include both on-chain and Lightning options.
# Recommended for privacy-conscious customers.
# EIP-1559 supported. EOA wallets only; we do not accept smart-contract wallets to avoid replay/reentrancy edge cases.
# TRC-20 (TRON) is the cheapest network for USDT in our experience and the one most customers use.
# BASE and ARB networks supported via standard ERC-20 contract.
# SOL invoicing has the lowest fee of any cryptocurrency we accept.
# Functionally similar to BTC on-chain but with cheaper fees and faster confirmation.
# Energy-staked TRON wallets pay near zero fee.
# CashAddr format required.
# Native chain only.
# MakerDAO-issued DAI on Ethereum mainnet.
Tell us what you need: SMTP tier, IP count, jurisdiction, addons. We confirm the configuration and price in EUR. Most quotes are returned within 12 minutes during operating hours.
The invoice page lists every cryptocurrency we accept with the live exchange rate at the moment of invoice generation. The amount is locked at that rate for 15 minutes (longer windows on request). You pick the cryptocurrency that's most practical for you and send the exact amount to the displayed address.
Confirmation requirements depend on the cryptocurrency you chose. Lightning is instant, Solana is ~13 seconds, Bitcoin on-chain is ~10 minutes, Ethereum is ~3 minutes. The invoice page updates in real time as confirmations arrive.
SMTP credentials, server access, DNS records to publish, DKIM keys, and any warmup schedule we agreed on are delivered via the channel you specified (Telegram or ticket). Most provisioning completes within 2 to 6 hours of payment confirmation.
Network fees (Bitcoin miner fees, Ethereum gas, etc.) are paid by the sender on top of the invoiced amount. We do not absorb network fees because they vary too widely to price into the EUR invoice fairly.
We recommend Lightning Network for invoices below €100, where on-chain Bitcoin fees can become a meaningful percentage of the amount paid. For invoices above €1000, the choice of network has minimal impact on the total.
Overpayment. We refund the excess in the same cryptocurrency, minus the network fee for the refund transaction. Or, by mutual agreement, we credit the excess to a future invoice. Most customers prefer this option to avoid paying a second network fee.
Underpayment. The invoice remains open. You send the difference and the invoice clears. If the underpayment is small (under €5 equivalent) we usually accept the invoice as paid and move on; flagged at our discretion.
We run BTCPay Server ourselves on infrastructure we control. There is no payment-processor company between you and us. No KYC checks at the processor level. No "fraud screening" against your wallet history. No risk that a processor's compliance team freezes your invoice mid-confirmation.
BTCPay Server is open-source software widely audited by the Bitcoin community. We do not modify the source for our deployment beyond standard configuration.
We do not accept Visa, Mastercard, SEPA, ACH, wire transfers, or any other fiat payment method. We are not interested in maintaining the compliance apparatus that fiat acceptance would require: KYC checks, AML reporting, chargeback handling, and the regulatory exposure that comes with each.
If you need to convert fiat to crypto for the first time, services like Strike (US), Bitvavo (EU), and Kraken (global) let you buy small amounts with a card or bank transfer, then send to our invoice address.
The payment infrastructure runs on a self-hosted BTCPay Server instance with no third-party payment processor in the payment chain. The reasoning is structural: every third-party processor in a payment chain represents a point where customer data exists outside our control, a point where transaction visibility leaks beyond the parties actually involved in the transaction, and a point where the processor can unilaterally freeze or reverse payments based on their own risk policies. We operate the payment infrastructure ourselves to eliminate these structural dependencies.
BTCPay Server is open-source software that has been production-grade since 2018 and is used by tens of thousands of operators globally. We run a version that we have audited and configured for our specific operational needs: hot wallets for the smallest invoice amounts (under €500), cold storage for everything above that, key management procedures that distribute access across multiple operators rather than concentrating it in a single person, regular reconciliation against on-chain state to detect any discrepancies. The wallet infrastructure is segregated from the customer-facing site infrastructure for security isolation.
For Monero specifically, we run a self-hosted node with subaddress generation per invoice. Each invoice gets a unique subaddress that is not used for any other purpose, which provides per-invoice unlinkability at the protocol level. We do not run external Monero indexers, do not subscribe to chain-analysis services for Monero (the structural privacy of Monero makes such services ineffective anyway), and do not retain customer payment attribution beyond what is required for service provisioning.
For Lightning Network, we run a self-hosted LND node paired with the BTCPay Server instance. Lightning invoices are HTLC-secured with appropriate timeouts, and we maintain adequate inbound capacity through channel partnerships to handle expected invoice volume. Customers paying via Lightning receive Lightning invoices that include the full payment hash and timeout window; payment confirmation is effectively instant (sub-second) compared to on-chain Bitcoin which takes 10-60 minutes for the confirmations we require.
Cryptocurrency privacy varies substantially across the eleven coins we accept, and the choice of coin has implications for what is publicly observable about the transaction. Customers selecting payment method should understand the trade-offs because the wrong choice can undo other privacy work they have done.
Maximum privacy: Monero (XMR) provides protocol-level privacy through ring signatures, stealth addresses, and confidential amounts. On-chain analysis of Monero transactions is not generally possible with current techniques; the chain reveals that transactions occurred but not amounts, source addresses, or destination addresses. For invoices where on-chain privacy matters (privacy-positioned products, journalistic infrastructure, operators in restrictive jurisdictions), Monero is the recommended default.
Strong privacy: Lightning Network for Bitcoin provides effective unlinkability between sender and receiver because payments route through multiple intermediate nodes that each see only the next hop in the chain. Chain analysis cannot reconstruct payment paths from publicly available data. Lightning is appropriate for smaller invoices (€100 and below) where its fee economics are most favourable; larger invoices can be split into multiple Lightning payments if privacy matters more than operational simplicity.
Pseudonymous: Bitcoin on-chain, Ethereum, Litecoin, Bitcoin Cash, Dogecoin, and DAI on most chains are pseudonymous: transactions are publicly visible and permanently recorded, but addresses do not directly identify individuals. The privacy posture depends on whether the customer has used the same address for other purposes (which links transactions across uses) and whether the funding source for the address has KYC attribution (such as withdrawal from an exchange that KYC'd the customer). For customers whose funding source is itself private, on-chain Bitcoin or similar provides meaningful pseudonymity.
Reduced privacy: Stablecoins on regulated chains (USDT and USDC on ERC-20, Solana, Polygon, Base, and Arbitrum; the issuer has the technical capability to freeze tokens at specific addresses and has done so in response to legal process. The privacy posture of stablecoin payments is good for operational predictability (the amount you pay equals the amount we receive) but weaker for privacy than non-stablecoin alternatives. The choice often comes down to whether stable amounts or stronger privacy matter more for the specific transaction.
The summary recommendation: Monero for maximum privacy on any invoice size, Lightning Network for Bitcoin payments below €100 where fees and privacy both favour it, on-chain Bitcoin or Litecoin for medium invoices where the customer has private funding sources, and stablecoins for customers who prioritise price stability over chain privacy. The choice is always the customer's; we accept all eleven and do not steer customers toward one option or another.
Our cryptocurrency payment infrastructure handles eleven cryptocurrencies as of 2026, with the operational patterns reflecting actual customer payment behavior rather than abstract feature completeness. The patterns matter because customers evaluating cryptocurrency payment for hosting services benefit from understanding what works versus what creates operational friction.
Bitcoin (BTC) on-chain: the standard cryptocurrency payment option for customers preferring established infrastructure. Confirmation time runs 10-60 minutes depending on network conditions and confirmation requirements; we accept payment with 1 confirmation for most transactions, 3 confirmations for amounts above EUR 5,000. Transaction fees range from USD 1-15 depending on network congestion and transaction priority.
Bitcoin (BTC) Lightning Network: the operationally superior option for amounts below approximately USD 500. Lightning payments settle within seconds with negligible fees (typically under USD 0.10). The 2026 Lightning ecosystem has matured substantially: aggregate routing capacity exceeds 5,000 BTC, node count exceeds 16,000, payment success rates run above 95% for typical channel sizes. Customers familiar with Lightning find it the smoothest cryptocurrency payment experience.
Monero (XMR): the operational option for customers prioritizing financial privacy beyond what Bitcoin on-chain provides. Confirmation time runs 20-40 minutes typical; transaction fees range USD 0.01-0.20 reflecting Monero's privacy-preserving but lower-volume network. Customer-facing operations require generating fresh Monero subaddresses per transaction to maintain privacy properties; our integration handles the subaddress generation transparently.
Stablecoins (USDT, USDC) on various chains: the operational option for customers preferring price stability and operational speed. Tron-based USDT and USDC have low fees (under USD 1) and fast confirmation (under 5 minutes). Ethereum-based stablecoins have higher fees (USD 5-50 depending on network conditions) but produce equivalent operational outcomes. Customer choice between chains often reflects existing customer wallet infrastructure.
Payment processing follows specific operational patterns that customers benefit from understanding before initiating payments. The patterns affect timing expectations and operational outcomes.
Step 1: invoice generation. Customer-facing invoices generate with specific payment addresses, payment amounts, and confirmation requirements. The invoice includes a time window during which the payment address remains valid (typically 4-24 hours depending on cryptocurrency); payments arriving after the window may require additional coordination.
Step 2: payment initiation from customer wallet. Customer sends the payment from their wallet to the invoice address. Customer-side responsibility includes correct amount, correct address, appropriate network fees for the customer wallet to actually broadcast the transaction.
Step 3: blockchain confirmation. The network confirms the transaction through standard mining/validation processes. Confirmation time varies by cryptocurrency as documented above. Our infrastructure monitors the blockchain for incoming payments to the invoice addresses.
Step 4: payment recognition and service activation. Once required confirmations complete, our infrastructure recognizes the payment and activates the customer service. Activation timing varies by service type: subscription extensions happen within minutes of confirmation, new service provisioning happens within business hours regardless of when confirmation completes.
Step 5: customer-facing confirmation. Customers receive payment confirmation through their preferred channel (Telegram, email, ticket update). The confirmation includes payment amount, confirmation timestamp, service activation details, next billing cycle information if applicable.
Total time from customer payment initiation to service activation ranges from minutes (Lightning, Tron stablecoins, fast cryptocurrencies during low network congestion) to hours (slower cryptocurrencies during high network congestion). Customer expectations should match the actual timing rather than assuming instantaneous activation across all payment methods.
Customer-side payment operations matter for getting cryptocurrency payments to flow smoothly. The considerations below capture what production customers settle on after experiencing the operational realities of cryptocurrency payment.
Consideration 1: wallet selection. Customer wallet choice affects operational smoothness substantially. Self-custodial wallets (hardware wallets, software wallets the customer controls) produce predictable operational outcomes; custodial wallets (exchange-based wallets, custodial services) sometimes introduce operational complications including withdrawal limits, KYC requirements affecting transactions, transaction batching that delays specific transactions.
Consideration 2: network fee management. Customers setting transaction fees too low produce transactions that may not confirm in reasonable time. The customer-side fee setting must produce timely confirmation; our address remains valid for the invoice window, but transactions confirming after the window require coordination to apply the payment correctly.
Consideration 3: amount precision. Cryptocurrency amounts must match invoice amounts within reasonable precision. Overpayment by small amounts (typical in wallet operations) generates account credit applied to subsequent invoices. Underpayment requires the customer to send the difference; partial payment cannot generally activate services.
Consideration 4: cross-chain confusion. Customers occasionally send payment on the wrong chain (USDT on Ethereum to a Tron USDT address, for example). Recovery from cross-chain mistakes is sometimes possible but operationally complex; customers should verify the invoice chain before initiating payment.
Consideration 5: regulatory considerations from customer side. Customer-side jurisdictions may have cryptocurrency regulations affecting how customers transact. Customer responsibility includes complying with their own jurisdictional requirements; our acceptance of cryptocurrency payment does not constitute regulatory guidance for customer operations.
Some customers require fiat payment for specific operational reasons. Fiat payment availability is limited compared to cryptocurrency payment but exists for customers whose requirements warrant it.
Available fiat payment methods: SEPA bank transfer for EU customers (no minimum, processing time 1-3 business days), wire transfer for non-EU customers (USD 25 fee, processing time 2-5 business days), invoice-based billing with NET 30 terms for established customers (minimum monthly commitment EUR 500). Credit card payment is not available; the operational overhead of credit card processing does not match the customer base.
Fiat payment situations: customer regulatory requirements that prohibit cryptocurrency transactions, customer accounting requirements that require traditional invoicing and payment records, customer operational requirements that benefit from fiat-denominated pricing rather than cryptocurrency conversion volatility. Each situation has explicit fit for fiat payment that operational standard pricing would not match.
Cryptocurrency remains the operationally smoother payment path for most customers. The fiat payment availability accommodates specific customer requirements; customers without specific fiat requirements typically find cryptocurrency payment produces faster operational outcomes with lower friction.
Customer refund situations occur occasionally for various reasons: service cancellation with prepaid period remaining, payment errors requiring correction, duplicate payments. Refund handling follows specific patterns rather than ad-hoc resolution.
Cryptocurrency refunds: returned in the same cryptocurrency as the original payment when feasible. Customer wallet address required for refund processing; we cannot generally reverse blockchain transactions without explicit customer wallet coordination. Refund processing time runs 1-7 business days depending on cryptocurrency and customer wallet availability.
Account credit: alternative to cash refund for customers preferring credit toward future services. Account credit applies automatically to subsequent invoices without requiring explicit customer action.
No. The first interaction is a quote request on Telegram or via ticket. We send you an invoice link, you pay, the service activates. There is no "create account" step; your Telegram handle or email is your account.
The invoice locks the cryptocurrency amount at the moment of generation, valid for 15 minutes by default (longer on request). If you pay within the window, the rate is what you saw. If the window expires, we generate a new invoice at the current rate.
Technically yes; the address we generate is a regular address. But exchanges sometimes apply additional verification to outgoing transactions, which can delay your payment or get it returned. We recommend paying from a self-custodial wallet whenever possible.
Yes. ETH on Arbitrum and Base, USDC on Arbitrum, Base and Solana, USDT on TRON / BSC / Solana / Polygon. The cheaper L2 networks are the ones most customers use; Ethereum mainnet remains supported but it's rarely the optimal choice for invoices below €500.
€19, our cheapest VPS tier. Below that we run into a problem where the network fee for the cheapest cryptocurrency exceeds 5% of the invoice value, which is uncomfortable for both sides. Use addon bundles or longer billing periods to stay above the threshold.
We do not report payments to any authority on a routine basis. We do not file CTRs, SARs, or equivalent reports under any country's anti-money-laundering framework. We are not a payment processor and these obligations do not apply to us.
We respond to valid legal process (see our Privacy Policy), but informational disclosures of payment activity for surveillance purposes are not part of our normal operations.
Ready to talk through what you need?