해외 결제 연동 안내서 · PayPal·Stripe

국내 PG에서도 계약한 상품과 결제수단에 따라 해외 발급 카드나 해외 간편결제를 받을 수 있습니다. 먼저 지원 국가와 카드 브랜드, 인증 방식, 결제 통화와 정산 통화를 확인합니다. 국내 PG를 사용한다는 이유만으로 원화 결제만 가능하다고 정하지 않습니다. 승인율이 낮다면 발급사 거절과 인증 실패, 상점 설정, 결제수단의 부재를 구분해 봅니다. 실패 코드와 인증 결과를 수집하고 확인할 수 없는 사유는 결제사에 문의합니다. 해외 결제사 추가 여부는 해외에서 들어온 결제 시도와 승인 비율, 국가별 결제 화면 이탈을 바탕으로 판단합니다. 국내 카드와 차이가 보여도 원인을 한 가지로 확정하지 않습니다. 해당 국가의 결제수단 지원과 고객 문의를 함께 보고 기존 계약이나 연동 설정으로 해결할 수 있는 범위를 확인합니다. 추가할 결제사가 있으면 기대하는 개선과 개발·운영·정산 비용을 같은 표에 놓습니다.

해외 결제를 붙일 때는 무엇을 어느 통화로 보여 주고 어느 통화로 청구할지부터 정합니다. 표시 통화는 상품 페이지의 가격이고 결제 통화는 실제로 승인이 나는 통화입니다. 둘을 같게 두면 고객이 본 값이 그대로 청구되지만 환율이 움직일 때마다 가격을 다시 매겨야 합니다. 둘을 다르게 두면 가격은 고정되지만 고객은 자기 카드 명세서에서 다른 숫자를 보고 문의를 넣습니다. 결제 시점에 고객의 통화로 환산해 보여 주는 방식도 있는데, 이때 환율과 그 위에 붙는 마진을 누가 정하는지가 서비스마다 다르므로 화면에 어느 값을 적을지를 함께 정합니다. 구독 상품은 이 결정이 더 무겁습니다. 매달 같은 금액을 청구하려면 통화를 고정해야 하고 통화를 고정하면 환율이 움직인 만큼 나라별 체감 가격이 벌어집니다. 나라별로 가격표를 따로 두는 방식은 매출을 지키지만 요금제와 청구 규칙이 그만큼 늘어납니다. 환불에서도 같은 문제가 돌아옵니다. 결제한 날과 환불하는 날의 환율이 다르면 고객이 받은 금액이 낸 금액과 어긋나고 그 차이를 누가 떠안을지는 정책으로 미리 정해 두지 않으면 건마다 판단이 갈립니다. 표시 통화와 결제 통화, 환불 기준 통화 셋을 한 문서에 적어 두면 고객센터가 같은 답을 내놓습니다.

승인이 났다고 돈이 통장에 들어오는 것은 아닙니다. 해외 결제사는 잔액을 자기 계정에 쌓아 두고 정해진 주기로 상점 계좌에 보냅니다. 여기서 확인할 것이 넷입니다. 지급 통화를 무엇으로 받을지, 원화로 받는다면 환전을 결제사가 하는지 은행이 하는지, 외화 계좌로 받는다면 어느 은행의 어떤 계좌가 필요한지, 첫 정산이 언제 나가는지입니다. 신규 계정에는 대금을 일정 기간 묶어 두는 조건이 붙는 경우가 있고 취소와 분쟁이 늘면 그 비율이 다시 올라갑니다. 환전이 어디서 일어나는지가 실수령액을 가릅니다. 결제사가 원화로 바꿔 보내면 편하지만 환산 조건이 결제사 정책을 따르고 외화로 받아 직접 바꾸면 은행 조건을 고를 수 있는 대신 외화 계좌와 수령 절차가 생깁니다. 재무 쪽에서는 여기에 매출 인식 시점과 실제 입금 시점이 벌어진다는 문제가 하나 더 붙으므로 결제사 잔액과 은행 입금을 서로 다른 두 줄로 관리하는 대사 규칙이 필요합니다. 정산 명세의 항목 구조도 국내와 다릅니다. 거래별 수수료와 통화 변환분, 지급거절로 회수된 금액과 그 처리 비용, 환불로 되돌아간 금액이 한 파일에 섞여 들어오므로 어느 항목을 매출에서 빼고 어느 항목을 비용으로 잡을지를 처음에 정해 둡니다. 이 규칙이 없으면 월 마감마다 같은 판단을 다시 합니다.

해외 판매의 세무 요건은 고객 국가만으로 정해지지 않습니다. 판매 주체와 상품 유형, 판매 국가, 기업 거래인지 소비자 거래인지에 따라 확인할 항목이 달라집니다. 판매할 국가와 거래 구조를 정한 뒤 세무 담당이나 자문가에게 등록과 신고, 세율 적용, 증빙 요건을 확인합니다. 연동 설계에서는 그 판단에 필요한 입력값과 저장 위치를 정합니다. 고객 국가와 청구 주소, 사업자 여부와 등록번호는 해당 거래에서 필요한 범위를 확인해 수집합니다. 가격에 세액을 포함할지, 결제 단계에서 더할지, 청구서와 영수증에 어떤 값을 남길지도 확인한 요건에 맞춥니다. 구독 변경과 환불 때 세액과 문서를 어떻게 수정할지 함께 정하고 검토일과 담당자를 기록합니다. 결제사가 세금 계산 기능을 제공하더라도 적용 범위와 설정 책임을 확인해야 합니다. 출시 전에는 주문 금액과 결제 금액, 세금 기록과 영수증이 같은 거래를 가리키는지 점검합니다.

해외 결제사를 붙이는 일은 API 연동보다 계정 심사에서 시간이 더 듭니다. PayPal과 Stripe는 계정을 여는 법인의 소재 국가에 따라 이용 조건과 지원 기능이 갈리고 개설 단계에서 법인 서류와 대표자 신원 확인, 사업 설명, 예상 거래 규모를 요구합니다. 웹사이트도 심사 대상입니다. 판매하는 것이 무엇인지, 가격과 배송 조건이 적혀 있는지, 환불 정책과 연락처가 게시돼 있는지, 이용약관이 서비스 내용과 맞는지를 봅니다. 국내 심사에서 요구하지 않던 항목이 여기서 나오므로 페이지를 고치는 일이 연동 일정에 들어갑니다. 취급할 수 없는 업종 목록도 결제사가 공개하고 있어 계약 전에 대조합니다. 기능 쪽에서는 국내와 다른 것이 몇 가지 있습니다. 승인과 매입을 나눠 거는 방식, 지역별로 다른 결제수단, 구독 청구와 세금 계산을 결제사 기능으로 받는 방식이 그렇습니다. 국내 PG와 해외 결제사를 함께 쓰는 서비스는 이 차이를 제품 코드에 흩지 않고 하나의 거래 규격 아래 어댑터로 가릅니다. 어느 거래를 어느 결제사로 보낼지는 규칙으로 적습니다. 카드 발급 국가나 고객이 고른 통화, 상품 종류를 조건으로 삼아 경로를 나누고 한쪽이 지연될 때의 우회까지 같은 자리에 둡니다. 주문 번호와 거래 식별자를 두 결제사에서 같은 규칙으로 만들어 두어야 대사와 고객센터 조회가 한 화면에서 끝납니다.

해외 결제에서 새로 생기는 가장 큰 운영 부담이 지급거절입니다. 고객이 상점이 아니라 카드 발급사에 이의를 제기하면 대금이 먼저 회수되고 상점은 정해진 기한 안에 증빙을 올려 다투게 됩니다. 국내 환불이 상점의 판단으로 끝나는 것과 절차가 다릅니다. 대응은 증빙 준비에서 갈립니다. 주문 시각과 접속 기록, 배송 추적 번호와 수령 확인, 디지털 재화라면 계정 활동 로그, 약관 동의 시점과 환불 정책을 보여 준 화면이 필요합니다. 이 자료를 사후에 모으면 기한을 놓칩니다. 거래마다 자동으로 쌓이게 해 두어야 기한 안에 답합니다. 지급거절이 늘면 결제사가 대금 유보 비율을 올리거나 계정 조건을 다시 보므로 비율 자체를 지표로 관리합니다. 분쟁을 줄이는 쪽도 함께 봅니다. 명세서에 찍히는 상점 이름을 고객이 알아보게 적고 구독은 청구 전에 안내를 보내고 환불 요청 창구를 결제사보다 찾기 쉬운 자리에 두면 이의 제기로 넘어가기 전에 끝나는 건이 늘어납니다. 부정 사용으로 들어오는 지급거절은 성격이 달라 대응도 다릅니다. 카드 정보를 훔쳐 쓴 거래는 증빙을 아무리 붙여도 상점이 대금을 지키기 어려우므로 승인 앞에 위험도 판정을 두어 애초에 통과시키지 않는 쪽이 비용이 적습니다. 판정을 어디에 둘지와 어느 거래에 추가 인증을 걸지는 결제수단과 상품 성격에 따라 갈리므로 연동 설계 단계에서 함께 정합니다.