Bitcoin Payment Processor는 결제 요청을 만들고, 수신한 결제를 주문에 연결하며 기록 관리를 지원합니다. 직접 운영하거나 서비스로 이용할 수 있습니다. 비트코인 합의 규칙이 아니며, 프로세서라는 이름만으로 누가 자금을 통제하는지 알 수 없습니다.
상점이 주문을 만들고 서버가 금액과 통화를 담은 청구서를 프로세서에 요청합니다. 내부 주문 번호와 청구서 식별자의 연결을 저장합니다. 고객은 결제 페이지나 QR 코드를 받고 프로세서는 수신 여부를 추적합니다. 이 연결이 없으면 어느 주문에 대한 결제인지 신뢰성 있게 판단할 수 없습니다. 브라우저로 돌아오는 것만으로는 결제 증거가 되지 않습니다. [BTCPay Server — eCommerce integration]
BTCPay Server는 기존 지갑의 공개 데이터로 개인 키 없이 수신 주소를 도출할 수 있습니다. 이는 서버에 저장된 핫 월렛이나 Lightning 노드 자금에 대한 접근과 다릅니다. 제공자는 지급 전까지 자금을 보유할 수 있습니다. 제품 이름이나 non-custodial이라는 단어만 보지 말고 실제 키 보유자, 권한, 인출 가능성을 평가해야 합니다. [BTCPay Server — General FAQ] [BitPay — Configuring settlements]
일반적인 BTCPay Server 청구서는 제한된 시간 동안 환율을 고정합니다. 만료되었다고 이후 전송이 도착할 수 없는 것은 아닙니다. 부족 지급, 초과 지급, 지연 지급은 서로 다른 상태를 가지며 후속 절차가 필요합니다. 원래 금액과 적용 환율을 보관하세요. 가격이 바뀌면 새로 발행한 요청의 사토시 수가 같지 않을 수 있습니다. [BTCPay Server — Invoice lifecycle]
BTCPay Server는 설정한 확인 횟수를 기다리는 Processing과 Settled를 구분합니다. 성공한 Lightning 결제는 블록을 기다리지 않고 Settled로 넘어갑니다. 다른 제공자의 상태 이름을 기계적으로 동일시해서는 안 됩니다. BitPay는 paid가 결제 보장이 아니라고 명확히 경고합니다. 상점에는 구체적인 상태와 결제 수단에 맞는 상품 인도 규칙이 필요합니다. 상태를 수동으로 바꿔도 네트워크 확인은 생기지 않습니다. [BTCPay Server — Invoice lifecycle] [BitPay — Invoice webhooks]
BTCPay는 원본 본문 바이트와 공유 비밀에 대한 HMAC-SHA256으로 webhook을 검증합니다. BitPay가 설명하는 IPN은 서명되지 않습니다. 알림은 API로 청구서 상태를 조회할 계기이며 자체로 신뢰할 수 있는 증거가 아닙니다. 알림은 반복 도착할 수 있습니다. 따라서 통합 시스템은 재전송된 이벤트를 확실히 식별하고 같은 주문의 두 번째 배송을 막아야 합니다. 장애 후에는 저장한 상태를 프로세서와 대조해야 합니다. [BTCPay Server — Webhook validation example] [BitPay — Invoice webhooks]
고객 결제의 확인 시점이 제공자의 지급 시점과 일치하지 않을 수 있습니다. BitPay에서는 정산 통화와 은행 계좌 또는 암호화폐 주소를 설정할 수 있으며 변경에 승인이 필요할 수 있습니다. 지원 통화, 한도, 일정, 수수료, 지급 전 자금 통제권을 확인하세요. 자신의 지갑으로 직접 받는 방식이 이러한 제공자 지급 모델을 자동으로 사용하는 것은 아닙니다. [BitPay — Configuring settlements] [BTCPay Server — General FAQ]
환불에는 별도 지급과 수신자 확인이 필요하며 원래 비트코인 거래를 바꾸지 않습니다. 주문에 대한 이의 제기, 환불 금액 결정, 실제 송금을 구분하세요. 주문–청구서–결제의 연결, 환율, 수수료, 환불 기록을 보관합니다. 보고서 내보내기는 기록 관리에 도움이 되지만 그 자체로 모든 지역 회계 의무나 상품 배송 분쟁을 해결하지는 못합니다. 확인된 전송이라도 거래의 법적 최종성을 그 자체로 결정하지는 않습니다. 결제 경로, 계약, 관할권에 따라 분쟁 처리, 가능한 chargeback 절차, 의무를 확인하세요. [BTCPay Server — Refunds] [BTCPay Server — Reporting] [BitPay — Merchant and shopper terms]
성공한 결제, 불완전한 결제, 지연 결제, 반복 통지된 결제와 장애 복구를 시험하세요. API 키에는 필요한 권한만 부여하고 해당 상점으로 범위를 제한합니다. 메타데이터에 불필요한 고객 정보를 전달하지 마세요. 호스팅, 업데이트, 유동성, 지원 비용을 고려해야 합니다. 무료 소프트웨어가 운영 비용 0을 의미하지는 않습니다. 서비스 가용성, 키 보관, 통합의 정확성은 별개의 조건입니다. [BTCPay Server — eCommerce integration] [BTCPay Server — Lightning operations]
같은 알림은 또 다른 구매가 아니다
가상의 통합 사례에서 주문 OBJ-101에는 청구서 식별자가 저장됩니다. 정산을 검증한 시스템은 배송을 한 번만 생성합니다. 나중에 같은 이벤트의 중복 알림이 도착하면 이미 이행된 주문에 연결하고 다른 배송은 생성하지 않습니다. 감사 페이지를 표시하는 것만으로 이런 상태 전환이 발생해서는 안 됩니다.
더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 BTCPay Server, Bitcoin Point of Sale, Merchant Adoption, Lightning Network, Bitcoin. 다음 항목에서도 이 글을 참조합니다 Alza Bitcoin payments, Merchant Adoption, BTCPay Server, Bitcoin Point of Sale.
01모든 결제 프로세서가 내 비트코인을 보관하나요?+
아닙니다. 일부 솔루션은 요청을 만들고 지갑으로의 수신만 추적하며, 다른 솔루션은 지급 전까지 자금을 관리합니다. 같은 소프트웨어도 서로 다른 지갑 모델을 사용할 수 있습니다. 핵심은 키, 권한, 실제 자금 흐름이지 프로세서라는 이름만이 아닙니다.
02고객이 결제 페이지에서 돌아오면 상점은 배송해도 되나요?+
돌아오는 것만으로는 부족합니다. 상점은 해당 프로세서의 절차로 관련 청구서와 그 상태를 검증해야 합니다. 알림은 문서에 따라 검증하며, 재전송이 또 다른 이행을 일으켜서는 안 됩니다. 상품 인도는 선택한 결제 확인 조건을 따릅니다.