결제와 정산이 들어가는 앱, 베트남에서 먼저 정해야 할 것

앱 안에서 돈이 오가기 시작하면 무엇이 달라지는가

결제가 붙는 순간 앱은 소프트웨어를 넘어 자금 흐름의 한 구간이 됩니다. 돈이 누구 계좌로 들어가는지, 환불은 누가 책임지는지, 기록은 어디에 얼마나 남는지가 한꺼번에 생깁니다. 베트남에서 서비스한다면 여기에 통화와 현지 결제 관행, 사업자 자격 요건이 더 얹힙니다. 기술 선택보다 구조 결정이 먼저입니다.

기능 목록만 놓고 보면 결제는 화면 하나가 늘어나는 일처럼 보입니다. 장바구니 다음에 결제 수단 선택이 오고 성공 화면이 뜨면 끝인 것 같습니다. 실제로 늘어나는 것은 화면이 아니라 책임입니다. 결제는 실패했는데 돈은 빠져나간 경우, 같은 요청이 두 번 들어와 두 번 청구된 경우, 사용자가 취소를 눌렀는데 판매자는 이미 물건을 보낸 경우를 서비스가 스스로 판정하고 복구해야 합니다. 이 판정 규칙은 코드보다 먼저 사업 쪽에서 합의돼 있어야 합니다.

베트남 시장에서 특히 갈리는 지점은 결제 수단의 폭입니다. 은행 계좌 이체, QR 코드 결제, 전자지갑, 카드, 물건을 받고 현금을 내는 방식이 한 서비스 안에 섞여 들어옵니다. 수단마다 승인과 취소가 도달하는 시점이 다르고, 실패를 알려주는 방식도 다릅니다. 어떤 수단은 몇 초 안에 확정되고, 어떤 수단은 사람이 확인해야 확정됩니다. 이 차이를 화면 하나 뒤에 감추려면 뒤쪽 상태 관리가 훨씬 촘촘해야 합니다. 화면은 단순해 보이는데 서버가 복잡해지는 전형적인 구간입니다.

되돌리기 비용도 다릅니다. 일반 기능은 잘못 만들었으면 다음 배포에서 고치면 됩니다. 돈이 오간 기록은 고쳐 쓸 수 없습니다. 이미 나간 정산을 되감으려면 사람과 사람 사이의 협의가 필요하고, 그 과정에서 신뢰가 먼저 소모됩니다. 결제가 들어가는 프로젝트에서 착수 전 질문의 밀도가 다른 프로젝트보다 높아야 하는 이유가 여기 있습니다.

착수 전에 답이 있어야 하는 질문은 대체로 넷으로 모입니다. 돈을 실제로 받는 주체는 누구인가. 그 돈이 최종 수령인에게 가기까지 몇 번 손을 바꾸는가. 문제가 생겼을 때 사용자에게 책임지는 이름은 무엇인가. 나중에 이 흐름을 증빙해야 한다면 어떤 기록이 남아 있어야 하는가. 넷이 정해지면 결제 연동 자체는 오히려 평범한 작업이 됩니다. 정해지지 않은 채 개발이 시작되면 연동은 끝나도 서비스는 열지 못합니다.

한 가지 덧붙이면, 결제를 붙인 앱은 운영 부담도 같이 커집니다. 대사 작업, 문의 응대, 환불 처리, 월 마감이 매일 또는 매주 반복됩니다. 개발 견적에는 잘 잡히지 않지만 실제 사람이 들어가는 영역입니다. 팀이 작다면 결제 범위를 처음부터 넓게 잡기보다, 운영으로 감당할 수 있는 만큼만 열고 늘려가는 편이 낫습니다. 저희가 자체 제품을 직접 운영하면서 반복해서 확인한 지점도 이쪽입니다. 만드는 일보다 만든 뒤에 매일 도는 일이 조직의 체력을 정합니다.

수취 주체와 정산 주체를 먼저 정해야 하는 이유

수취 주체는 사용자의 돈이 처음 들어오는 법적 주체이고, 정산 주체는 그 돈을 최종 수령인에게 나눠 보내는 주체입니다. 둘은 같을 수도 있고 다를 수도 있습니다. 이 선택이 계약 문구, 영수증과 증빙, 환불 책임, 회계 처리, 그리고 요구되는 사업자 자격을 함께 결정합니다.

가장 흔한 오해는 이것을 기술 설정값으로 여기는 것입니다. 결제 연동 문서에 판매자 계정을 등록하는 항목이 있으니 그 칸에 무엇을 넣을지만 정하면 된다고 생각하기 쉽습니다. 실제로는 그 칸에 들어가는 이름이 곧 사용자와 계약하는 당사자입니다. 사용자가 환불을 요구할 때, 세무 당국이 거래 근거를 물을 때, 분쟁이 소비자 보호 절차로 갈 때 앞에 서는 이름이 그 이름입니다. 화면에 표시되는 브랜드와 실제 수취 주체가 다르면 그 간극은 언젠가 문제로 돌아옵니다.

여러 참여자가 있는 서비스에서는 갈래가 둘로 나뉩니다. 하나는 플랫폼이 대금을 한 번 모았다가 정산해 보내는 방식입니다. 다른 하나는 대금이 판매자나 제공자에게 바로 가고 플랫폼은 수수료만 별도로 받는 방식입니다. 앞쪽은 사용자 경험이 매끄럽고 분쟁 처리도 한 곳에서 됩니다. 대신 남의 돈을 일시적으로 보관하고 대신 전달하는 성격이 생깁니다. 그 성격이 어디까지 허용되는지, 별도의 자격이나 등록이 필요한지는 사업 형태와 현지 규정에 따라 달라지므로 반드시 현지 자문으로 확인해야 합니다. 뒤쪽은 그 부담이 줄어드는 대신 판매자마다 계정과 정산이 흩어지고, 환불과 분쟁이 플랫폼 손을 떠납니다.

국경이 걸리면 한 겹이 더해집니다. 개발사가 한국에 있고 서비스가 베트남에서 돌아가는 구성은 흔합니다. 이때 소프트웨어를 만드는 주체와 돈을 받는 주체가 같아야 할 이유는 없습니다. 오히려 갈라두는 편이 정상적인 구조인 경우가 많습니다. 저희가 여러 서비스 구조를 검토하면서 반복해서 마주한 판단이 하나 있습니다. 정산 투명성이 서비스의 핵심 가치인 경우, 자금을 받고 나눠 보내는 주체는 현지에 실체가 있어야 한다는 것입니다. 이것은 개발로 우회할 수 있는 문제가 아닙니다. 우회를 시도하면 기술적으로는 동작하지만 사업적으로는 열 수 없는 서비스가 됩니다.

그래서 순서를 뒤집지 않는 편이 낫습니다. 법인과 계약 구조를 먼저 세우고, 그 구조에 맞는 결제 수단과 정산 흐름을 고르고, 마지막에 코드를 씁니다. 반대로 가면 이미 만든 것을 버리게 됩니다. 결제 연동은 데이터 모델과 상태 기계, 권한 체계에 깊이 스며들기 때문에, 수취 주체가 바뀌면 화면 몇 개가 아니라 서버의 뼈대가 바뀝니다.

정하는 과정에서 문서로 남겨두면 좋은 것이 있습니다. 자금이 이동하는 각 구간마다 보내는 쪽과 받는 쪽의 이름, 이동의 근거가 되는 계약, 그 구간에서 발생하는 수수료와 세금 처리, 문제가 생겼을 때 되돌리는 방법. 이 표 한 장이 있으면 개발팀과 회계, 자문이 같은 그림을 놓고 이야기할 수 있습니다. 이 표가 없으면 각자 다른 그림을 머릿속에 두고 합의한 줄 착각하게 됩니다.

스토어 인앱결제와 외부 결제의 갈림길

모바일 앱이라면 앱 스토어의 인앱결제를 써야 하는지, 자체 결제 수단을 붙여도 되는지가 초기에 갈립니다. 대체로 앱 안에서만 소비되는 디지털 재화와 구독은 스토어 결제 대상이 되고, 실물 재화나 앱 밖에서 제공되는 서비스는 외부 결제 여지가 있습니다. 다만 기준과 예외는 계속 바뀝니다.

이 갈림길이 중요한 이유는 수수료 때문만이 아닙니다. 인앱결제를 쓰면 대금을 받는 주체가 스토어가 되고, 정산 주기와 통화 환산, 환불 판정이 스토어 규칙을 따릅니다. 사업자는 스토어로부터 정산을 받는 위치에 서게 됩니다. 외부 결제를 쓰면 대금이 사업자 쪽으로 바로 들어오고, 정산과 증빙과 환불을 직접 설계하고 직접 책임집니다. 같은 매출이라도 회계에 잡히는 모양과 자금이 도는 속도가 다릅니다.

구체적인 수수료율, 소규모 사업자 대상 예외, 외부 결제 안내나 링크를 어디까지 허용하는지는 스토어 정책 문서에 있고 시기와 지역에 따라 달라집니다. 이 글에서 그 숫자와 조건을 단정하지 않는 이유가 그것입니다. 심사에 넣기 전에 각 스토어의 최신 정책 문서를 직접 읽고, 경계에 걸리는 부분은 심사 문의로 사전에 확인해야 합니다. 지난해 통과했던 방식이 올해도 통과한다는 보장은 없습니다.

베트남 서비스에서 이 판단이 특히 헷갈리는 자리가 있습니다. 앱 안에서 결제하지만 실제 제공은 오프라인 매장이나 사람이 하는 경우입니다. 예약, 수업 매칭, 방문 서비스가 여기에 들어갑니다. 이런 서비스는 겉보기에 앱 안 결제지만 제공 실체가 앱 밖에 있어 판단이 갈릴 수 있습니다. 저희가 만든 서비스 중에도 배우는 사람과 가르치는 사람을 잇는 매칭 형태가 있는데, 이런 구조에서는 앱이 만남을 잇는 자리이고 실제 제공과 대가 관계는 참여자 사이에 있다는 점을 설계 단계에서 분명히 해두는 편이 안전합니다. 이 구분이 흐리면 스토어 심사와 현지 요건 양쪽에서 동시에 질문을 받습니다.

설계 측면의 권고는 단순합니다. 결제를 한 가지 방식에 못 박지 마십시오. 주문과 상품, 가격, 환불을 다루는 도메인 계층을 결제 수단과 분리해두면, 나중에 인앱결제와 외부 결제를 함께 굴리거나 한쪽으로 옮길 때 바꿔야 할 범위가 줄어듭니다. 영수증 검증, 구독 상태 동기화, 환불 통지 수신처럼 스토어에만 있는 절차는 어댑터 안쪽에 가두는 편이 좋습니다.

둘을 함께 쓰는 하이브리드 운영을 택했다면 회계 대사가 두 갈래로 늘어난다는 점을 미리 계산해야 합니다. 스토어 정산 명세와 자체 결제 내역은 통화 표기, 확정 시점, 환불 반영 방식이 서로 다릅니다. 월말에 숫자가 맞지 않는 대부분의 원인이 여기서 나옵니다. 처음부터 양쪽 기록을 같은 원장 형식으로 정규화해 쌓아두면, 나중에 사람이 손으로 맞추는 시간을 크게 줄일 수 있습니다.

정산 투명성이 필요한 서비스의 구조

한 번의 결제가 둘 이상의 수령인에게 나뉘는 서비스라면 정산은 부가 기능이 아니라 제품의 본체입니다. 마켓플레이스, 매장 운영 플랫폼, 매칭 서비스, 배차와 배달이 여기 들어갑니다. 이런 서비스에서 참여자가 가장 먼저 확인하는 것은 화면의 완성도가 아니라 내 몫이 맞게 들어왔는지입니다.

기록부터 시작해야 합니다. 거래 원장은 덮어쓰지 않고 쌓기만 하는 구조가 안전합니다. 상태를 한 칼럼에 저장해 계속 갱신하면 지금 값은 알 수 있어도 어떤 경로로 여기 왔는지는 사라집니다. 결제 승인, 취소, 부분 환불, 수수료 차감, 보류 해제를 각각 한 줄씩 남기고 현재 잔액은 그 줄들의 합으로 계산하면, 분쟁이 생겼을 때 설명할 수 있는 서비스가 됩니다. 설명할 수 있다는 점이 곧 신뢰입니다.

중복과 순서 문제도 미리 잡아야 합니다. 결제 요청은 네트워크 사정으로 두 번 도착할 수 있고, 결제사가 보내는 알림은 순서가 뒤바뀌거나 여러 번 올 수 있습니다. 같은 거래를 몇 번 처리해도 결과가 한 번 처리한 것과 같도록 키를 잡아두는 설계가 필요합니다. 알림 수신은 재시도를 전제로 만들고, 알림만 믿지 말고 결제사 쪽 상태를 다시 조회해 맞춰보는 절차를 넣는 편이 안전합니다. 이 세 가지가 없으면 대사 단계에서 사람이 매일 손으로 메워야 합니다.

통화 처리도 미리 규칙을 정해야 합니다. 베트남 동은 실무에서 소수점 아래를 쓰지 않는 통화입니다. 수수료율을 곱하면 반드시 나머지가 생기고, 그 나머지를 누가 가져가는지, 어떤 방향으로 반올림하는지를 정해두지 않으면 건별로는 미미한 차이가 월 단위로 쌓여 맞지 않는 숫자가 됩니다. 반올림 규칙은 문서에 적어두고 코드에서 한 군데로 모아 처리하는 편이 좋습니다.

정산 주기와 보류 규칙은 사업 결정입니다. 언제 확정되고, 언제 지급되며, 분쟁 가능성이 있는 건은 얼마나 잡아두는지가 참여자의 자금 사정에 직접 영향을 줍니다. 규칙을 정하는 것보다 중요한 것은 그 규칙을 참여자가 미리 알 수 있게 하는 일입니다. 정산 명세 화면에서 이번 회차에 무엇이 포함되고 무엇이 왜 보류됐는지 스스로 확인할 수 있으면 문의가 크게 줄어듭니다. 반대로 총액만 보여주면 모든 의문이 사람에게 옵니다.

앞 절에서 말한 판단이 여기서 다시 걸립니다. 정산 투명성이 핵심인 서비스일수록 자금을 실제로 보관하고 나눠 보내는 주체가 어디에 있는지가 설계보다 앞섭니다. 아무리 원장을 정교하게 만들어도, 수취와 지급의 실체가 현지 요건에 맞지 않으면 그 원장은 열리지 않는 서비스의 기록일 뿐입니다. 그래서 이런 서비스는 기술 설계와 주체 설계를 같은 회의에서 같이 다뤄야 합니다.

마지막으로 감사 흔적입니다. 누가 언제 어떤 정산 규칙을 바꿨는지, 수수료율이 언제부터 적용됐는지, 수동으로 조정한 건은 누구의 승인으로 처리됐는지가 남아야 합니다. 정산에서 사람이 손대는 일은 반드시 생깁니다. 손대는 것 자체가 문제가 아니라, 손댄 기록이 없는 것이 문제입니다.

확인이 필요한 사항과 전문가에게 물어야 할 것

여기까지는 구조를 잡는 이야기였습니다. 아래는 이 글에서 답할 수 없고, 사업 형태와 시점에 따라 달라지므로 현지 전문가에게 직접 확인해야 하는 항목입니다. 베트남 관련 규정은 개정되고 해석도 사안마다 다릅니다. 확인 없이 가정하고 개발을 시작하면 되돌리는 비용이 큽니다.

사업자 자격 쪽에서 먼저 확인할 것들입니다. 등록된 사업 범위에 지금 하려는 활동이 포함되는지, 전자상거래나 온라인 중개에 해당한다면 별도의 등록이나 신고가 필요한지, 외국인 투자가 들어간 법인이 해당 활동을 하는 데 추가 조건이 있는지. 그리고 대금을 일시적으로 보관했다가 제3자에게 전달하는 행위가 어떤 범주로 다뤄지는지. 마지막 항목은 마켓플레이스형 서비스에서 거의 항상 걸리는 지점이므로 구조를 확정하기 전에 물어야 합니다.

세무와 증빙 쪽입니다. 거래 단계마다 어떤 증빙을 발행해야 하는지, 플랫폼 수수료와 판매 대금의 처리가 어떻게 나뉘는지, 개인 참여자에게 지급할 때 원천징수 의무가 있는지, 국경을 넘는 대금과 용역비에 어떤 절차가 붙는지. 세율과 신고 주기는 이 글에서 다루지 않습니다. 회계 자문에게 사업 구조를 그림으로 보여주고 구간별로 답을 받는 편이 정확합니다.

데이터와 소비자 보호 쪽도 확인 목록에 넣어야 합니다. 결제와 관련된 개인정보를 어디에 보관해야 하는지, 보관 기간과 접근 통제에 요구되는 수준이 무엇인지, 카드 정보를 직접 다루지 않고 결제 서비스 제공자에게 넘기는 구성이 요구를 어디까지 줄여주는지. 그리고 환불과 취소 정책을 사용자에게 어떤 방식으로 고지해야 하는지. 앱 스토어 심사에서도 같은 항목을 묻는 경우가 있어 두 번 준비할 필요가 없도록 한 번에 정리해두는 편이 낫습니다.

결제 수단 쪽은 제공자의 온보딩 심사팀에 직접 묻는 것이 가장 빠릅니다. 어떤 서류가 필요한지, 어떤 업종이 지원되고 어떤 업종이 제외되는지, 정산 주기와 보류 정책이 어떻게 되는지, 분쟁이 들어왔을 때 사업자가 해야 하는 일이 무엇인지. 이 글에서 특정 제공자를 권하지 않는 이유는 사업 형태에 따라 가능 여부가 갈리기 때문입니다. 두세 곳에 같은 질문을 보내고 답변을 나란히 놓고 비교하는 편이 낫습니다.

앱 스토어 정책은 심사 직전에 다시 확인해야 하는 항목입니다. 지금 만들고 있는 상품 유형이 인앱결제 대상인지, 외부 결제를 안내할 수 있는 범위가 어디까지인지, 구독 취소와 환불을 앱이 어떻게 처리해야 하는지. 문서는 바뀌고, 바뀐 문서가 심사 기준이 됩니다. 개발 시작 시점에 읽은 내용을 그대로 믿고 심사에 들어가지 않는 편이 안전합니다.

물을 상대는 셋으로 나뉩니다. 법인 형태와 활동 범위, 자금 취급의 성격은 현지 법무 자문에게. 증빙과 세무 처리는 현지 회계 자문에게. 정산 조건과 온보딩 가능 여부는 결제 서비스 제공자에게. 개발사는 이 세 곳의 답을 받아 시스템 구조로 옮기는 역할을 합니다. 저희가 프로젝트 초기에 하는 일도 대체로 그것입니다. 답을 대신 내는 것이 아니라, 무엇을 물어야 하는지 목록을 만들고 답이 오는 대로 설계를 맞춰가는 일입니다.

정리하면 순서는 이렇습니다. 수취와 정산의 주체를 정하고, 그 주체에게 필요한 자격과 절차를 자문으로 확인하고, 확인된 범위 안에서 결제 수단과 스토어 정책을 고르고, 그다음에 원장과 대사 구조를 만듭니다. 이 순서를 지키면 개발은 예측 가능한 작업이 됩니다. 순서를 건너뛰면 잘 만든 코드가 열리지 못한 채 남습니다.