Stripe Connect 판매자 적자가 플랫폼 은행까지 번지는 조건

Summary

환불이나 지급 분쟁은 우선 결제가 기록된 연결 계정에서 처리된다. 그 계정의 손실을 플랫폼이 부담하고 판매자 자금이 부족하면 Stripe는 플랫폼에 reserve_transaction을 만든다. 플랫폼 사용 가능 잔고도 모자라면 마이너스로 내려가고 연결 은행 계좌에서 인출을 시작한다.
판매자 적자가 줄면 준비금 일부가 플랫폼으로 돌아올 수 있다. 적자가 180일 지속되면 connect_collection_transfer가 준비금을 판매자 계정으로 옮겨 음수 잔고를 없앤다.

한 상점의 서랍이 본사 금고에 연결된다

판매가 끝난 뒤 구매자가 환불을 요구한다. Stripe는 먼저 그 거래가 일어난 연결 계정에서 돈을 찾는다. 판매자가 Stripe 잔고나 연결 은행 계좌로 환불 또는 지급 분쟁을 감당하지 못하고, 플랫폼이 그 계정의 손실을 맡은 경우 자금 부족은 운영사로 넘어온다. ‘준비금’이라는 말이 점잖게 들려도 그 안에서는 실제로 누가 돈을 내는지가 바뀐다.

손실 책임이 플랫폼에 있는 연결 계정이 마이너스가 되면 Stripe는 플랫폼 측에 reserve_transaction을 기록한다. 사용 가능 잔고가 충분하면 그 돈이 준비금을 채운다. 모자라면 플랫폼 잔고도 음수가 되고, Stripe는 플랫폼의 연결 은행 계좌에서 부족분을 인출하기 시작한다. 모든 판매자나 모든 환불에 적용되는 경로가 아니다. 책임 배분과 양쪽의 자금 상태가 충족돼야 은행까지 이어진다.

Accounts v2의 defaults.responsibilities.losses_collector가 책임을 가른다. application이면 플랫폼이 연결 계정의 음수 잔고를 부담하고, stripe이면 Stripe가 부담한다. 어느 쪽이든 플랫폼 자신의 계정에 생긴 음수는 플랫폼 책임이다. Stripe 문서는 Merchant 구성을 추가할 때 이 값을 정하며 그 뒤에는 같은 방식으로 바꿀 수 없다고 한다. 판매자 등록 과정의 기술적 선택이 플랫폼 자금의 사용권을 정하는 셈이다.

준비금은 적자와 함께 움직인다. Stripe는 플랫폼이 책임지는 연결 계정의 음수 잔고 합계와 준비금이 대체로 같아야 한다고 설명하면서 데이터 반영 지연 가능성도 적는다. 판매자가 새 결제로 적자를 줄이면 준비금 조정분이 플랫폼 사용 가능 잔고로 풀린다. 적자가 180일 남아 있으면 connect_collection_transfer가 준비금에서 연결 계정으로 돈을 옮기고 그 계정의 음수를 0으로 만든다. 플랫폼이 그 전에 직접 송금해 적자를 메울 수도 있다. 시간이 손실을 없애 주는 마술은 아니다.

공개 자료에는 특정 플랫폼의 은행 인출 사례나 손실액이 없다. 실제 사건을 확인하려면 책임 설정, 환불과 분쟁, 준비금 거래, 은행 기록이 필요하다. 그래도 사업 판단은 명확하다. 판매자에게 결제 창구를 열어 주는 일이 때로는 플랫폼의 유동성을 빌려 주는 일까지 포함한다. 그 약속에는 가격과 한도가 있어야 한다.