494 / 691MERCHANT

Merchant Adoption

상점의 비트코인 결제 도입

상품과 서비스 대금을 비트코인으로 받으려면 작동하는 계산대, 결제 검증, 운영 절차가 필요합니다. 지속적인 이용 가능성과 실제 구매는 발표나 매장 스티커보다 더 강한 증거입니다.

Merchant Adoption은 오프라인 매장과 온라인 상점에서 비트코인 결제를 도입하고 사용하는 것을 뜻합니다. 고객의 비트코인 결제 가능성, 자금 수취 및 정산 방식, 상인의 비트코인 계속 보유 결정은 구분해야 합니다.

지도 등록이나 통합 발표가 직원이 오늘 결제를 받을 수 있음을 입증하지는 않습니다. 구체적인 매장, 지원 결제 방식, 검증 날짜를 확인합니다. BTC Map은 지속적인 재검증과 지역 기여자 지원을 설명합니다. 결제가 작동한다고 단골을 입증하는 것도 아니며, 일정 기간의 실제 사용 자료가 필요합니다. [BTC Map — Verification and local maintenance]

상인이 키를 직접 통제하면 자신의 지갑으로 자금을 받고 보안에 책임집니다. 제공업체는 결제를 처리하고 합의된 선택지에 따라 현지 통화로 바꿀 수 있으며 BitPay가 이런 정산을 문서화합니다. 따라서 상인이 장기 보유하지 않아도 고객은 비트코인으로 지불할 수 있습니다. 지급 전에 누가 자금을 통제하는지, 한도와 조건은 무엇인지 확인합니다. [BTCPay Server — Lightning options and custody] [BitPay — Configuring settlements]

계산대는 주문을 금액, 통화, 결제 요청과 연결합니다. BTCPay Server의 일반 청구서는 제한된 시간 동안 환율을 고정합니다. 만료 후 결제, 부족 결제, 초과 결제는 별도 처리가 필요합니다. 보내기 전 금액, 네트워크, 수취인이 일치해야 하며, 주문과 연결되지 않은 QR만으로는 명확한 대사가 어렵습니다. [BTCPay Server — Invoice lifecycle]

고객 화면 캡처는 수취 확인이 아닙니다. 직원은 자신의 시스템에서 상태를 검증합니다. BTCPay Server는 설정된 확인을 기다리는 Processing과 Settled를 구분하며, 성공한 Lightning 결제는 바로 Settled로 전환됩니다. 수동으로 표시한 상태는 새로운 네트워크 증거가 아닙니다. 상품 인도 규칙은 결제 방식과 주문 가치를 고려해야 합니다. [BTCPay Server — Invoice lifecycle]

Lightning Network는 빠른 계산대 결제를 돕지만 연결과 수취 능력이 필요합니다. 자체 노드는 채널과 인바운드 유동성 관리가 필요합니다. 서비스가 이 일을 맡으면 운영에 의존하게 되고, 모델에 따라 자금 수탁에도 의존합니다. 지갑 잔액만으로 충분한 인바운드 유동성을 입증할 수는 없습니다. [BTCPay Server — Lightning options and custody]

광고 요율 하나만 보지 말고 네트워크·서비스 수수료, 환전 스프레드, 유동성 비용, 장비 운영비를 비교합니다. 직원 교육과 장애·예외 결제 처리도 포함합니다. 자체 관리는 통제권을 주지만 유지보수가 필요하며, 간편한 서비스는 한도와 제공업체 위험을 더할 수 있습니다. 직원 교대 후에도 결제 수단을 사용할 수 있어야 합니다. [BTCPay Server — Lightning options and custody] [BTCPay Server — Invoice lifecycle]

주문마다 결제 연결 정보, 적용 환율, 수수료, 후속 정산을 보관합니다. BTCPay Server는 결제 보고서 내보내기를 제공하지만 내보내기만으로 현지 회계 의무 충족 여부가 결정되지는 않습니다. 환불은 원래 거래를 고치는 것이 아니라 다른 결제입니다. 반환 통화와 금액 계산 방식을 미리 정하고 수취인 정보를 확인합니다. 문서화된 BTCPay 절차에도 후속 지급 처리가 필요합니다. [BTCPay Server — Reporting] [BTCPay Server — Refunds]

활성 매장, 성공한 구매, 반복 사용, 결제 문제를 따로 추적합니다. 동일 기간과 정의를 비교하며 폐점과 오래된 정보도 기록합니다. 지역 지원과 지속적인 검증은 서비스 운영 유지에 도움이 됩니다. 추가 장소 수는 고객 수가 아니고, 결제 수락만으로 매출 증가나 비트코인 가격 상승이 보장되지는 않습니다. [BTC Map — Verification and local maintenance] [BTCPay Server — Reporting]

예시 · MERCHANT

서로 다른 두 증거가 있는 카페

가상의 카페에서 스티커가 비트코인 수락을 알립니다. 직원은 주문용 요청을 만들고 고객은 Lightning Network로 결제합니다. 이 구매를 입증하는 것은 카페 시스템의 수취 상태이며, 스티커나 고객 휴대전화의 사진으로는 부족합니다. 성공한 결제 한 번으로 단골 수를 알아낼 수는 없습니다. 이후 정산 방식은 별도로 기록합니다.

더 정확히 이해하려면 이 항목과 함께 다음도 읽어 보세요 Bitcoin Point of Sale, Bitcoin Payment Processor, BTC Map, Lightning Network, Medium of Exchange, Grassroots Bitcoin Adoption. 다음 항목에서도 이 글을 참조합니다 Bitcoin Pizza Day, Bitcoin Coffee, BTC Prague, Alza Bitcoin payments.

01상인은 받은 비트코인을 장기 보유해야 하나요?

아니요. 직접 관리해 보유하거나 지원되는 현지 통화 정산을 제공하는 업체를 이용할 수 있습니다. 비트코인 결제를 받는다고 상인이 최종적으로 어떤 통화로 돈을 받는지 알 수는 없습니다. 조건, 수수료, 자금 통제는 선택한 방식에 달려 있습니다.

02스티커나 지도 등록만으로 도입의 증거가 되나요?

기껏해야 발표되거나 기록된 선택지를 보여 줍니다. 현재 작동 여부는 구체적인 장소와 결제 절차를 확인해야 합니다. 지속 사용을 판단하려면 실제 반복 구매 자료도 필요하며 한 번의 검증이 이를 대신하지는 못합니다.

₿ / 지도
전 세계 비트코인 결제처 지도 열기

가맹점 채택이라는 개념에서 실제로 오늘 비트코인을 받는 장소로 이동합니다.

↗
DOC · 001BTC Map — Verification and local maintenance1차 출처 ↗DOC · 002BTCPay Server — Lightning options and custody문서 ↗DOC · 003BitPay — Configuring settlements문서 ↗DOC · 004BTCPay Server — Invoice lifecycle문서 ↗DOC · 005BTCPay Server — Reporting문서 ↗DOC · 006BTCPay Server — Refunds문서 ↗
1차 출처 우선 · 투자 조언이 아닙니다