[ホーム](https://servhidden.com/ja) / [プライバシーホスティングガイド](https://servhidden.com/ja/guides) / How to Self-Host a Crypto Payment Gateway with BTCPay Server 運用 # Self-Host a Crypto Payment Gateway A payment processor is not a one-percent fee. It is a third party that holds your money before you do, learns who your customers are, and can decide on a Tuesday afternoon that your business no longer suits it. Self-hosting removes that party completely: invoices, exchange rates, address generation and order webhooks all run on a server you rent. Here is what it actually takes — the disk it needs, the keys that must never be on it, and the honest limits of what it buys you. [ガイドを読む](#guide-body) [FAQ](#guide-faq) ## このページの内容 - [ガイド](#guide-body) - [FAQ](#guide-faq) - [Related ガイドs](#guide-related) - [推奨 pages](#guide-cta) KYC不要 暗号資産決済のみ ログなし DMCA無視 フルroot NVMe SSD 20 min 読み込み Sep 2026更新 このページの内容 [01What a payment processor actually costs you](#what-a-payment-processor-actually-costs-you) [02What self-hosting gives you — and what it doesn’t](#what-self-hosting-gives-you-and-what-it-doesnt) [03The stack: what BTCPay Server actually is](#the-stack-what-btcpay-server-actually-is) [04Sizing the server: the disk is the whole decision](#sizing-the-server-the-disk-is-the-whole-decision) [05Step 1 — Provision and harden the host](#step-1-provision-and-harden-the-host) [06Step 2 — Install the gateway](#step-2-install-the-gateway) [07Step 3 — Connect a wallet without putting keys on the server](#step-3-connect-a-wallet-without-putting-keys-on-the-server) [08Step 4 — Add Lightning and Monero, if you need them](#step-4-add-lightning-and-monero-if-you-need-them) [09Step 5 — Wire it into your site](#step-5-wire-it-into-your-site) [10Running it: backups, upgrades and the failure modes](#running-it-backups-upgrades-and-the-failure-modes) [11The privacy reality: what the chain still shows](#the-privacy-reality-what-the-chain-still-shows) [12The legal part nobody enjoys](#the-legal-part-nobody-enjoys) [13The whole build, on one page](#the-whole-build-on-one-page) [FAQよくある質問](#guide-faq) [→推奨 pages](#guide-cta) Every business that accepts crypto eventually notices the same contradiction. The whole point of being paid in Bitcoin or Monero is that no institution stands between you and the customer — and yet the ordinary way to accept it is to sign up with a company that takes the payment first, holds it, converts it, verifies you, and forwards what is left. You have swapped a bank for a startup with a shorter memory and a longer list of prohibited businesses. The alternative is not exotic. A self-hosted payment gateway is a piece of open-source software on a server you rent: it generates a fresh address per order, watches the chain for the money, tells your website when the invoice is paid, and never has the authority to move a single coin. It has been production-grade for years. What follows is the whole build — what it removes, what it does not, how to size the machine, and where the sharp edges are. ## What a payment processor actually costs you The fee is the least interesting line item. What you are really buying from a hosted crypto processor is a set of dependencies, and it is worth naming them before deciding they are acceptable. | What the processor takes | Why it matters | | --- | --- | | Custody, for minutes or for days | Between the customer paying and you being paid, the money is theirs. Every insolvency, freeze and exit scam in this industry has happened in that gap | | An account, with identity attached | The processor knows your legal name, your bank, your volume and your customers’ payment patterns. A no-KYC host in front of a KYC checkout is a locked door in a glass wall | | The right to decide what you sell | Acceptable-use policies change without warning and are enforced retroactively. The account that worked last quarter is the account frozen this quarter | | A dependency you cannot inspect | Their downtime is your checkout being down; their rate source is your pricing; their bug is your missing order | | A permanent record of every sale | A subpoena to them produces your entire order book. You will not be told | None of that is an accusation of bad faith. It is simply the shape of an intermediary. If your business is uncontroversial, well capitalised and happy to be identified, an intermediary is a perfectly rational trade — you get refunds, support and someone else’s uptime. The rest of this guide is for everyone whose answer to that trade is no. Payments land on addresses your own server derived, and the company that used to sit in the middle is simply not on the path any more. ## What self-hosting gives you — and what it doesn’t Be precise about the win, because overstating it is how people build the wrong threat model. Self-hosting a gateway changes exactly three things, and leaves several important things untouched. **What genuinely changes.** The money goes straight from the customer to an address only you control, so there is no custodian and no freeze to survive. No third party is told who your customers are or what you sell. And nobody can revoke your ability to take payments, because there is no account to revoke — only software you run. **What does not change.** The Bitcoin blockchain is still a public ledger, and every address your server hands out is still visible forever. Your tax and reporting obligations are exactly what they were. And the moment you convert those coins into your local currency, you meet a regulated exchange that will want your passport — which is why the cash-out, not the checkout, is where most people’s privacy actually ends. **The single best property, stated plainly:** a correctly configured self-hosted gateway holds no private keys. If the server is compromised, seized or simply repossessed, the attacker gets your invoice history and a list of your addresses — not the ability to spend one satoshi. That is a very different disaster from losing a hot wallet, and it is the reason this architecture is worth the effort. ## The stack: what BTCPay Server actually is The de-facto answer is BTCPay Server: free, MIT-licensed, self-hosted, and built after a well-known processor’s policy decisions annoyed enough merchants to produce a replacement. It is not one program but a small stack of containers that come up together, and it helps to know which piece does what before something breaks at two in the morning. - **A Bitcoin node.** Your own copy of the chain. This is what makes the setup trustless — you are not asking anyone else whether you were paid, and no one else learns which addresses you are watching. - **An indexer** that tracks the addresses derived from your wallet and reports what lands on them, so the node itself does not need to hold a wallet. - **The BTCPay application** — the part you actually see. Stores, invoices, exchange rates, a point-of-sale page, payment buttons, crowdfunding pages, refunds, the REST API and the webhooks. - **A database** holding stores, invoices and settings. This is the only irreplaceable state on the machine, which matters enormously when you get to backups. - **A reverse proxy with automatic TLS**, so the checkout is served over HTTPS without you assembling it by hand. - **Optional daemons** — a Lightning node, a Monero node and wallet, other chains — each of which adds real weight to the machine. Add them deliberately, not by default. Deployment is a Docker Compose stack driven by an environment file: you declare which optional pieces you want, run the setup script, and the composition is generated for you. That is a genuine advantage over hand-assembling six services, and it is also the reason the machine wants more disk than you would guess. ## Sizing the server: the disk is the whole decision CPU is almost never the constraint. A gateway that processes a few hundred invoices a day is idle most of the time; the load is the initial block download and then a trickle. Memory matters more, and disk decides everything. Work out which row you are in before you order anything. | Configuration | Disk to plan for | Sensible RAM | Who it is for | | --- | --- | --- | --- | | Pruned Bitcoin node, on-chain only | ~40–60 GB total, including the operating system | 4 GB | Most merchants. The correct default | | Pruned node plus Lightning | ~60–80 GB | 8 GB | Small, frequent payments where fees would otherwise dominate | | Full, unpruned Bitcoin node | ~1 TB, with headroom for years of growth | 8 GB | People who also want the node for other software, or who value having the whole chain | | Adding a Monero node | Add ~120 GB pruned, ~300 GB unpruned | +4 GB | Anyone who wants payments the public ledger does not narrate | | Everything at once, unpruned | 1.5 TB and upwards | 16 GB | Rare, and usually a sign the gateway should be split across two machines | Two details catch people out, and both cost time rather than money. First, **pruning saves disk, not bandwidth**: the node still downloads and verifies the entire chain during the initial sync, then discards the old blocks it no longer needs. Budget several hundred gigabytes of transfer for that first sync regardless of the final footprint — which is exactly why unmetered bandwidth belongs on the requirements list. Second, **NVMe is not a luxury here**. Initial block download is brutally random-access; the same sync that takes a day on NVMe can take a week on spinning disk, and you will spend that week wondering whether it is broken. **Prune first, expand later — the reverse is painful.** Going from a pruned node to a full one means resyncing from genesis. Going from full to pruned is a configuration change and a restart. If you are unsure, start pruned: the gateway behaves identically, and the only thing you lose is the ability to serve historic blocks to other peers. ## Step 1 — Provision and harden the host Order the server before you need it and let the chain sync while you do everything else. A [KVM VPS](https://servhidden.com/ja/vps) with full root is the right shape: you need kernel-level control for Docker, and you want the machine to be yours rather than a container on someone’s shared platform. Pay for it the same way you intend to be paid — our walkthrough of [buying a VPS with Bitcoin](https://servhidden.com/ja/guides/how-to-buy-a-vps-with-bitcoin) covers that end, and the [jurisdiction guide](https://servhidden.com/ja/guides/choosing-an-offshore-jurisdiction) covers where to put it. Harden it while it is still empty, because it will not be empty for long and this machine is, by design, a public advertisement that money passes through it. Keys-only SSH, no password authentication, a default-deny firewall with only 22, 80 and 443 open, unattended security upgrades, and the SSH port itself restricted to addresses you control if you can manage that. The [first-hour hardening checklist](https://servhidden.com/ja/guides/first-hour-vps-hardening-checklist) is precisely this list, and doing it before the gateway exists takes twenty minutes rather than an afternoon. Point a hostname at the machine before you install — the setup script wants a domain so it can request a certificate on first boot. A dedicated subdomain is fine and is what most people use. Bear in mind that this hostname becomes part of your public checkout, so it will appear in Certificate Transparency logs the moment the certificate is issued, permanently and searchably. Choose a name you are content to have indexed forever, and if the association between that name and your main site is itself sensitive, read our note on [what a hostname reveals](https://servhidden.com/ja/guides/hiding-your-origin-server-ip) before you pick one. ## Step 2 — Install the gateway Installation is deliberately boring: clone the deployment repository, export a handful of environment variables describing what you want, and run the setup script. The variables that matter are the host name, the chains you want, and the optional fragments — which Lightning implementation, whether to prune, whether to add other daemons. There is a full-featured web installer too, but the environment-variable route is the one you can reproduce from your notes six months later, and reproducibility is worth more than convenience here. What happens next is a wait. The stack comes up in a couple of minutes; the Bitcoin node then spends anywhere from several hours to a couple of days catching up with the chain, and BTCPay will honestly tell you it is still syncing rather than pretending to work. Do not create invoices during this window and do not judge anything by it. Use the time productively: create your admin account and turn on two-factor authentication immediately, because this interface is the control panel for your revenue and it is reachable from the entire internet. Two settings deserve attention while you wait. Set the **invoice expiry** to something that respects real-world confirmation times — the default is a quarter of an hour, which is fine for Lightning and tight for an on-chain payment during a fee spike. And set the **payment tolerance**, which decides whether an invoice that arrives a few cents short is settled or left hanging. Zero tolerance generates support tickets; a small percentage generates none. That single field prevents more customer emails than any other. ## Step 3 — Connect a wallet without putting keys on the server This is the step that determines whether self-hosting was worth doing, and it is the one most often got wrong in a hurry. BTCPay can generate a wallet for you, on the server, with the private keys on the server. Do not do this for a store that takes real money. The correct approach is to create the wallet elsewhere — a hardware wallet, or a desktop wallet on a machine that is not this one — and give the server only the extended public key, the xpub. That single string lets the gateway derive an unlimited sequence of receiving addresses and watch them, while remaining mathematically incapable of spending anything. Your keys stay where you put them; the server becomes a very well-informed observer. Once connected, verify it rather than assuming. Create a one-cent invoice, pay it from a wallet you control, and confirm three things: the address appears in the wallet you own, the invoice settles in BTCPay, and the funds are visible and spendable from your own wallet software rather than only in the gateway interface. That three-way check is how you discover a wrong derivation path in five minutes instead of after your first real customer. **Do not spend from that account with a second wallet.** The indexer watches a limited window of unused addresses ahead of the last one it saw used. If another wallet quietly consumes addresses from the same account, the gateway can be looking at the wrong part of the sequence and miss a payment that did arrive. Keep the store’s account for the store, and if you need a hot balance for refunds or payouts, use a separate wallet with a small float rather than compromising the main one. ## Step 4 — Add Lightning and Monero, if you need them Both are worth having and neither is free, so add them because a customer asked, not because the checkbox exists. **Lightning** makes small payments viable — instant, effectively free, and immune to the fee spikes that make a four-dollar on-chain invoice absurd. The catch is not the software, which the stack installs for you; it is inbound liquidity. You can only be paid what your channels have room to receive, so a freshly launched node with no inbound capacity cannot accept anything at all until you open channels, buy inbound capacity or use a liquidity service. Budget an afternoon and some capital. And treat the node’s backups as a separate problem from everything else on the box: Lightning channel state is live state, a restore from an old snapshot can cost you the channel balance, and the recovery file that protects you must be kept current and off the machine. **Monero** is the opposite trade: no channels, no liquidity, no routing — just a second blockchain and its daemon, and payments that the public ledger does not narrate to anyone watching. BTCPay supports it through a plugin backed by your own Monero node and a view-only wallet, which is the same principle as the xpub: you hand the server the address and the private *view* key so it can see incoming payments, and keep the spend key elsewhere. Two operational facts to plan around: Monero funds require ten confirmations before they are spendable, roughly twenty minutes, so your invoice expiry and your order-fulfilment logic must tolerate that; and the daemon adds substantial disk. If you are weighing which coins to offer at all, our comparison of [Monero, Bitcoin and USDT](https://servhidden.com/ja/guides/crypto-payments-monero-vs-bitcoin-vs-usdt) is the shorter path to a decision. ## Step 5 — Wire it into your site The gateway is useless until your application knows an invoice was paid. There are three integration routes, in ascending order of effort and control. - **A plugin,** if you run one of the common e-commerce platforms. Install it, paste an API key, done in an afternoon. This covers the majority of real deployments and there is no prize for avoiding it. - **Payment buttons or a hosted checkout page,** if you sell a handful of things or take donations. Copy an HTML snippet, and BTCPay handles the entire payment flow on its own domain. - **The REST API,** if you have a custom application. Create invoices programmatically, receive webhooks when they change state, and control the whole experience. Whichever route you take, the rule for fulfilment is the same and it is not negotiable: **never ship on the basis of a webhook you have not verified.** Webhooks are signed with a shared secret — check the signature on every request, and then call back to the API to confirm the invoice really is in the state the webhook claims. An unauthenticated endpoint that marks orders paid is a free-goods generator, and it will be found by someone with a scanner long before it is found by you. Then decide what “paid” means for your business. Settling on an unconfirmed transaction is instant and exposes you to replacement; waiting for one confirmation costs the customer ten minutes on average and removes almost all of that risk. Digital goods delivered instantly deserve a confirmation. A physical item shipped tomorrow does not — the parcel will not move before the block does. ## Running it: backups, upgrades and the failure modes A payment gateway is infrastructure, and infrastructure is judged on the bad day rather than the good one. Three habits cover almost every way this goes wrong. **Back up the right things.** The blockchain is not one of them — it is several hundred gigabytes that the internet will happily send you again. What is irreplaceable is the database of stores, invoices and settings, the configuration, and any Lightning material. The deployment ships a backup script that captures exactly this; the discipline is to run it on a schedule, ship the result somewhere else, encrypt it before it leaves, and restore it once to prove it works. An [off-site encrypted backup](https://servhidden.com/ja/guides/vps-backup-strategy) is the same pattern as everywhere else on this site, and here the archive is a full record of your revenue — so the encryption is not optional. **Upgrade on purpose.** The stack has an update script and it is well behaved, but a gateway that updates itself unattended is a gateway that can be down while you sleep. Read the release notes, take a database backup first, and update at a quiet hour. Never during a promotion. **Know what an outage actually costs.** This is the reassuring part. If the gateway is down, new customers cannot generate invoices — an availability problem, and a real one. But money already sent to your addresses is not lost, delayed or at risk: it is sitting in a wallet whose keys were never on the machine, and it will be there when the node comes back and rescans. Downtime costs you sales, not funds. That distinction is worth internalising, because it turns a three-in-the-morning emergency into something that can wait until breakfast. ## The privacy reality: what the chain still shows Removing the processor removes the processor. It does not make Bitcoin private, and a self-hosted gateway can quietly make your on-chain privacy worse if you are not paying attention. | What leaks | Why | What to do about it | | --- | --- | --- | | Your entire revenue history, to anyone holding the xpub | One extended public key derives every address your store will ever use | Treat the xpub as a business secret. Never paste it into a block explorer or a support ticket | | Which customers paid you, linked together | Consolidating many invoice payments into one transaction proves the same entity received all of them | Consolidate rarely, in large batches, at quiet times — or not at all | | The link between your checkout and your main site | Certificate Transparency, DNS records and the page that embeds the payment form | Assume the association is public. If it must not be, that constraint belongs in the design, not in a later patch | | Your own admin sessions | Server access logs record who administers the machine and from where | Never touch the gateway from an address that identifies you. Our [server OpSec guide](https://servhidden.com/ja/guides/server-opsec-staying-anonymous) is the long version | | Everything, eventually, at the exchange | Conversion to fiat is the regulated chokepoint, and it sees the coins’ history | Nothing technical fixes this. Plan for it, or accept payment in something the ledger does not publish | Two mitigations are worth the effort and are built in. Turning on a payjoin-style collaborative payment breaks the naive assumption that all the inputs of a transaction belong to one person, which is the single most useful heuristic chain analysts rely on. And offering Monero alongside Bitcoin means the customers who care most simply never write anything to a public ledger in the first place. Neither is a magic trick; both raise the cost of watching you. ## The legal part nobody enjoys Short version, and not legal advice: running the software is not the regulated act. What you do with the money can be. In most jurisdictions, accepting crypto as payment for your own goods and services is an ordinary commercial transaction. You are a merchant being paid, not a financial institution. The obligations that follow are the ones you already have: recognise the revenue at its value on the day you received it, apply the same sales tax or VAT you would have applied to a card payment, and keep records that survive an audit. A self-hosted gateway makes that easier rather than harder, because the invoice history is yours and complete. Where the line moves is when you start handling money for other people. Converting, transmitting or holding crypto on behalf of third parties is a licensed activity almost everywhere, and “but I self-host it” is not a defence. Sanctions obligations also survive the change of architecture entirely. And accepting payment without KYC is a very different question from accepting payment you know to be criminal — the first is legal in most of the world, the second is not, anywhere. Our guide on whether [offshore hosting is legal](https://servhidden.com/ja/guides/is-offshore-hosting-legal) works through the same distinction in more depth. ## The whole build, on one page Stripped of the reasoning, this is a weekend project of which most is waiting: - **Decide the shape:** pruned or full node, Lightning or not, Monero or not. This sets the disk, and the disk sets the plan. - **Order the server** — NVMe, unmetered bandwidth, full root — and pay for it in the currency you intend to accept. - **Harden it while it is empty,** then point a hostname at it and let the certificate issue. - **Deploy the stack** from the environment file, then wait for the node to sync. Do not judge anything during the sync. - **Create the wallet elsewhere** and give the server only the extended public key. Verify with a one-cent invoice before anything else. - **Add Lightning or Monero** only if a customer will use them, and budget the liquidity or the disk accordingly. - **Integrate** by plugin, button or API — and verify every webhook signature against the API before you ship a single order. - **Schedule the backup,** encrypt it, send it off the machine, and restore it once so you know it works. What you end up with is unglamorous and quietly significant: a checkout with no company in it. The money arrives at addresses only you can spend from, no account can be closed because there is no account, and the cost of the whole arrangement is one small server. If you want the same independence for the machine underneath it, that is what [hosting paid for in Bitcoin](https://servhidden.com/ja/bitcoin-hosting) exists for — and the two decisions are, satisfyingly, the same decision made twice. FAQ ## Self-hosted crypto payments — common questions ### 01 Do I need a full Bitcoin node to run my own gateway? You need a node, but it does not have to be a full one. A pruned node verifies every block exactly as a full node does and then discards the old ones it no longer needs, which brings the storage requirement down from around a terabyte to roughly the size of a small VPS disk. Your gateway behaves identically — the only thing you give up is the ability to serve historic blocks to other peers. What you cannot skip is the node itself: without it you are asking a third party whether you were paid, which is the dependency you set out to remove. ### 02 How much disk does a self-hosted payment gateway really need? For the common case — a pruned Bitcoin node, on-chain payments only — plan on roughly 40 to 60 GB including the operating system, and 4 GB of RAM. Add Lightning and you want a little more disk and about 8 GB of memory. Add a Monero node and you are adding another 120 GB pruned or around 300 GB unpruned. An unpruned Bitcoin node alone wants a terabyte with room to grow. Pruning saves disk but not bandwidth: the first sync downloads and verifies the entire chain regardless, which is why unmetered transfer belongs on the requirements list. ### 03 If someone hacks or seizes the server, do they get my money? Not if you set it up correctly. A properly configured gateway holds no private keys — you give it only an extended public key, which lets it derive and watch addresses but makes spending mathematically impossible. An attacker with full control of the machine gets your invoice history, your customer order data and your list of addresses, which is a serious privacy breach and worth defending against. What they cannot do is move your funds. The exception is any hot wallet you deliberately fund for refunds or Lightning; keep that balance small, because that part genuinely is at risk. ### 04 Can I accept Monero with a self-hosted gateway? Yes, through a plugin backed by your own Monero daemon and a view-only wallet. You give the server the address and the private view key so it can see payments arrive, and the spend key never touches the machine — the same principle as the extended public key on the Bitcoin side. Two things to plan for: the daemon needs its own disk, roughly 120 GB pruned, and Monero funds require ten confirmations before they can be spent, about twenty minutes. Set your invoice expiry and your order-fulfilment logic to tolerate that delay rather than fighting it. ### 05 Does self-hosting mean I avoid KYC completely? It removes KYC from the checkout, which is the part that touches your customers. It does not remove it from the cash-out. The moment you convert crypto into your local currency through a regulated exchange, you meet identity verification, and the exchange can see the history of the coins you deposit. For most businesses this is a good trade rather than a solved problem: your customers pay without being profiled by a third party, your order book is not sitting on someone else’s server, and the identified step happens once, at your own bank, on your own schedule. ### 06 What happens to payments if my gateway goes down? New customers cannot generate an invoice, so you lose sales while it is down — that part is a genuine availability problem. But money already sent to your addresses is entirely unaffected. Those funds sit in a wallet whose keys were never on the server, and when the node comes back it rescans the chain and reconciles the payments it missed. Downtime costs you revenue you did not capture, not funds you already had. That is worth knowing at three in the morning, because it turns an emergency into something that can wait for daylight. ### 07 Do I need Lightning, or is on-chain enough? On-chain is enough for most merchants, and it is far less work. Lightning earns its keep when your average order is small enough that on-chain fees become absurd — selling anything for a few dollars, or taking micro-donations. The real cost is not the software but inbound liquidity: a new node cannot receive anything until it has channels with capacity pointed at it, which means opening channels, buying inbound capacity or using a liquidity provider. Start on-chain, watch your fee-to-order ratio, and add Lightning when the numbers justify the afternoon. ### 08 Is running my own crypto payment gateway legal? Running the software is not itself a regulated activity, and in most jurisdictions accepting crypto for your own goods and services is an ordinary commercial transaction — you are a merchant being paid, not a financial institution. The usual obligations still apply in full: recognise the revenue at the value on the day it arrived, charge the sales tax or VAT you would have charged on a card payment, and keep records. The line moves when you handle money for other people; converting, transmitting or holding crypto on behalf of third parties is licensed almost everywhere, and self-hosting is not a defence. This is general information, not legal advice — check your own jurisdiction. Related ガイドs ## 続けて読む [### 2026年にオフショアホスティング法域を選ぶ方法 購入 オフショア法域を選ぶための実践的な意思決定フレームワーク: データ保持法、MLATの露出、DMCA対応姿勢、裁判所のスピード、実際の執行状況を国ごとに解説します。 6の質問からなるFAQ](https://servhidden.com/ja/guides/choosing-an-offshore-jurisdiction) [### プライバシーが重要なワークロード向けのVPS vs 専用サーバー 購入 VPSで十分な場合、共有テナンシーが弱点になる場合、そしてベアメタルだけが誠実な答えになる場合を解説します。ハードウェア分離、ハイパーバイザーのリスク、コストと脅威モデルの比較について。 6の質問からなるFAQ](https://servhidden.com/ja/guides/vps-vs-dedicated-for-privacy) [### No-KYC VPS上のセルフホストVPN: WireGuard vs OpenVPN 運用 セルフホストVPNが商用プロバイダーより優れている理由、そして2026年時点でWireGuardとOpenVPNがプライバシー、性能、運用リスクの面で実際にどう比較されるかを解説します。 6の質問からなるFAQ](https://servhidden.com/ja/guides/self-hosted-vpn-wireguard-vs-openvpn) [### AI推論向けRTX 4090 vs H100 SXM5比較（RTX 5090はどこに位置するか） 購入 購入ガイド：2026年、セルフホストのLLM、画像、動画、音声、ファインチューニングのワークロードにはどのNVIDIA GPUを選ぶべきか。RTX 4090 vs RTX 5090 vs H100 SXM5 vs デュアルH100——VRAM、スループット、$/トークン、それぞれが優位になる場面を比較します。 6の質問からなるFAQ](https://servhidden.com/ja/guides/rtx-4090-vs-h100-for-ai-inference) [### MT4 / MT5 / cTrader Forexトレード向けのオフショアWindows RDP 運用 完全ガイド：Forex取引にWindows RDPを使う理由、低遅延なオフショア法域の選び方、MT4 / MT5 / cTrader / Expert Advisorのセットアップ方法、ブローカーサーバーへの遅延、そしてKYC不要の決済フローまで解説します。 6の質問からなるFAQ](https://servhidden.com/ja/guides/offshore-windows-rdp-for-forex-trading) [### DMCA無視ホスティング解説：2026年における本当の意味 購入 「DMCA無視」ホスティングが実際に何をもたらすのか、どの法域が本当に支持しているのか、それを必要とするワークロードとは何か、そしてその言葉がカバーしない著作権の落とし穴とは何か。 6の質問からなるFAQ](https://servhidden.com/ja/guides/dmca-ignored-hosting-explained) [### 暗号通貨による匿名ドメイン登録：2026年のWHOISプライバシー プライバシー 身元を明かさずにドメインを登録するための2026年実践ガイド：TLD別WHOISの仕組み、レジストラの選択、暗号支払いオプション、そしてそれでも身元が漏れる運用上のミス。 6の質問からなるFAQ](https://servhidden.com/ja/guides/anonymous-domain-registration-with-crypto) [### 暗号資産決済向けホスティング: Monero vs Bitcoin vs USDT プライバシー 支払いに使うコインによって、ホストに知られる情報がどう変わるかを解説します。XMR、BTC、USDTそれぞれのプライバシー、手数料、ファイナリティ、チェーン分析への露出を比較し、明確な結論を提示します。 6の質問からなるFAQ](https://servhidden.com/ja/guides/crypto-payments-monero-vs-bitcoin-vs-usdt) [### オフショアホスティングは本当に匿名なのか?正直な答え プライバシー オフショアのKYC不要ホスティングは、通常のホスティング業者が収集する身元情報を排除します——しかし「匿名」かどうかは、支払い方法、業者側のログ、そしてあなた自身のOPSEC次第です。実際に何が追跡可能なのかを解説します。 6の質問からなるFAQ](https://servhidden.com/ja/guides/is-offshore-hosting-truly-anonymous) [### VPSハードニングの最初の1時間:チェックリスト 運用 新しいVPSを1時間以内に守るための、具体的で順序立ったチェックリスト。SSHキー、ファイアウォール、fail2ban、自動アップデート、そして無差別攻撃の大半を食い止める攻撃対象領域の削減。 6の質問からなるFAQ](https://servhidden.com/ja/guides/first-hour-vps-hardening-checklist) [### No-KYCホスティングとは？定義・合法性・仕組みを解説 プライバシー No-KYCホスティングは、氏名・メールアドレス・身分証明書など一切の本人確認なしでサーバーを借りられるサービスです。その意味、技術的な仕組み、合法性、そして本物のプロバイダーの見分け方を詳しく解説します。 6の質問からなるFAQ](https://servhidden.com/ja/guides/what-is-no-kyc-hosting) [### オフショアホスティングは合法か？2026年版・正直な回答 購入 オフショアホスティングは合法です――利用者にとっても、プロバイダーにとっても。この記事では、その用語の本当の意味、法的境界線の実態、払拭すべき誤解、そして責任ある活用方法を解説します。 6の質問からなるFAQ](https://servhidden.com/ja/guides/is-offshore-hosting-legal) [### Monero（XMR）でホスティングを支払う方法 — ステップバイステップ プライバシー Monero（XMR）でVPSや専用サーバーの料金を支払うためのステップバイステップガイド：XMRがプライバシー保護の観点から最も優れた選択肢である理由、入手方法、そしてチェックアウトから数分でサーバーが稼働するまでの流れを解説します。 6の質問からなるFAQ](https://servhidden.com/ja/guides/how-to-pay-for-hosting-with-monero) [### ウェブサイトを匿名でホスティングする方法 — 2026年版実践ガイド プライバシー アカウント、支払い、ドメイン、管轄地域、接続、コンテンツ — 身元を一切残さずウェブサイトをホスティングするための、層ごとに解説した実践的ガイド。 6の質問からなるFAQ](https://servhidden.com/ja/guides/how-to-host-a-website-anonymously) [### VPSにWireGuard VPNを構築する — ステップバイステップガイド 運用 WireGuardを使ってVPS上に自分専用のプライベートVPNを構築する方法：セルフホスト型VPNが商用VPNより優れている理由から、インストールからクライアント接続まで完全なセットアップ手順、そして堅牢化の方法まで解説します。 6の質問からなるFAQ](https://servhidden.com/ja/guides/how-to-set-up-wireguard-vpn-on-a-vps) [### GPUサーバーでLLMをセルフホストする方法 — 2026年版ガイド 運用 レンタルGPUサーバーで独自の大規模言語モデルを稼働させる：APIより自己ホスティングが優れている理由、GPUとモデルの選び方、OllamaまたはvLLMを使ったセットアップ、そしてコストについて。 6の質問からなるFAQ](https://servhidden.com/ja/guides/self-host-an-llm-on-a-gpu-server) [### バレットプルーフホスティングとオフショアホスティング — その違いとは？ 購入 バレットプルーフホスティングとオフショアホスティングは混同されがちですが、まったく別物です。両者の本質的な違い、その重要性、そして実際にどちらを選ぶべきかを解説します。 6の質問からなるFAQ](https://servhidden.com/ja/guides/bulletproof-vs-offshore-hosting) [### BitcoinでVPSを購入する方法――ステップバイステップ完全ガイド（2026年版） 購入 BitcoinでVPSを購入するための初心者向けガイド。BTCの入手方法、プランの選び方、請求書の支払い方、そして手に入るものが何か――カードも氏名も不要なサーバーを手順を追って解説します。 6の質問からなるFAQ](https://servhidden.com/ja/guides/how-to-buy-a-vps-with-bitcoin) [### DMCAを無視できるホスティングに最適な国（2026年版） 購入 米国式の削除申請が届かないサーバーをどこに置くか——機能する法域、「DMCA無視」が本当に意味すること、そして選び方。 6の質問からなるFAQ](https://servhidden.com/ja/guides/best-countries-for-dmca-ignored-hosting) [### Torの隠しサービス（.onionサイト）のホスティング方法 — 2026年版ガイド 運用 VPS上にTor onionサービスを構築する：隠しサービスとは何か、それが最も強力な匿名ホスティング形態である理由、完全な設定手順、そして真の匿名性を維持する方法。 6の質問からなるFAQ](https://servhidden.com/ja/guides/how-to-host-a-tor-hidden-service) [### オフショアメールサーバーの構築 — 2026年版・プライベートメールを自己ホスト 運用 オフショアVPS上でプライベートメールサーバーを自己ホストする方法：なぜ自己ホストするのか、何が必要か、オールインワンメールスタックによる現実的な構築手順、そして配信可能性を正しく確保する方法。 6の質問からなるFAQ](https://servhidden.com/ja/guides/offshore-mail-server-setup) [### 暗号ノードホスティングガイド — VPS でブロックチェーンノードを運用する 運用 ブロックチェーンノードをサーバー上でホストする方法：自前のノードを運用する理由、Bitcoin・Ethereum・Monero などに適したサーバー構成、セットアップ手順、そしてプライバシーを守りながら運用する方法。 6の質問からなるFAQ](https://servhidden.com/ja/guides/crypto-node-hosting-guide) [### Stable Diffusion 向け GPU ホスティング — 自分だけの画像生成サーバーを運用する 運用 GPU サーバーで Stable Diffusion を自己ホストする方法：セルフホスティングの理由、最適な GPU の選び方、Web UI のセットアップ、そしてホスト型サービスとのコスト比較。 6の質問からなるFAQ](https://servhidden.com/ja/guides/gpu-hosting-for-stable-diffusion) [### サーバーOpSec — サーバー運用時に匿名性を維持する方法 プライバシー 匿名サーバーを運用するすべての人のための運用セキュリティ：身元が特定されてしまう失敗のパターン、それを防ぐ習慣、そして真に独立したアイデンティティを保ち続ける方法。 6の質問からなるFAQ](https://servhidden.com/ja/guides/server-opsec-staying-anonymous) [### シードボックス設定ガイド — 2026年版プライベートシードボックスの自己構築 運用 サーバー上に自分だけのシードボックスを構築する方法：シードボックスとは何か、サイジングの考え方、WebUI付きトレントクライアントのインストール、そしてプライベートかつ安全に保つための手順。 6の質問からなるFAQ](https://servhidden.com/ja/guides/seedbox-setup-guide) [### 自前のVPSでDPI検閲を回避する方法(2026年版ガイド) プライバシー VPNが突然つながらなくなった?自前のVPSでDPI検閲を回避する方法を解説する。ディープパケットインスペクション(DPI)が実際に何を検知しているのか、2026年時点で有効な5つのプロトコルがそれぞれどのブロック手法に強いのか、そしてVLESS+REALITYの導入手順をひと通り示す。 6の質問からなるFAQ](https://servhidden.com/ja/guides/bypass-dpi-censorship-with-your-own-vps) [### VPSのフルディスク暗号化：LUKS導入と本当に守れるもの 運用 VPSをLUKSで暗号化する方法を解説します。暗号化データボリューム、dropbearによるSSH経由リモートロック解除を伴うフルルート暗号化、インストール時に暗号化するベアメタルという3つの構成、小規模サーバーで本当に重要になる設定、そしてディスク暗号化が実際に何を防ぎ、何を防がないのかを正直に説明します。 8の質問からなるFAQ](https://servhidden.com/ja/guides/full-disk-encryption-on-a-vps) [### オリジンサーバーIPを隠す：CDN・リバースプロキシと漏れる経路 プライバシー オフショアサーバーの前にCDNやリバースプロキシを置くべきかどうかを解説します。CDNが実際に何を隠してくれるのか、その代わりに背負うことになる苦情処理の窓口、そして設定を誤るとオリジンサーバーのIPアドレスが漏れてしまう6つの経路と、自分のIPアドレスを10分で監査する具体的な手順までを正直に述べます。 8の質問からなるFAQ](https://servhidden.com/ja/guides/hiding-your-origin-server-ip) [### VPSバックアップ完全ガイド：暗号化・オフサイト・復元検証 運用 ホスティング業者はバックアップを保持しません。サーバーを壊す本当の原因、restic対BorgBackupの選び方、忘れがちな鍵、復元テストの手順まで解説します。 8の質問からなるFAQ](https://servhidden.com/ja/guides/vps-backup-strategy) [### Matrixサーバーのセルフホスト:Synapseと連合の実態 運用 Matrixホームサーバーで本当に変わることとは。Synapse・Conduitの違い、変更不可能なserver_name、肥大化するメディア保存、連合が明かす情報を解説します。 8の質問からなるFAQ](https://servhidden.com/ja/guides/self-host-a-matrix-server) [### サイトをオフショアホスティングへダウンタイムゼロで移行する方法 運用 ホスト移行を退屈な作業に変える順序をご紹介します。DNSのTTLを数日前に下げ、2台のサーバーを並行稼働させて書き込みフリーズを時間ではなく分に抑え、さらに移行が残すパッシブDNSやCertificate Transparency、WHOISの痕跡を消す方法まで解説します。 8の質問からなるFAQ](https://servhidden.com/ja/guides/migrate-website-to-offshore-hosting) ## Put the gateway somewhere it can stay up Offshore KVM servers in seven jurisdictions from $7.50/mo, with full root, NVMe storage and unmetered bandwidth, deployed in under five minutes once a crypto payment confirms. The larger plans carry the disk a full node wants; the smaller ones are more than enough for a pruned one. [VPSプランを見る](https://servhidden.com/ja/vps) [Bitcoin ホスティング](https://servhidden.com/ja/bitcoin-hosting) [オフショアホスティング](https://servhidden.com/ja/offshore-hosting) ## Structured data (JSON-LD) ```json { "@context": "https://schema.org", "@type": "Organization", "@id": "https://servhidden.com/#organization", "name": "ServHidden", "url": "https://servhidden.com", "description": "7つのオフショア法域で提供するVPSと専用サーバー。KYC不要、ログなし、暗号資産決済のみ。設計段階からプライバシーを重視しています。", "logo": { "@type": "ImageObject", "url": "https://servhidden.com/ServHidden.webp", "width": 512, "height": 512 }, "foundingDate": "2025", "areaServed": [ { "@type": "Country", "name": "Iceland" }, { "@type": "Country", "name": "Panama" }, { "@type": "Country", "name": "Moldova" }, { "@type": "Country", "name": "Romania" }, { "@type": "Country", "name": "Switzerland" }, { "@type": "Country", "name": "Netherlands" }, { "@type": "Country", "name": "Russia" } ], "knowsAbout": [ "Offshore hosting", "Offshore VPS", "Bare-metal dedicated servers", "DMCA-ignored hosting", "No KYC hosting", "Cryptocurrency payments", "Privacy engineering", "Token-based authentication", "Anonymous domain name registration", "No-KYC domain registrar", "WHOIS privacy", "Cheap .com domains", "Crypto-paid domain names", "NVIDIA GPU compute", "Windows RDP hosting", "Agentic commerce" ], "contactPoint": { "@type": "ContactPoint", "contactType": "customer support", "url": "https://servhidden.com/contact", "availableLanguage": [ "en", "ru", "zh", "es", "fr", "de", "pt", "ar", "ja", "ko", "hi", "id", "it", "tr", "fa", "vi" ] }, "sameAs": [ "https://servhidden.com/canary", "https://servhidden.com/press" ] } ``` ```json { "@context": "https://schema.org", "@type": "WebSite", "@id": "https://servhidden.com/#website", "url": "https://servhidden.com", "name": "ServHidden", "publisher": { "@id": "https://servhidden.com/#organization" }, "inLanguage": [ "en", "ru", "zh", "es", "fr", "de", "pt", "ar", "ja", "ko", "hi", "id", "it", "tr", "fa", "vi" ] } ``` ```json { "@context": "https://schema.org", "@type": "Article", "headline": "How to Self-Host a Crypto Payment Gateway with BTCPay Server", "description": "Run your own non-custodial checkout on an offshore VPS: BTCPay Server, a pruned Bitcoin node, Lightning and Monero — how to size the disk, why the private keys must never touch the machine, and where KYC quietly reappears at the cash-out.", "image": "https://servhidden.com/assets/img/guides/self-host-a-crypto-payment-gateway.webp?v=1788358001", "author": { "@type": "Organization", "@id": "https://servhidden.com/#editorial", "name": "ServHidden Editorial", "url": "https://servhidden.com/about", "description": "Operator-side editorial team writing about offshore hosting jurisdictions, offshore server architecture, self-hosted privacy stacks and crypto payments.", "knowsAbout": [ "Offshore hosting jurisdictions", "Data retention law", "MLAT and judicial cooperation", "WireGuard and OpenVPN deployment", "Tor relay operation", "Monero and Bitcoin payment privacy", "KVM virtualization and bare-metal hosting", "DMCA-ignored hosting" ], "parentOrganization": { "@id": "https://servhidden.com/#organization" } }, "publisher": { "@id": "https://servhidden.com/#organization" }, "datePublished": "2026-09-02T00:00:00+00:00", "dateModified": "2026-09-02T00:00:00+00:00", "mainEntityOfPage": "https://servhidden.com/guides/self-host-a-crypto-payment-gateway", "inLanguage": "ja", "keywords": "self-hosted crypto payment gateway, BTCPay Server setup, accept bitcoin payments without KYC, non-custodial payment processor, accept Monero payments, crypto payment gateway VPS, BTCPay Server requirements, self-hosted bitcoin checkout", "articleSection": "運用", "wordCount": 3975 } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Do I need a full Bitcoin node to run my own gateway?", "acceptedAnswer": { "@type": "Answer", "text": "You need a node, but it does not have to be a full one. A pruned node verifies every block exactly as a full node does and then discards the old ones it no longer needs, which brings the storage requirement down from around a terabyte to roughly the size of a small VPS disk. Your gateway behaves identically — the only thing you give up is the ability to serve historic blocks to other peers. What you cannot skip is the node itself: without it you are asking a third party whether you were paid, which is the dependency you set out to remove." } }, { "@type": "Question", "name": "How much disk does a self-hosted payment gateway really need?", "acceptedAnswer": { "@type": "Answer", "text": "For the common case — a pruned Bitcoin node, on-chain payments only — plan on roughly 40 to 60 GB including the operating system, and 4 GB of RAM. Add Lightning and you want a little more disk and about 8 GB of memory. Add a Monero node and you are adding another 120 GB pruned or around 300 GB unpruned. An unpruned Bitcoin node alone wants a terabyte with room to grow. Pruning saves disk but not bandwidth: the first sync downloads and verifies the entire chain regardless, which is why unmetered transfer belongs on the requirements list." } }, { "@type": "Question", "name": "If someone hacks or seizes the server, do they get my money?", "acceptedAnswer": { "@type": "Answer", "text": "Not if you set it up correctly. A properly configured gateway holds no private keys — you give it only an extended public key, which lets it derive and watch addresses but makes spending mathematically impossible. An attacker with full control of the machine gets your invoice history, your customer order data and your list of addresses, which is a serious privacy breach and worth defending against. What they cannot do is move your funds. The exception is any hot wallet you deliberately fund for refunds or Lightning; keep that balance small, because that part genuinely is at risk." } }, { "@type": "Question", "name": "Can I accept Monero with a self-hosted gateway?", "acceptedAnswer": { "@type": "Answer", "text": "Yes, through a plugin backed by your own Monero daemon and a view-only wallet. You give the server the address and the private view key so it can see payments arrive, and the spend key never touches the machine — the same principle as the extended public key on the Bitcoin side. Two things to plan for: the daemon needs its own disk, roughly 120 GB pruned, and Monero funds require ten confirmations before they can be spent, about twenty minutes. Set your invoice expiry and your order-fulfilment logic to tolerate that delay rather than fighting it." } }, { "@type": "Question", "name": "Does self-hosting mean I avoid KYC completely?", "acceptedAnswer": { "@type": "Answer", "text": "It removes KYC from the checkout, which is the part that touches your customers. It does not remove it from the cash-out. The moment you convert crypto into your local currency through a regulated exchange, you meet identity verification, and the exchange can see the history of the coins you deposit. For most businesses this is a good trade rather than a solved problem: your customers pay without being profiled by a third party, your order book is not sitting on someone else’s server, and the identified step happens once, at your own bank, on your own schedule." } }, { "@type": "Question", "name": "What happens to payments if my gateway goes down?", "acceptedAnswer": { "@type": "Answer", "text": "New customers cannot generate an invoice, so you lose sales while it is down — that part is a genuine availability problem. But money already sent to your addresses is entirely unaffected. Those funds sit in a wallet whose keys were never on the server, and when the node comes back it rescans the chain and reconciles the payments it missed. Downtime costs you revenue you did not capture, not funds you already had. That is worth knowing at three in the morning, because it turns an emergency into something that can wait for daylight." } }, { "@type": "Question", "name": "Do I need Lightning, or is on-chain enough?", "acceptedAnswer": { "@type": "Answer", "text": "On-chain is enough for most merchants, and it is far less work. Lightning earns its keep when your average order is small enough that on-chain fees become absurd — selling anything for a few dollars, or taking micro-donations. The real cost is not the software but inbound liquidity: a new node cannot receive anything until it has channels with capacity pointed at it, which means opening channels, buying inbound capacity or using a liquidity provider. Start on-chain, watch your fee-to-order ratio, and add Lightning when the numbers justify the afternoon." } }, { "@type": "Question", "name": "Is running my own crypto payment gateway legal?", "acceptedAnswer": { "@type": "Answer", "text": "Running the software is not itself a regulated activity, and in most jurisdictions accepting crypto for your own goods and services is an ordinary commercial transaction — you are a merchant being paid, not a financial institution. The usual obligations still apply in full: recognise the revenue at the value on the day it arrived, charge the sales tax or VAT you would have charged on a card payment, and keep records. The line moves when you handle money for other people; converting, transmitting or holding crypto on behalf of third parties is licensed almost everywhere, and self-hosting is not a defence. This is general information, not legal advice — check your own jurisdiction." } } ] } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "ホーム", "item": "https://servhidden.com/ja/" }, { "@type": "ListItem", "position": 2, "name": "プライバシーホスティングガイド", "item": "https://servhidden.com/ja/guides" }, { "@type": "ListItem", "position": 3, "name": "How to Self-Host a Crypto Payment Gateway with BTCPay Server", "item": "https://servhidden.com/ja/guides/self-host-a-crypto-payment-gateway" } ] } ``` ```json { "@context": "https://schema.org", "@type": "HowTo", "name": "Self-Host a Crypto Payment Gateway", "description": "Run your own non-custodial checkout on an offshore VPS: BTCPay Server, a pruned Bitcoin node, Lightning and Monero — how to size the disk, why the private keys must never touch the machine, and where KYC quietly reappears at the cash-out.", "image": "https://servhidden.com/assets/img/guides/self-host-a-crypto-payment-gateway.webp?v=1788358001", "inLanguage": "ja", "totalTime": "PT1H", "step": [ { "@type": "HowToStep", "position": 1, "name": "What a payment processor actually costs you", "text": "The fee is the least interesting line item. What you are really buying from a hosted crypto processor is a set of dependencies, and it is worth naming them before deciding they are acceptable. What the processor takesWhy it matters Custody, for minutes or for daysBetween the customer paying and y…", "url": "https://servhidden.com/guides/self-host-a-crypto-payment-gateway#what-a-payment-processor-actually-costs-you" }, { "@type": "HowToStep", "position": 2, "name": "What self-hosting gives you — and what it doesn’t", "text": "Be precise about the win, because overstating it is how people build the wrong threat model. Self-hosting a gateway changes exactly three things, and leaves several important things untouched. What genuinely changes. The money goes straight from the customer to an address only you control, so the…", "url": "https://servhidden.com/guides/self-host-a-crypto-payment-gateway#what-self-hosting-gives-you-and-what-it-doesnt" }, { "@type": "HowToStep", "position": 3, "name": "The stack: what BTCPay Server actually is", "text": "The de-facto answer is BTCPay Server: free, MIT-licensed, self-hosted, and built after a well-known processor’s policy decisions annoyed enough merchants to produce a replacement. It is not one program but a small stack of containers that come up together, and it helps to know which piece does wh…", "url": "https://servhidden.com/guides/self-host-a-crypto-payment-gateway#the-stack-what-btcpay-server-actually-is" }, { "@type": "HowToStep", "position": 4, "name": "Sizing the server: the disk is the whole decision", "text": "CPU is almost never the constraint. A gateway that processes a few hundred invoices a day is idle most of the time; the load is the initial block download and then a trickle. Memory matters more, and disk decides everything. Work out which row you are in before you order anything. ConfigurationDi…", "url": "https://servhidden.com/guides/self-host-a-crypto-payment-gateway#sizing-the-server-the-disk-is-the-whole-decision" }, { "@type": "HowToStep", "position": 5, "name": "Step 1 — Provision and harden the host", "text": "Order the server before you need it and let the chain sync while you do everything else. A KVM VPS with full root is the right shape: you need kernel-level control for Docker, and you want the machine to be yours rather than a container on someone’s shared platform. Pay for it the same way you in…", "url": "https://servhidden.com/guides/self-host-a-crypto-payment-gateway#step-1-provision-and-harden-the-host" }, { "@type": "HowToStep", "position": 6, "name": "Step 2 — Install the gateway", "text": "Installation is deliberately boring: clone the deployment repository, export a handful of environment variables describing what you want, and run the setup script. The variables that matter are the host name, the chains you want, and the optional fragments — which Lightning implementation, whethe…", "url": "https://servhidden.com/guides/self-host-a-crypto-payment-gateway#step-2-install-the-gateway" }, { "@type": "HowToStep", "position": 7, "name": "Step 3 — Connect a wallet without putting keys on the server", "text": "This is the step that determines whether self-hosting was worth doing, and it is the one most often got wrong in a hurry. BTCPay can generate a wallet for you, on the server, with the private keys on the server. Do not do this for a store that takes real money. The correct approach is to create t…", "url": "https://servhidden.com/guides/self-host-a-crypto-payment-gateway#step-3-connect-a-wallet-without-putting-keys-on-the-server" }, { "@type": "HowToStep", "position": 8, "name": "Step 4 — Add Lightning and Monero, if you need them", "text": "Both are worth having and neither is free, so add them because a customer asked, not because the checkbox exists. Lightning makes small payments viable — instant, effectively free, and immune to the fee spikes that make a four-dollar on-chain invoice absurd. The catch is not the software, which t…", "url": "https://servhidden.com/guides/self-host-a-crypto-payment-gateway#step-4-add-lightning-and-monero-if-you-need-them" }, { "@type": "HowToStep", "position": 9, "name": "Step 5 — Wire it into your site", "text": "The gateway is useless until your application knows an invoice was paid. There are three integration routes, in ascending order of effort and control. A plugin, if you run one of the common e-commerce platforms. Install it, paste an API key, done in an afternoon. This covers the majority of real …", "url": "https://servhidden.com/guides/self-host-a-crypto-payment-gateway#step-5-wire-it-into-your-site" }, { "@type": "HowToStep", "position": 10, "name": "Running it: backups, upgrades and the failure modes", "text": "A payment gateway is infrastructure, and infrastructure is judged on the bad day rather than the good one. Three habits cover almost every way this goes wrong. Back up the right things. The blockchain is not one of them — it is several hundred gigabytes that the internet will happily send you aga…", "url": "https://servhidden.com/guides/self-host-a-crypto-payment-gateway#running-it-backups-upgrades-and-the-failure-modes" }, { "@type": "HowToStep", "position": 11, "name": "The privacy reality: what the chain still shows", "text": "Removing the processor removes the processor. It does not make Bitcoin private, and a self-hosted gateway can quietly make your on-chain privacy worse if you are not paying attention. What leaksWhyWhat to do about it Your entire revenue history, to anyone holding the xpubOne extended public key d…", "url": "https://servhidden.com/guides/self-host-a-crypto-payment-gateway#the-privacy-reality-what-the-chain-still-shows" }, { "@type": "HowToStep", "position": 12, "name": "The legal part nobody enjoys", "text": "Short version, and not legal advice: running the software is not the regulated act. What you do with the money can be. In most jurisdictions, accepting crypto as payment for your own goods and services is an ordinary commercial transaction. You are a merchant being paid, not a financial instituti…", "url": "https://servhidden.com/guides/self-host-a-crypto-payment-gateway#the-legal-part-nobody-enjoys" }, { "@type": "HowToStep", "position": 13, "name": "The whole build, on one page", "text": "Stripped of the reasoning, this is a weekend project of which most is waiting: Decide the shape: pruned or full node, Lightning or not, Monero or not. This sets the disk, and the disk sets the plan. Order the server — NVMe, unmetered bandwidth, full root — and pay for it in the currency you inten…", "url": "https://servhidden.com/guides/self-host-a-crypto-payment-gateway#the-whole-build-on-one-page" } ] } ```