Accetti il pagamento lei stesso.
Non è rimasto nessuno che possa congelarlo.

Un pagamento su una blockchain non ha bisogno di un'azienda in mezzo. Il cliente firma una transazione, la rete la conferma, e il denaro è suo — non c'è un acquirer, non c'è una finestra di regolamento e non c'è nessuno dalla cui approvazione il pagamento dipenda. Questo è tutto il senso della cosa, ed è il motivo per cui questa tecnologia esiste.

Poi un negozio deve effettivamente accettare pagamenti, e i requisiti pratici arrivano tutti insieme. Ogni fattura ha bisogno del proprio indirizzo, così i pagamenti si possono distinguere. Qualcuno deve osservare la catena e decidere quando una fattura è pagata. L'importo deve essere quotato in una valuta in cui il cliente ragiona, a un tasso che tenga abbastanza a lungo perché lui prema invia. Lo stato dell'ordine deve rifluire nel negozio. E deve funzionare alle due di notte senza che nessuno stia a guardare. Costruire tutto questo è un progetto; non costruirlo è il motivo per cui quasi tutti si iscrivono invece a un gateway ospitato — rimettendo, nello spazio di un modulo, un intermediario in un sistema progettato per non averne uno.

Vale la pena dire chiaramente cosa detiene quell'intermediario, perché è più della commissione. Detiene le monete, almeno finché non viene eseguito un payout, il che significa che può ritardarne uno. Detiene l'elenco: ogni cliente, ogni importo, ogni timestamp, ogni prodotto, in un database che lei non può leggere né cancellare. Detiene un documento d'identità su di lei, perché un'azienda che tocca il denaro altrui è tenuta a raccoglierne uno. E detiene l'interruttore, perché i termini di servizio si riservano il diritto di decidere che la sua attività non è più gradita — una decisione che arriva via email, si applica sia al saldo sia all'account, e in pratica non è impugnabile.

BTCPay Server è la risposta esattamente a quel problema, e a nient'altro. È un processore di pagamento gratuito e open source che fa girare sulla propria macchina: deriva un indirizzo per ogni fattura, osserva la catena, quota i prezzi in valuta fiat, espone un checkout e un'API, e parla Lightning. Non detiene mai le sue monete, perché il portafoglio che osserva è uno che possiede già. Quattro modi per accettare un pagamento in crypto, e cosa costa davvero ciascuno:

Anche la seconda colonna non è uno scherzo — un singolo indirizzo in un footer va genuinamente bene per un link di donazione, e far finta del contrario vende software che a nessuno serve. Smette di andare bene nel momento in cui due persone pagano lo stesso importo lo stesso giorno, o nel momento in cui preferirebbe che il suo reddito annuo non fosse una cifra pubblica che chiunque può sommare.

Ordini il server. Nel pannello: Ordina → VPS → Garrison, immagine Debian 12, nel bastione in cui vuole che vivano i dati del negozio — Helsinki, Stoccolma, Oslo o Reykjavík. Garrison è la scelta predefinita giusta perché contiene una catena pruned da 100 GB, un nodo Lightning e il database senza che debba ripensare al disco per anni. Sentinel funziona con un pruning più stretto; Bulwark è il livello per un nodo archivistico. Non è richiesto alcun indirizzo email per aprire l'account, e la fattura si salda in Monero, Bitcoin, Lightning o qualsiasi altro asset supportato — il che è la parte piacevole di questo progetto in particolare, dato che sta costruendo una macchina per accettare pagamenti in crypto e la sta pagando con uno di essi.

Poi esegua la checklist di hardening della prima ora prima di qualsiasi altra cosa — SSH solo a chiave su una porta spostata, aggiornamenti automatici, un firewall a diniego predefinito. Questo server conterrà col tempo il registro di ogni cliente che ha e il materiale delle chiavi di un nodo Lightning con fondi vivi al suo interno. Non è un server da lasciare con l'autenticazione a password per una settimana.

Ora il record DNS, e lo faccia prima di eseguire l'installer, non dopo. Scelga l'hostname su cui vivrà il checkout — shop.example.com, pay.example.com, quello che preferisce — e punti un record A verso l'indirizzo del VPS, più un AAAA se lo vuole raggiungibile via IPv6. Lo lasci propagare. Il reverse proxy che l'installer configura cercherà di ottenere un certificato per quel nome esatto durante il suo primo avvio, usando una sfida HTTP che richiede che il nome risolva già verso questa macchina. Un record non ancora attivo è, di gran lunga, il modo più comune in cui una prima installazione finisce in un errore che disorienta.

Poi scriva le regole del firewall mentre ancora nessuno è in ascolto. Quattro porte, e solo quattro. Il checkout è per necessità un endpoint HTTPS pubblico — il browser di un cliente deve poterlo raggiungere — e la porta 80 resta aperta perché il rinnovo del certificato la usa. La porta peer-to-peer di Lightning serve solo se vuole che altri nodi possano aprire canali verso di lei, cosa che il passo 05 sosterrà essere nel suo interesse. La porta peer-to-peer di Bitcoin non ha alcun bisogno di essere aperta: il suo nodo fa connessioni in uscita perfettamente bene, e aprirla in entrata lo rende solo più facile da trovare.

ufw default deny incoming
ufw allow 47222/tcp                  # administrative SSH, moved off 22
ufw allow 80/tcp                     # ACME HTTP-01 challenge and the redirect
ufw allow 443/tcp                    # the checkout
ufw allow 9735/tcp                   # Lightning peer-to-peer, only if you want inbound channels
ufw enable
ufw status numbered

Due note sulle risorse prima di continuare. Dia dello swap al server se non ne ha — il download iniziale dei blocchi è l'ora più affamata di memoria di questo progetto, e 4 GB di RAM con 2 GB di swap si comportano molto meglio di 4 GB da soli. E verifichi i conti sul disco del passo 01 rispetto al livello che ha effettivamente ordinato, perché un nodo che riempie il proprio volume a metà sync non fallisce educatamente; corrompe il proprio indice e ricomincia da capo.

fallocate -l 2G /swapfile && chmod 600 /swapfile
mkswap /swapfile && swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab
df -h /                              # confirm the volume matches step 01

Crei un negozio, e poi prenda l'unica decisione di questa pagina che conta davvero. BTCPay offrirà due modi per collegare un portafoglio Bitcoin: collegarne uno esistente, oppure lasciare che ne generi uno nuovo tenendo il seed sul server. Il primo è watch-only ed è quello che vuole. Il secondo trasforma una macchina pubblica, esposta a internet, in un hot wallet che detiene il suo fatturato, e nessuna quantità di hardening rende questo un buono scambio per un server il cui unico compito è essere raggiungibile da sconosciuti.

Il meccanismo dietro questo consiglio è abbastanza elegante da meritare di essere capito. I portafogli moderni sono gerarchici: un seed deriva un albero di chiavi, ed esiste una chiave pubblica estesa — uno xpub, o la sua variante zpub per il segwit nativo — a partire dalla quale si può calcolare ogni indirizzo di ricezione di un account senza alcuna capacità di firmare. La consegni al negozio e potrà generare un indirizzo nuovo per ogni fattura, osservare la catena per i pagamenti verso ciascuno di essi, e mostrarle il saldo. Non può muovere un satoshi. La metà privata resta nel suo portafoglio, o sul suo dispositivo hardware, e non viaggia mai.

Quindi: apra Sparrow, Electrum, oppure l'app desktop del suo portafoglio hardware, crei un nuovo account dedicato a questo negozio, ed esporti la sua chiave pubblica estesa. Nelle impostazioni del portafoglio del negozio scelga di collegare un portafoglio esistente, incolli la chiave, e verifichi i primi indirizzi che BTCPay deriva contro quelli mostrati dal suo portafoglio. Se corrispondono, il percorso di derivazione è corretto e il collegamento è fatto. Se non corrispondono, ha scelto il tipo di script sbagliato — la differenza tra uno xpub e uno zpub è la differenza tra due insiemi di indirizzi completamente separati.

Ora le impostazioni delle fatture, che sono il punto in cui un negozio viene davvero calibrato. La scadenza è impostata di default a circa quindici minuti, ed è un blocco del tasso di cambio più che un limite tecnico: è per quanto tempo è disposto a mantenere un prezzo denominato in fiat contro un asset volatile. La riduca per un mercato volatile, la allunghi se i suoi clienti sono lenti. Le conferme decidono quando una fattura conta come saldata — zero conferme è istantaneo ed è adatto per un caffè, una conferma è il default ordinario, e sei sono per gli importi in cui un'ora di attesa costa meno dell'alternativa. La tolleranza di sottopagamento le permette di accettare una fattura che arriva leggermente in difetto, cosa che succede di continuo quando il portafoglio di un cliente detrae la propria commissione dall'importo anziché aggiungerla; una piccola percentuale qui elimina un'intera categoria di email di supporto.

Poi lo testi con denaro vero, non con la testnet. Emetta una richiesta di pagamento per un importo trascurabile, la paghi da un portafoglio sul telefono, e osservi la fattura passare da nuova a in lavorazione a saldata. Quella singola transazione dimostra che il nodo è sincronizzato, che il percorso di derivazione è corretto, che il fornitore del tasso di cambio funziona, che il certificato è valido su un browser mobile, e che il denaro è arrivato in un portafoglio che controlla. Nient'altro dimostra tutte e cinque le cose insieme.

Scelga la superficie di checkout più piccola che si adatta a quello che ha già. Una richiesta di pagamento è un link che invia a qualcuno — nessun sito web richiesto, e il modo più veloce di fatturare a un cliente. Un'app punto vendita trasforma la stessa istanza in una cassa con un elenco di prodotti, il che funziona da un telefono a una bancarella del mercato. Un pulsante di pagamento è un frammento di HTML per un sito statico. Un plugin per il negozio aggiunge Bitcoin come metodo di pagamento a un vero negozio online e riscrive automaticamente lo stato dell'ordine. E la REST API emette fatture, ne riporta lo stato e chiama un webhook quando una si salda, il che è l'integrazione che invecchia meglio perché non dipende da altro che HTTP e un segreto condiviso.

Qualunque cosa scelga, colleghi il webhook e poi verifichi che scatti. Una fattura che si salda e non notifica mai la sua applicazione è la modalità di fallimento che nessuno intercetta, perché tutto sembra corretto su entrambi i lati se osservato isolatamente: il denaro è arrivato, il cliente ha visto una pagina di conferma, e l'ordine resta inevaso. Si invii di proposito un webhook di fattura saldata, confermi che il suo endpoint lo abbia ricevuto, e verifichi la firma invece di fidarsi del payload — quell'endpoint è pubblico e chiunque può inviarci dati.

Capito questo, la routine è breve. Il deployment include uno script di backup che archivia i volumi e fa il dump del database saltando i dati della blockchain, e accetta una passphrase in modo che l'archivio sia cifrato prima di lasciare il server. Lo esegua a intervalli regolari, poi invii il risultato a una macchina in una giurisdizione diversa nel modo descritto dalla guida ai backup — un repository append-only vale i dieci minuti extra in questo caso, perché un server di pagamento compromesso non dovrebbe poter cancellare il registro di ciò che ha elaborato.

cd ~/BTCPayServer/btcpayserver-docker
export BTCPAY_BACKUP_PASSPHRASE="a long passphrase you keep elsewhere"
./btcpay-backup.sh                   # archives volumes + database, skips the chain
# then ship the archive offsite, and keep the channel backup separately

Poi vengono gli aggiornamenti, e un server di pagamento è l'unica macchina in cui “aggiornarlo più avanti, di proposito” è la politica corretta. Il deployment ha un proprio script di aggiornamento che rigenera il file compose e scarica le nuove immagini; lo esegua quando ha letto le note di rilascio, non quando gli va di farlo a un cron job. Prima faccia l'archivio. Avanzi di una release alla volta. E tenga scritta da qualche parte la versione precedente, perché un rollback che può fare in un minuto è ciò che rende l'intera faccenda a basso rischio.

./btcpay-update.sh                   # deliberate, after reading the release notes
df -h /                              # the check that should be an alert, not a habit

Infine, imposti un avviso e un promemoria. L'avviso riguarda l'uso del disco — un nodo blockchain è l'unico processo sulla macchina che cresce da solo, e un volume pieno manda giù il checkout in un modo lento da diagnosticare perché nient'altro è cambiato. Lo faccia scattare all'ottanta per cento, non al novantacinque. Il promemoria è mensile, e consiste nell'aprire il negozio e controllare due cose: che le fatture continuino a saldarsi, e che i canali Lightning che ha aperto siano ancora vivi. Un processore di pagamento fallisce silenziosamente, e il modo in cui lo scopre è un cliente che le dice di non essere riuscito a pagare.