온라인 상점의 주문, 결제, 잔액, 은행 지급과 환불 기록을 맞추는 방법을 설명합니다. 가상 계산과 Stripe 공식 문서로 상태·수수료·통화를 구분합니다.
스테이블코인 결제 대사 핵심 정리
스테이블코인 결제 대사는 주문 기록과 결제·수수료·지급·환불 기록을 연결해 차액의 원인을 확인하는 작업입니다. 결제 성공 표시만으로 은행 입금이나 환불까지 완료됐다고 판단하면 안 됩니다.
주문 ID와 결제 ID를 먼저 연결하고, 결제 총액에서 수수료와 환불액을 뺀 금액을 사업자 잔액·은행 지급 기록과 대조하세요. 통화와 처리 기간이 다른 기록은 같은 표에 단순 합산하지 않습니다.
결제 대사는 주문 내역, 결제 처리 기록, 사업자 잔액, 은행 입금과 환불 기록이 서로 맞는지 확인하는 작업입니다. 고객이 코인을 보냈다는 사실만으로 주문 처리와 은행 정산이 모두 끝난 것은 아닙니다. 스테이블코인 결제에서는 통화·네트워크·수수료·상태를 나누어 기록하는 것이 출발점입니다.
네 가지 기록은 역할이 다릅니다
| 기록 | 확인하려는 질문 | 연결할 식별자 예시 |
|---|---|---|
| 주문 | 무엇을 얼마에 판매했나? | 자체 주문번호 |
| 결제 | 제공자가 결제를 성공 처리했나? | PaymentIntent·결제 ID |
| 잔액·정산 | 수수료 후 얼마가 언제 사용 가능해졌나? | 잔액 거래·지급 ID |
| 환불 | 어느 주문에 얼마를 어떤 상태로 돌려줬나? | 환불 ID·원결제 ID |
위 표는 편집부의 운영 설계 예시입니다. 사업자마다 제공되는 필드가 다르며 블록체인 거래 해시를 항상 받을 수 있는 것도 아닙니다. 조회되지 않는 정보는 추정해 채우지 말고, 제공자가 지원하는 식별자를 기록해야 합니다.
결제 성공과 은행 입금을 분리합니다
Stripe의 잔액 거래 객체는 총액, 수수료, 순액, 통화, 사용 가능 시점과 상태 등을 구분합니다. 순액은 해당 거래의 총액에서 수수료를 뺀 잔액 영향이며, available과 pending도 구별합니다. 이것을 곧바로 특정 은행 입금 완료와 동일시해서는 안 됩니다. Stripe 잔액 거래 문서.
운영표에는 고객 결제 통화와 사업자 정산 통화를 별도 열로 두는 것이 좋습니다. USDC 100개와 원화 100원, 달러 100달러는 같은 숫자라고 합산할 수 없습니다. 환산이 있었다면 적용 기준·시각·환율을 확인 가능한 기록과 함께 남깁니다.
가상의 하루 매출을 맞춰 보겠습니다
실제 서비스 요율이 아닌 연습입니다. 주문 A의 총액이 100달러, 처리 수수료가 2달러이고, 이후 20달러 부분 환불이 발생했다고 가정합니다. 환불 시 최초 수수료는 반환되지 않고 다른 비용·조정은 없다고 가정합니다.
- 결제에 따른 잔액 증가: 100 – 2 = 98달러.
- 부분 환불에 따른 감소: 20달러.
- 두 거래의 합산 순영향: 78달러.
그러나 그날 은행 입금이 반드시 78달러인 것은 아닙니다. 사용 가능 시점, 지급 묶음, 이전 잔액이나 다른 주문이 포함될 수 있습니다. ‘주문별 순영향’과 ‘하루 은행 입금액’을 억지로 같게 만들면 오히려 기록이 틀릴 수 있습니다.
지급 방식에 맞는 보고서를 고릅니다
Stripe의 Payout reconciliation 보고서는 자동 지급 묶음을 맞추는 데 최적화돼 있습니다. 일반적인 수동 지급 이용자는 Balance 보고서를 보도록 안내하며, 즉시 지급은 사용자가 선택한 시점·금액 때문에 어떤 거래가 포함됐는지 별도 대조 책임이 있음을 설명합니다. 지급 대사 보고서.
여기서 배울 점은 특정 보고서 하나가 모든 상점에 정답은 아니라는 것입니다. 사업자의 지급 방식, 보고서 시간대, 조회 기간을 먼저 맞추고 총액을 비교해야 합니다. 자동화하려면 금액이 맞지 않는 건을 조용히 지우는 대신 예외 목록으로 남겨야 합니다.
환불은 원래 결제를 지우는 일이 아닙니다
Stripe의 스테이블코인 결제 문서는 환불이 스테이블코인으로 고객의 원래 지갑에 돌아간다고 안내합니다. 환불 요청과 최종 상태는 구분해 관리해야 하며, 실패·대기 가능성과 제공자 안내는 환불 문서에서 확인합니다. 스테이블코인 결제 조건.
운영표에서 원주문을 삭제하면 부분 환불, 중복 요청, 정산 후 환불을 추적하기 어려워집니다. 원결제에 연결된 별도 환불 행을 남기고, 요청액과 처리 상태를 구분하는 방식이 이해하기 쉽습니다. 이는 장부 운영 예시이지 개별 기업의 회계·세무 분개 지침이 아닙니다.
예외 목록에 남길 항목
- 결제 제공자는 성공인데 자체 주문이 미결제로 남은 경우.
- 같은 주문에 둘 이상의 결제 기록이 붙은 경우.
- 잔액은 증가했으나 예상한 지급 묶음에 없는 경우.
- 환불을 요청했지만 최종 상태가 확인되지 않은 경우.
- 통화·시간대·수수료 범위가 서로 다른 경우.
편집부 해설: 자동 처리는 이미 확인된 상태와 식별자를 기준으로 해야 합니다. 이름이나 금액이 비슷하다는 이유만으로 다른 주문을 합치지 마세요. 고객정보 접근 권한과 보관 기간도 운영 정책에 포함해야 합니다.
자주 묻는 질문
거래 해시만 있으면 주문 처리를 완료해도 되나요?
해당 결제 방식에서 제공자가 요구하는 완료 확인을 따라야 합니다. 온체인 기록과 주문·결제 상태는 별개일 수 있습니다.
매출 총액과 은행 입금액은 항상 같아야 하나요?
아닙니다. 수수료·환불·조정·시점·지급 묶음을 대조해 차이를 설명해야 합니다.
한국 사업자도 이 서비스를 바로 사용할 수 있나요?
이 글은 운영 기록의 원리 설명입니다. 사업자 소재지와 계정의 최신 지원 조건을 별도로 확인해야 합니다.
이어서 읽기
자료 확인: 2026-09-10. 계산·체크리스트는 가상의 운영 예시입니다. 실제 도입은 이용 자격·계약·보안·회계·법률 검토가 필요합니다.
편집: K-스테이블코인넷 편집팀 · 2026.09.10 검색 제목·핵심 설명·분류·문서 구조 보강. 자료와 수치의 기준일은 각 본문 표기를 따릅니다. 편집 원칙 · 사이트 소개