Merchant Adoption은 상점과 서비스 업체가 고객이 실제로 쓸 수 있는 bitcoin 결제를 도입하는 것입니다. 오프라인 매장과 온라인 쇼핑몰을 모두 포함합니다. 다만 bitcoin을 받는 것과 오래 보유하는 것은 다릅니다. 직접 받을 수도 있고, 약정된 조건에 따라 다른 통화로 정산하는 서비스를 이용할 수도 있습니다.
지도에 Bitcoin을 받는 곳으로 등록됐지만 오늘 근무자는 결제를 시작하는 법을 모르는 매장을 생각해 보세요. 그 정보는 고객에게 별 도움이 되지 않습니다. 구체적인 지점, 지원 방식, 확인 날짜를 점검해야 합니다. 그래서 BTC Map은 현지 기여자와 기존 장소의 반복 확인에 의존합니다. 시험 구매에 성공하면 그 순간 절차가 작동한다는 것은 알 수 있습니다. 정기 이용자가 몇 명인지는 알 수 없으며, 정해진 기간의 실제 구매를 관찰해야 합니다. [1]
상인은 자신이 키를 통제하는 지갑으로 bitcoin을 받을 수 있습니다. 키는 자금을 쓸 권한을 주므로 백업도 보호해야 합니다. 다른 방법은 업체가 결제를 처리하고 지원하는 현지 통화로 정산받는 것입니다. BitPay는 이런 방식을 설명합니다. 고객은 bitcoin을 내지만 상인은 계속 그 시세 변동을 감수할 필요가 없습니다. 정산 전 누가 자금을 통제하는지, 언제 지급하는지, 조건과 한도가 무엇인지 알아보세요. 결제 수단과 자금 보관 방식은 별개의 선택입니다. [2] [3]
계산대는 구매와 금액, 결제 방식을 연결합니다. BTCPay Server는 이를 invoice라고 부릅니다. 일정 시간 동안 금액과 환율을 정하는 결제 요청입니다. 고객은 주문에 얼마를 보내야 하는지 알 수 있습니다. 기한이 지난 요청, 부족한 입금, 초과 입금은 따로 처리해야 합니다. 보내기 전에 금액과 수취인, 올바른 네트워크를 확인해야 합니다. QR 코드는 정보를 지갑으로 옮길 뿐, 그 정보의 정확성이나 올바른 주문과의 연결을 자체적으로 보장하지 않습니다. [4]
고객이 송금 완료 화면을 보여 줘도 직원은 자기 시스템을 확인합니다. BTCPay Server의 Processing은 요청 금액이 지급됐지만 블록 내 거래 확인 같은 완료 조건이 아직 남았다는 뜻입니다. Settled는 그 조건이 충족되었다는 뜻입니다. Lightning 결제는 보통 블록 확인을 기다리지 않습니다. 상품 인도는 매장 정책, 결제 방식, 구매 금액에 따릅니다. 상태를 수동으로 바꾸는 것은 네트워크 확인의 증거가 아니므로 비정상적인 결제는 먼저 검증해야 합니다. [4]
Lightning Network는 참여자 사이에 미리 만든 연결인 결제 채널을 통해 빠르게 지급합니다. 수취하려면 연결이 가능해야 하고 인바운드 유동성, 즉 그 채널로 추가 자금을 받을 여유가 필요합니다. 이는 상인이 이미 가진 금액과 다릅니다. 결제 소프트웨어를 실행하는 컴퓨터인 자체 노드를 운영하면 채널 관리와 지속적인 유지가 필요합니다. 서비스는 일을 간단하게 만들지만 상인은 그 운영에 의존하며, 모델에 따라 돈까지 맡길 수 있습니다. [2]
솔루션을 고를 때 광고 속 한 가지 요율만 비교해서는 안 됩니다. 네트워크 및 서비스 수수료 외에도 적용 환율과 비교 기준 환율의 차이에 비용이 들어갈 수 있습니다. 인바운드 유동성, 장비, 유지보수, 직원 시간도 고려하세요. 자체 관리는 통제권과 함께 가동 책임을 줍니다. 더 간단한 서비스에는 한도와 업체 중단 또는 실패 위험이 있을 수 있습니다. 다음 근무조도 장애나 잘못된 금액의 처리 방법까지 알아야 합니다. [2] [4]
대사를 위해 주문, 결제, 환율, 수수료, 업체 정산 사이의 관계를 남겨야 합니다. BTCPay Server는 보고서를 내보낼 수 있지만 그것만으로 현지 회계 의무 준수를 보장하지는 않습니다. 환불은 원래 거래를 지우는 것이 아니라 새로 지급하는 것입니다. 통화와 금액 계산법을 미리 정하고 고객의 수취 정보를 확인하세요. BTCPay에 문서화된 절차에서는 환불 링크만 만들어서는 끝나지 않습니다. 고객이 받을 곳을 지정한 뒤 실제 지급 처리가 필요합니다. [5] [6]
중요한 질문은 “몇 곳을 추가했나?”만이 아니라 “지금도 결제가 되나, 고객이 다시 오나?”입니다. 정상 운영 매장, 성공한 구매, 반복 사용, 결제 문제를 각각 추적하세요. 같은 기간과 정의로 비교하고 폐점과 오래된 정보도 기록합니다. 현지 지원과 정기 점검은 실제 사용 가능성을 유지합니다. 장소 수는 고객 수가 아니며 Bitcoin을 받는 것만으로 매출 증가나 Bitcoin 가격 상승이 보장되지는 않습니다. [1] [5]
커피값은 냈지만 질문은 남는다
가상의 카페에서 직원이 특정 주문에 대한 요청을 만듭니다. 고객은 이를 스캔하고 Lightning Network로 결제합니다. 직원은 자기 시스템에서 실제 입금을 확인하고 판매를 마칩니다. 휴대전화 사진만으로는 부족합니다. 이 구매는 당시 절차가 작동함을 보여 줄 뿐 단골 수를 말해 주지는 않습니다. 카페가 bitcoin을 보유하는지 업체에서 다른 통화로 받는지는 별도로 기록합니다.
더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 Bitcoin Point of Sale, Bitcoin Payment Processor, BTC Map, Lightning Network, Medium of Exchange, Grassroots Bitcoin Adoption. 다음 항목에서도 이 글을 참조합니다 Bitcoin Pizza Day, Paralelní Polis(평행 폴리스), Bitcoin Coffee, BTC Prague.
01상인은 받은 bitcoin을 계속 보유해야 하나요?+
아닙니다. 직접 관리하거나 지원되는 현지 통화로 정산하는 업체를 쓸 수 있습니다. 수수료와 지급 조건, 지급 전 누가 자금을 통제하는지 알아야 합니다. “고객이 bitcoin으로 냈다”는 말만으로 상인이 최종적으로 받는 통화를 알 수는 없습니다.
02스티커나 지도만으로 결제 지원을 확인할 수 있나요?+
발표되거나 등록된 선택지를 보여 주지만 정보가 오래됐을 수 있습니다. 해당 장소에서 오늘 결제 절차 전체가 작동하는지 확인하세요. 장기 사용을 판단하려면 실제 구매와 반복 구매 데이터도 필요합니다. 한 번의 성공적인 시험은 이를 대신하지 못합니다.