Bitcoin Point of Sale은 대면 판매용 계산 인터페이스입니다. 구매 가격을 계산하고 결제 요청을 만들며 수취한 결제를 연결하고 기록을 보관합니다. 휴대전화, 태블릿, 단말기에서 실행할 수 있지만 기기의 외형이 코인 통제권을 결정하지는 않습니다.
직원은 상품을 선택하거나 금액을 입력하고 통화, 팁, 최종 합계를 확인합니다. BTCPay Server는 상품 목록, 장바구니, 숫자 키패드를 제공합니다. 각 구매는 주문과 청구서를 통해 추적할 수 있어야 하며 화면을 다시 열어도 판매 기록을 중복 생성해서는 안 됩니다. [BTCPay Server — Point of Sale app] [BTCPay Server — Invoice lifecycle]
현지 통화 가격은 설정한 환율 출처로 환산하며 계산대는 예상 비트코인 금액과 제안의 유효기간을 보여야 합니다. BOLT 11에는 결제 해시와 만료 시점을 포함한 Lightning 청구서 정보가 들어가며 금액은 선택 사항일 수 있습니다. 구체적인 구매에서는 실제 금액, 네트워크, 수취인을 확인해야 합니다. 가격 환산은 비트코인을 법정화폐로 매도하는 것이 아닙니다. [BTCPay Server — Store rates and policies] [Lightning BOLTs — Invoice protocol]
QR 코드는 결제 정보를 전달할 뿐입니다. 고객의 화면 캡처는 상점 시스템의 상태를 대신하지 못합니다. BTCPay Server의 Processing은 선택한 on-chain 확인을 기다립니다. Settled는 정책 충족을 뜻하지만 수동으로 설정할 수도 있습니다. 성공한 Lightning 결제는 블록 확인을 기다리지 않습니다. 따라서 상품 인도는 화면 색상만이 아니라 검증된 결제에 근거해야 합니다. [BTCPay Server — Invoice lifecycle]
같은 태블릿도 자체 지갑으로 수취하거나 수탁 제공자를 이용할 수 있습니다. 중요한 것은 키, 권한, 정산 조건이지 Bitcoin 로고가 아닙니다. 공개키로 수취해도 침해된 계산대나 서버가 향후 주소를 바꾸는 위험은 남습니다. 직원 권한은 수취인 변경, 지갑 관리, 환불 승인 권한과 분리해야 합니다. [BTCPay Server — Wallet setup] [BTCPay Server — Third-party hosting risks] [BTCPay Server — Lightning setup]
자체 Lightning 노드에는 운영, 채널, 수취 유동성이 필요합니다. 제공자가 일부 작업을 맡으면 비용과 신뢰 조건이 달라집니다. 라우팅 실패나 유동성 부족은 성공한 결제가 아닙니다. 다른 결제 수단으로 바꾸기 전에 원래 시도의 결과를 확인해 한 구매에 두 번 결제하지 않도록 합니다. [BTCPay Server — Lightning setup] [Lightning BOLTs — Invoice protocol]
인터넷, 백엔드, 환율 출처를 사용할 수 없으면 새 요청이나 수취 확인이 불가능할 수 있습니다. 화면에 표시되거나 인쇄된 코드는 최신 상태 없이도 읽힐 수 있습니다. 운영 절차에는 예비 연결, 판매 연기, 사후 결제 조회를 정해야 합니다. 부족 결제, 초과 결제, 만료 후 결제는 개별 판단해야 하며 수동 상태 변경은 네트워크 이력을 바꾸지 않습니다. [BTCPay Server — Invoice lifecycle] [BTCPay Server — Store rates and policies]
환불에는 원래 구매와의 연결, 합의한 금액과 통화, 검증한 목적지, 권한 있는 승인이 필요합니다. BTCPay Server는 환불 요청 생성과 실제 지급을 구분합니다. 원래 이체는 사라지지 않습니다. 직원은 생성된 요청, 대기 중인 지급, 실제 완료된 환불을 구별해야 합니다. [BTCPay Server — Refund workflow]
교대가 끝나면 주문, 수취 결제, 수수료, 환불, 제공자의 정산금을 대조합니다. BTCPay Server는 결제, 판매 상품, on-chain 지갑 보고서를 내보내지만 내보내기만으로 현지 회계·세무 요건 충족을 보장하지는 않습니다. 직원 절차, 장애, 복구를 시험하고 고객 정보 접근을 제한하며 기기, 연결, 운영 비용을 고려해야 합니다. [BTCPay Server — Reporting] [BTCPay Server — Point of Sale app] [BTCPay Server — Third-party hosting risks]
두 화면, 한 구매
가상의 주문 POS-497에서 고객은 결제 성공을 보여주지만 직원 태블릿의 연결이 끊깁니다. 직원은 자동으로 미결제 처리하거나 곧바로 두 번째 요청을 발행하지 않습니다. 연결을 복구하고 원래 청구서를 찾아 금액과 실제 수취 상태를 확인합니다. 그 뒤에야 상품 인도나 재시도를 결정하고 결과를 같은 주문에 기록합니다.
더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 Merchant Adoption, BTCPay Server, Bitcoin Payment Processor, BOLT 11, 확인, Bitcoin. 다음 항목에서도 이 글을 참조합니다 Merchant Adoption, Bitcoin Payment Processor, BTCPay Server, BTC Map.
01계산대에 QR 코드만 있으면 충분한가요?+
코드는 결제 정보를 전달하지만 자체적으로 수취를 검증하거나 구매에 연결하지는 않습니다. 계산대에는 신뢰할 수 있는 결제 상태와 금액 오류, 만료, 연결 장애를 처리할 절차가 필요합니다.
02Lightning 결제는 항상 상점의 자체 보관을 뜻하나요?+
아닙니다. 계산대는 자체 노드, 다른 서비스 모델, 수탁 제공자를 사용할 수 있습니다. 누가 키와 잔액을 통제하고 수취를 담당하며 어떤 조건에서 자금을 인출할 수 있는지 확인하세요.