직접 결제를 받으십시오.
그것을 동결할 사람이 이제 아무도 남아 있지 않습니다.

블록체인 위의 결제에는 중간에 낀 회사가 필요 없습니다. 고객이 트랜잭션에 서명하면 네트워크가 그것을 확인하고, 그러면 그 돈은 당신 것이 됩니다 — 매입사도, 정산 기간도, 결제가 승인을 기다려야 할 누군가도 없습니다. 그것이 바로 이 기술의 핵심이며, 이 기술이 애초에 존재하는 이유입니다.

그다음 상점은 실제로 결제를 받아야 하고, 실질적인 요구 사항들이 한꺼번에 밀려듭니다. 결제를 서로 구별할 수 있도록 모든 인보이스에는 저마다의 주소가 있어야 합니다. 누군가는 체인을 지켜보며 인보이스가 언제 결제되었는지 판단해야 합니다. 금액은 고객이 익숙한 통화로, 그가 전송 버튼을 누를 때까지 버텨 줄 환율로 표시되어야 합니다. 주문 상태는 다시 상점으로 흘러 들어가야 합니다. 그리고 이 모든 것이 새벽 두 시에도 아무도 지켜보지 않는 채로 작동해야 합니다. 이 모든 것을 만드는 일은 하나의 프로젝트이고, 만들지 않는 것이야말로 거의 모두가 대신 호스팅형 게이트웨이에 가입하는 이유입니다 — 그리고 그 순간, 양식 하나를 채우는 사이에, 애초에 없도록 설계된 시스템에 중개자를 도로 들여놓게 됩니다.

그 중개자가 쥐고 있는 것이 무엇인지는 분명히 말해 둘 가치가 있습니다. 수수료보다 훨씬 크기 때문입니다. 그것은 코인을 쥐고 있습니다, 적어도 페이아웃이 실행되기 전까지는요. 즉 그것을 지연시킬 수 있다는 뜻입니다. 그것은 목록을 쥐고 있습니다. 모든 고객, 모든 금액, 모든 타임스탬프, 모든 상품이, 당신은 읽을 수도 지울 수도 없는 데이터베이스 안에 담겨 있습니다. 그것은 당신에 대한 신분 확인 서류를 쥐고 있습니다. 다른 사람의 돈을 만지는 회사는 그것을 수집해야 하기 때문입니다. 그리고 그것은 스위치를 쥐고 있습니다. 이용 약관은 당신의 사업이 더는 반갑지 않다고 결정할 권리를 유보해 두고 있으며, 그 결정은 이메일로 통보되고, 계정뿐 아니라 잔액에도 적용되며, 실제로는 이의를 제기할 수도 없습니다.

BTCPay Server는 정확히 그 문제에 대한 답이며, 그 이상도 이하도 아닙니다. 당신 소유의 머신에서 직접 운영하는 무료 오픈소스 결제 프로세서로, 인보이스마다 주소를 하나씩 파생시키고, 체인을 지켜보고, 법정화폐 가격을 매기고, 체크아웃과 API를 노출하며, Lightning을 구사합니다. 당신의 코인을 절대 쥐지 않는데, 그것이 지켜보는 지갑은 이미 당신이 소유한 지갑이기 때문입니다. 크립토 결제를 받는 네 가지 방법과, 각각이 실제로 얼마나 드는지는 다음과 같습니다.

두 번째 열도 농담이 아닙니다 — 푸터에 적힌 주소 하나만으로도 후원 링크로는 정말 충분하며, 그렇지 않은 척하는 것은 아무도 필요로 하지 않는 소프트웨어를 파는 것입니다. 그것이 충분하지 않게 되는 시점은 같은 날 두 사람이 같은 금액을 결제하는 순간, 또는 당신의 연 수입이 누구나 합산해 볼 수 있는 공개된 숫자이지 않기를 바라게 되는 순간입니다.

서버를 주문하십시오. 패널에서: Order → VPS → Garrison, 이미지는 Debian 12, 상점의 기록이 자리 잡길 원하는 거점은 Helsinki, Stockholm, Oslo, Reykjavík 중에서. Garrison이 올바른 기본값인 이유는 100GB 프루닝 체인과 Lightning 노드, 데이터베이스를 담고도 앞으로 수년간 디스크를 다시 신경 쓰지 않아도 되기 때문입니다. Sentinel은 더 빡빡한 프루닝으로 돌아가고, Bulwark는 아카이브 노드를 위한 티어입니다. 계정을 여는 데 이메일 주소는 필요 없고, 청구서는 Monero, Bitcoin, Lightning을 비롯한 다른 지원 자산으로 정산됩니다 — 크립토 결제를 받는 머신을 만들면서 그 대금을 크립토로 치른다는 점이, 바로 이 프로젝트에서 유독 흐뭇한 부분입니다.

그런 다음 다른 무엇보다 먼저 첫 시간 보안 강화 체크리스트를 실행하십시오 — 옮긴 포트에서의 키 전용 SSH, 무인 업그레이드, 기본 차단 방화벽입니다. 이 서버는 언젠가 당신의 모든 고객 기록과, 실제 자금이 들어 있는 Lightning 노드의 키 자료를 담게 됩니다. 일주일씩이나 비밀번호 인증으로 방치해 둘 서버가 아닙니다.

이제 DNS 레코드입니다. 설치 프로그램을 실행한 다음이 아니라 그 전에 해 두십시오. 체크아웃이 자리 잡을 호스트네임을 고르고 — shop.example.com, pay.example.com, 무엇이든 맞는 것으로 — VPS 주소로 향하는 A 레코드를 지정한 다음, IPv6로도 접속하고 싶다면 AAAA도 하나 지정하십시오. 전파될 시간을 주십시오. 설치 프로그램이 구성하는 리버스 프록시는 첫 부팅 중에 바로 그 이름으로 인증서를 발급받으려 시도하는데, 이때 쓰는 HTTP 챌린지는 그 이름이 이미 이 서버로 해석되어야만 통과합니다. 아직 반영되지 않은 레코드는 첫 설치가 헷갈리는 오류로 끝나는 가장 흔한 원인입니다.

그런 다음 아직 아무것도 리스닝하지 않을 때 방화벽 규칙을 써 두십시오. 포트는 네 개, 딱 네 개뿐입니다. 체크아웃은 필연적으로 퍼블릭 HTTPS 엔드포인트입니다 — 고객의 브라우저가 닿아야 하기 때문입니다 — 그리고 인증서 갱신이 그것을 쓰므로 80번 포트도 열어 둡니다. Lightning 피어투피어 포트는 다른 노드가 당신 쪽으로 채널을 열 수 있기를 원할 때만 필요한데, 단계 05는 당신이 그것을 원해야 한다고 주장할 것입니다. Bitcoin 피어투피어 포트는 아예 열 필요가 없습니다. 당신의 노드는 아웃바운드 연결만으로도 완벽하게 잘 작동하며, 인바운드로 열어 두는 것은 그저 찾아내기 쉽게 만들 뿐입니다.

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

계속하기 전에 리소스에 관한 메모 두 가지입니다. 서버에 스왑이 없다면 추가하십시오 — 최초 블록 다운로드는 이 프로젝트에서 메모리를 가장 많이 먹는 시간이며, 4GB의 RAM에 2GB의 스왑을 더한 쪽이 4GB만 있는 것보다 훨씬 낫게 버팁니다. 그리고 단계 01의 디스크 계산을 실제로 주문한 티어와 대조해 확인하십시오. 동기화 도중 볼륨을 다 채운 노드는 얌전히 실패하지 않습니다. 자기 색인을 손상시키고 처음부터 다시 시작합니다.

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

상점을 만든 다음, 이 페이지에서 실제로 중요한 단 하나의 결정을 내리십시오. BTCPay는 Bitcoin 지갑을 연결하는 두 가지 방법을 제시합니다. 기존 지갑을 연결하거나, 새 지갑을 생성해 시드를 서버에 두는 것입니다. 첫 번째가 워치온리이고, 당신이 원하는 방식입니다. 두 번째는 퍼블릭하게 인터넷에 노출된 머신을 당신의 매출을 담은 핫월렛으로 바꿔 버리며, 낯선 사람들에게 닿는 것이 유일한 임무인 서버에게 그것은 아무리 강화를 해도 좋은 거래가 되지 않습니다.

이 권장 사항 뒤에 있는 메커니즘은 이해할 가치가 있을 만큼 우아합니다. 현대적인 지갑은 계층적입니다. 시드 하나가 키의 트리를 파생시키며, 확장 공개 키 — xpub, 또는 네이티브 segwit용 변형인 zpub — 라는 것이 있어서, 이것으로부터 계정의 모든 수신 주소를 서명 능력 없이도 계산해 낼 수 있습니다. 그것을 상점에 건네면 인보이스마다 새 주소를 생성하고, 각각에 대한 결제를 체인에서 지켜보고, 잔액을 보여 줄 수 있습니다. 사토시 하나도 옮길 수 없습니다. 개인 키 쪽은 당신의 지갑이나 하드웨어 장치 안에 머무를 뿐, 결코 밖으로 나가지 않습니다.

그러니: Sparrow나 Electrum, 또는 하드웨어 지갑의 데스크톱 앱을 열어, 이 상점 전용의 새 계정을 만들고 그 확장 공개 키를 내보내십시오. 상점의 지갑 설정에서 기존 지갑 연결을 선택하고 키를 붙여 넣은 다음, BTCPay가 파생시키는 처음 몇 개 주소를 지갑이 보여 주는 주소와 대조하십시오. 일치한다면 파생 경로가 맞은 것이고 연결이 끝난 것입니다. 일치하지 않는다면 스크립트 유형을 잘못 고른 것입니다 — xpub과 zpub의 차이는 완전히 서로 다른 두 벌의 주소 집합의 차이입니다.

이제 인보이스 설정입니다. 실제로 상점이 조율되는 지점이 바로 여기입니다. 만료 시간은 기본값이 약 15분이며, 기술적 한계라기보다는 환율 고정 시간입니다. 변동성 있는 자산에 대해 법정화폐 표시 가격을 얼마나 오래 유지해 줄 것인지를 정하는 것입니다. 변동성이 큰 시장이라면 짧게, 고객이 느리다면 길게 잡으십시오. 컨펌 수는 인보이스가 언제 정산된 것으로 칠지를 정합니다 — 0컨펌은 즉시 처리되어 커피 한 잔에 어울리고, 1컨펌이 일반적인 기본값이며, 6컨펌은 한 시간을 기다리는 편이 그 대안보다 싼 금액대에 씁니다. 부족 결제 허용치는 살짝 모자라게 도착한 인보이스도 받아들이게 해 주는데, 고객의 지갑이 수수료를 금액에 더하지 않고 그 안에서 떼어 갈 때 끊임없이 벌어지는 일입니다. 여기에 작은 비율을 설정해 두면 지원 이메일의 한 카테고리 전체가 사라집니다.

그런 다음 테스트넷이 아니라 실제 돈으로 테스트하십시오. 아주 적은 금액의 결제 요청을 발행해 휴대폰 지갑으로 결제하고, 인보이스가 신규에서 처리 중을 거쳐 정산됨으로 넘어가는 것을 지켜보십시오. 그 단 하나의 트랜잭션이 다섯 가지를 한꺼번에 증명합니다. 노드가 동기화되어 있다는 것, 파생 경로가 맞다는 것, 환율 제공자가 작동한다는 것, 인증서가 모바일 브라우저에서 유효하다는 것, 그리고 돈이 당신이 통제하는 지갑에 도착했다는 것입니다. 이 다섯 가지를 한꺼번에 증명해 주는 것은 이것 말고는 없습니다.

이미 갖추고 있는 것에 맞는, 가장 작은 체크아웃 형태를 고르십시오. 결제 요청은 누군가에게 보내는 링크입니다 — 웹사이트가 필요 없고, 고객에게 청구하는 가장 빠른 방법입니다. POS 앱은 같은 인스턴스를 상품 목록을 갖춘 계산대로 바꿔 주며, 시장 좌판에서 휴대폰으로도 작동합니다. 페이 버튼은 정적 사이트를 위한 HTML 스니펫입니다. 상점 플러그인은 실제 스토어에 Bitcoin을 결제 수단으로 추가하고 주문 상태를 자동으로 반영합니다. 그리고 REST API는 인보이스를 발행하고 상태를 보고하며 정산될 때 웹훅을 호출합니다. 이것이 가장 오래가는 통합 방식인데, HTTP와 공유 비밀 키 말고는 아무것도 필요로 하지 않기 때문입니다.

무엇을 고르든, 웹훅을 연결한 다음 실제로 발신되는지 테스트하십시오. 정산되었는데 애플리케이션에 한 번도 통지되지 않는 인보이스는 아무도 잡아내지 못하는 실패 양상입니다. 양쪽 모두 따로 보면 다 정상으로 보이기 때문입니다. 돈은 도착했고, 고객은 확인 페이지를 보았으며, 주문은 처리되지 않은 채 남아 있습니다. 일부러 정산 완료 웹훅을 스스로에게 보내 엔드포인트가 그것을 받았는지 확인하고, 페이로드를 그냥 믿지 말고 서명을 검증하십시오 — 그 엔드포인트는 공개되어 있어 누구든 거기에 게시할 수 있습니다.

이것을 이해했다면, 루틴은 간단합니다. 배포판은 블록체인 데이터는 건너뛰고 볼륨을 아카이브하고 데이터베이스를 덤프하는 백업 스크립트를 제공하며, 서버를 떠나기 전에 아카이브가 암호화되도록 비밀번호구를 받습니다. 이것을 타이머로 돌린 다음, 백업 가이드가 설명하는 방식으로 결과물을 다른 관할권의 머신으로 보내십시오 — 추가로 드는 10분은 여기서 그만한 값어치를 합니다. 추가 전용 저장소라면, 침해당한 결제 서버가 자신이 처리한 기록을 스스로 지울 수 없기 때문입니다.

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

그다음은 업그레이드이며, 결제용 서버는 "나중에, 의도를 갖고 업데이트한다"가 올바른 정책이 되는 유일한 종류의 머신입니다. 배포판에는 compose 파일을 다시 생성하고 새 이미지를 받아 오는 자체 업데이트 스크립트가 있습니다. 크론 작업이 내키는 때가 아니라 릴리스 노트를 읽은 뒤에 실행하십시오. 아카이브부터 먼저 만들어 두십시오. 릴리스는 한 번에 하나씩 올리십시오. 그리고 이전 버전을 적어 두십시오. 1분 만에 되돌릴 수 있다는 사실이야말로 이 모든 일을 부담 없게 만들어 줍니다.

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

마지막으로 알림 하나와 리마인더 하나를 설정하십시오. 알림은 디스크 사용량에 관한 것입니다 — 블록체인 노드는 머신에서 스스로 계속 커지는 유일한 프로세스이며, 볼륨이 가득 차면 다른 것은 아무것도 바뀌지 않았기에 원인을 찾기 어려운 방식으로 체크아웃이 멈춥니다. 95퍼센트가 아니라 80퍼센트에서 울리게 하십시오. 리마인더는 매달, 상점을 열어 두 가지를 확인하는 것입니다. 인보이스가 여전히 정산되고 있는지, 그리고 열어 둔 Lightning 채널이 여전히 살아 있는지 말입니다. 결제 프로세서는 조용히 실패하며, 그 사실을 알게 되는 경로는 결제할 수 없었다는 고객의 말뿐입니다.