현지 결제 수단 붙이기: QR 이체와 전자지갑, 카드

결제 수단은 취향이 아니라 습관이다

어떤 결제 수단을 붙일지는 개발 편의로 정할 문제가 아닙니다. 그 서비스를 쓸 사람들이 이미 손에 익힌 방식이 무엇인지가 먼저입니다. 익숙하지 않은 수단만 놓아두면 결제 화면에서 사람이 멈추고, 멈춘 자리는 대개 문의로도 오지 않고 그냥 이탈로 남습니다.

한국 기업 담당자가 현지용 서비스를 준비할 때 이 지점에서 자주 어긋납니다. 한국에서는 카드 결제가 기본값처럼 자리 잡아서, 결제 화면이라고 하면 카드 번호를 넣는 폼을 먼저 떠올립니다. 그런데 현지 사용자에게 익숙한 동작은 은행 앱을 열어 이체하거나 화면에 뜬 코드를 카메라로 읽는 쪽입니다. 처음 만난 서비스에서 카드 등록부터 요구하면, 사려던 마음이 있던 사람도 그 자리에서 손을 놓습니다.

그렇다고 카드가 필요 없다는 말은 아닙니다. 누구에게 파는지에 따라 답이 달라집니다. 기업을 상대로 청구하는 서비스라면 회사 계좌 이체와 증빙 서류가 중심이 되고, 외국인 방문객을 상대하는 서비스라면 해외 발급 카드를 받아야 하며, 매달 자동으로 빠져나가는 구독형이라면 또 다른 조건이 붙습니다. 사용자의 연령대, 주로 쓰는 기기, 도시와 지방의 차이까지 결제 수단 선택에 영향을 줍니다.

그래서 첫 회의에서 기능 목록보다 먼저 묻는 것이 있습니다. 지금은 돈을 어떻게 받고 있느냐는 질문입니다. 오프라인에서 이미 굴러가는 수납 방식이 답의 절반을 갖고 있습니다. 계좌로 받고 있었다면 온라인에서도 그 습관이 이어지고, 물건을 받을 때 현금을 내는 방식이 익숙한 고객층이라면 온라인 선결제로 옮기는 일 자체가 별도의 설득 과제가 됩니다. 이 차이를 모른 채 화면부터 만들면 다 만들고 나서 수단을 다시 붙이게 됩니다.

수수료율과 계약 조건, 승인에 필요한 요건은 이 글에서 단정하지 않겠습니다. 결제 대행사와 은행마다 다르고, 업종과 거래 규모에 따라 협의로 정해지며, 시간이 지나면 바뀝니다. 개발사가 대신 말해 줄 수 있는 영역이 아니라 고객사가 해당 사업자와 직접 확인해야 하는 항목입니다. 개발사가 답할 수 있는 것은 각 수단을 붙였을 때 화면이 몇 단계 늘어나고 서버가 어떤 상태를 더 다뤄야 하는지입니다.

여우비 인터랙션이 결제가 들어가는 화면을 설계할 때도 순서는 같습니다. 후보 수단을 늘어놓고, 각 수단이 사용자 흐름에서 몇 걸음을 차지하는지, 실패했을 때 사용자가 어디로 돌아오는지를 먼저 그립니다. 그 그림을 놓고 고객사가 고릅니다. 수단을 먼저 확정하고 화면을 나중에 그리면 흐름을 다시 짜야 하는 일이 생깁니다.

수단은 한 번에 다 붙이지 않는 편이 낫습니다. 가장 익숙한 하나로 먼저 열고, 실제로 어떤 문의가 들어오는지 본 뒤에 늘립니다. 수단이 하나 늘 때마다 환불 경로와 대조 절차, 고객 응대 문구가 같이 늘어나기 때문입니다. 화면에 버튼 하나 추가하는 일로 보이지만, 그 뒤에는 운영이 붙습니다.

계좌 이체와 QR이 주력인 환경의 설계

이체와 코드 스캔을 주력으로 두면 설계의 무게 중심이 결제 버튼에서 확인 단계로 옮겨갑니다. 돈이 우리 화면 밖에 있는 은행 앱에서 움직이기 때문입니다. 이때 만들어야 하는 것은 결제 기능이라기보다, 들어온 돈과 주문을 맞춰 보고 그 결과를 남기는 절차입니다.

기본 흐름은 단순합니다. 주문을 먼저 만들고, 사용자에게 보낼 금액과 받는 계좌, 그리고 이 주문을 알아볼 식별자를 화면에 보여 줍니다. 사용자는 은행 앱으로 옮겨 가 이체하고 돌아옵니다. 화면에서 중요한 것은 화려한 디자인이 아니라 복사 버튼과 정확한 금액 표기, 그리고 지금 어느 단계에 있는지 알려 주는 문구입니다. 사용자가 앱을 오가는 사이 자기가 무엇을 하고 있었는지 잊지 않게 하는 것이 이 화면의 일입니다.

가장 골치 아픈 부분은 식별입니다. 이체 메모에 주문번호를 적어 달라고 안내해도, 사용자는 그 칸을 지우거나 다르게 입력하고, 은행 앱마다 입력 가능한 글자 수와 표기가 다릅니다. 그래서 메모만 믿고 자동으로 대조하는 방식은 언제나 맞아떨어지지는 않습니다. 주문마다 금액의 끝자리를 조금씩 다르게 두어 구분하는 방법도 쓰이지만, 금액이 어긋나 보이는 만큼 안내 문구를 정성껏 써야 합니다. 주문마다 별도의 수취 번호를 발급받는 방식이 가능한지는 은행과 대행사가 어떤 서비스를 제공하는지에 달려 있고, 이는 개발 착수 전에 확인해야 하는 항목입니다.

코드 결제는 붙여 두는 형태와 주문마다 만들어 내는 형태로 갈립니다. 매장 계산대에 인쇄해 붙여 두는 쪽은 만들기 쉽지만 금액과 주문이 코드에 실리지 않아 대조 부담이 그대로 남습니다. 주문마다 생성하는 쪽은 금액과 식별 정보를 함께 실을 수 있어 자동 대조에 유리합니다. 은행권이 공통으로 쓰는 코드 규격이 있어 여러 은행 앱에서 읽히는 환경이지만, 어떤 항목을 실을 수 있고 어떤 경로로 발급받는지는 계약과 제공 범위에 따라 다르므로 문서로 확인한 뒤 설계를 확정해야 합니다.

입금 통지를 자동으로 받을 수 있는 경로가 있는지가 일정과 인력 계획을 가릅니다. 통지가 들어오면 대기 목록이 저절로 줄어들지만, 그 경로가 없으면 담당자가 은행 화면을 보며 하나씩 확인하게 됩니다. 후자여도 서비스는 굴러갑니다. 다만 사람이 붙는다는 사실을 처음부터 계산에 넣어야 합니다. 이런 경우 관리자 화면에는 미확인 입금 목록과 손으로 확정하는 버튼, 그리고 누가 언제 확정했는지 남는 이력이 반드시 있어야 합니다.

시간 정책도 미리 정해 둡니다. 이체는 몇 분 만에 끝나기도 하고 한참 걸리기도 합니다. 좌석이나 재고를 잡아 두는 서비스라면 얼마나 기다렸다가 주문을 취소할지 정해야 하고, 취소된 뒤에 돈이 들어오는 경우를 어떻게 처리할지도 함께 정해야 합니다. 사용자에게 이체를 마쳤다고 알리는 버튼이나 증빙을 올리는 자리를 주는 것은 응대에 도움이 되지만, 그 행동 자체가 결제 완료의 근거는 아닙니다. 근거는 다음 절에서 다룹니다.

정리하면 이 방식은 붙이기는 쉬워 보여도 운영이 무겁습니다. 반대로 대행사를 통해 처리하면 화면은 간단해지고 운영 부담은 줄지만 계약과 정산 조건이 따라옵니다. 어느 쪽이 맞는지는 예상 거래 건수와 확인 업무를 감당할 사람이 있는지로 판단합니다. 그 판단의 근거를 개발을 시작하기 전에 문서로 남겨 두면, 나중에 방식을 바꿀 때 무엇이 달라지는지 빨리 계산할 수 있습니다.

전자지갑과 카드는 처리 흐름이 다르다

사용자 눈에는 둘 다 버튼 한 번을 누르는 일이지만, 서버가 하는 일은 다릅니다. 전자지갑은 대체로 다른 앱으로 나갔다가 돌아오는 흐름이고, 카드는 입력과 추가 인증이 우리 흐름 안에서 이어집니다. 실패가 생기는 자리가 서로 달라서 화면과 예외 처리도 다르게 만들어야 합니다.

지갑 결제는 앱 전환이 핵심입니다. 모바일에서는 지갑 앱이 열렸다가 승인 뒤 우리 앱이나 브라우저로 돌아오고, 데스크톱에서는 화면에 뜬 코드를 지갑 앱으로 읽는 형태가 많습니다. 돌아오는 경로를 미리 등록해 두어야 하고, 앱과 웹, 모바일 브라우저를 각각 시험해야 합니다. 그리고 돌아오지 않는 경우가 생각보다 잦습니다. 사용자가 앱을 닫거나, 전환이 실패하거나, 통신이 끊깁니다. 그래서 복귀에만 기대어 상태를 확정하는 설계는 반드시 구멍이 납니다.

카드는 입력 폼을 우리 서버에 두지 않는 것이 기본 원칙입니다. 대행사가 제공하는 결제창이나 라이브러리로 넘겨서 카드 번호가 우리 시스템을 지나가지 않게 합니다. 그래야 우리가 책임져야 할 범위가 줄고, 로그나 오류 보고에 민감한 값이 남을 위험도 줄어듭니다. 은행이 붙이는 추가 인증 단계가 들어가면 흐름에 화면이 하나 더 생기고, 인증에 실패했을 때의 안내와 재시도 경로까지 준비해야 합니다.

국내에서 발급된 카드와 해외에서 발급된 카드는 취급이 다를 수 있습니다. 지원 범위와 통화 처리, 해외 카드 수용 여부는 대행사마다 다르므로 여기서 단정하지 않고 확인 목록에 올려 둡니다. 통화 단위도 실수가 잦은 지점입니다. 소수점을 쓰지 않는 통화를 다룰 때는 금액을 정수로 저장하고 반올림 규칙을 한 곳에 모아 두어야 합니다. 화면과 서버, 정산 자료의 금액이 조금씩 어긋나는 사고는 대개 여기서 시작됩니다.

카드 정보를 보관해 두고 매달 자동으로 청구하는 방식은 별개의 사안으로 다뤄야 합니다. 사용자에게 무엇을 동의받을지, 해지는 어디서 하는지, 청구가 실패하면 언제 다시 시도하고 언제 서비스를 멈출지까지 설계해야 합니다. 이런 방식은 제공자에 따라 별도의 절차나 검토가 필요할 수 있으므로, 가능 여부와 소요 기간을 사업자에게 미리 확인해 일정에 반영하는 편이 안전합니다.

시험 환경을 언제 받을 수 있는지도 일정에 넣습니다. 시험용 계정 발급에 시간이 걸리는 경우가 있고, 문서의 언어와 필드 이름이 실제 응답과 다른 경우도 있습니다. 운영으로 넘길 때는 키를 교체하고 접속 주소를 등록하는 절차가 또 따라옵니다. 개발을 시작하는 날이 아니라 계약을 논의하는 시점에 계정부터 신청해 두면 뒤에서 밀리는 시간을 줄일 수 있습니다.

수단이 늘어날수록 실제로 늘어나는 것은 화면이 아니라 상태 분기입니다. 어떤 수단은 승인과 매입이 나뉘고, 어떤 수단은 부분 취소가 되고 어떤 수단은 안 됩니다. 그래서 수단별로 흩어진 상태를 우리 쪽의 하나의 상태 모델로 정리해 두는 작업이 필요합니다. 그 작업이 이 절과 다음 절을 잇습니다.

결제가 끝났다는 사실을 어떻게 확인할 것인가

결제가 끝났다는 근거는 사용자 화면에 뜬 성공 문구가 아니라, 우리 서버가 받아서 기록한 통지입니다. 화면이 성공을 보여 주어도 서버에 기록이 없으면 그 주문은 완료가 아닙니다. 반대로 사용자가 창을 닫아 버렸어도 통지가 도착했다면 그 주문은 완료입니다. 이 원칙을 처음에 정해 두지 않으면 나중에 분쟁이 생겼을 때 기준이 없습니다.

완료를 알 수 있는 경로는 대체로 두 가지입니다. 사용자가 결제를 마치고 우리 화면으로 돌아오는 경로와, 결제 처리 쪽 서버가 우리 서버로 직접 보내는 통지입니다. 앞의 것은 사용자의 통신 상태와 기기 사정에 좌우되고 값이 조작될 여지도 있으므로 확정의 근거로 삼지 않습니다. 뒤의 것은 서명이나 검증 절차를 붙여 진짜인지 확인하고, 통지에 실린 금액과 통화, 주문 식별자가 우리 주문과 같은지 다시 대조합니다. 금액 확인을 빼먹는 실수가 의외로 흔합니다.

통지는 한 번만 오지 않습니다. 같은 내용이 여러 번 도착하기도 하고 순서가 뒤바뀌기도 합니다. 그래서 같은 거래에 대해 처리는 한 번만 일어나게 만들어야 합니다. 거래 식별자를 기준으로 이미 처리했는지 기록하고, 이미 처리한 통지가 다시 오면 조용히 성공으로 응답합니다. 여기서 실패로 응답하면 상대편은 계속 다시 보내고, 그 재전송이 다른 문제를 만듭니다.

통지가 끊기는 경우에 대비해 직접 조회하는 경로도 함께 만듭니다. 오래 대기 상태로 남아 있는 주문을 주기적으로 조회해 상태를 맞추고, 그래도 남는 건은 관리자 화면에 목록으로 보여 줍니다. 사람이 최종 확정할 수 있는 버튼과 그 이력이 필요합니다. 누가 언제 어떤 근거로 확정했는지가 남아야 나중에 되짚을 수 있습니다. 자동화가 잘 되어 있어도 마지막에 사람이 손댈 자리는 남겨 둡니다.

수단별 상태 코드를 우리 도메인의 상태로 그대로 복사하지 않는 편이 좋습니다. 결제 쪽 코드는 제공자마다 다르고 늘어나기도 합니다. 우리 쪽에는 대기, 완료, 실패, 취소, 부분 환불처럼 업무가 알아야 하는 상태만 두고, 제공자 코드와 연결하는 표를 따로 문서로 관리합니다. 그러면 수단이 늘어도 주문 화면과 정산 자료는 흔들리지 않습니다. 승인만 되고 매입이 아직인 상태처럼 중간 단계가 있는 수단은 그 중간 상태를 어떻게 다룰지 미리 정합니다.

여기서 우리가 남기는 것은 사실의 기록이지 자금 자체가 아니라는 점을 분명히 해 둘 필요가 있습니다. 돈은 결제 처리 사업자와 은행, 그리고 고객사 사이에서 움직이고, 대금을 받는 주체와 정산의 주체는 고객사입니다. 개발사의 책임은 어떤 일이 언제 있었는지를 나중에 확인할 수 있는 형태로 남기는 데 있습니다. 이 경계를 흐릿하게 두면 문제가 생겼을 때 책임 소재부터 다투게 됩니다.

한국 기업 담당자라면 본사 회계가 요구하는 대조 자료의 형식을 미리 물어보는 것이 좋습니다. 현지에서 굴러가는 데이터와 본사에서 필요한 항목이 다른 경우가 많습니다. 어떤 항목이 필요한지 회계 담당자에게 먼저 확인해 두면, 월말마다 사람이 자료를 다시 가공하는 일을 줄일 수 있습니다. 이런 요구는 개발이 끝난 뒤에 나오면 손이 두 배로 갑니다.

환불과 정산까지 그려 두고 시작한다

결제를 먼저 붙이고 환불은 나중에 보자는 계획이 결국 가장 비쌉니다. 환불 경로가 없으면 문의가 들어올 때마다 사람이 손으로 처리하게 되고, 그 처리는 어디에도 기록되지 않은 채 통장 내역과 메신저 대화창에만 남습니다. 몇 달 지나면 무엇을 돌려주었는지 회사가 알 수 없게 됩니다.

환불 경로는 수단마다 다릅니다. 카드는 승인 취소와 부분 취소라는 개념으로 처리되고, 계좌 이체는 사실상 우리가 다시 보내는 일이라 고객의 계좌 정보를 받아야 하며 그 정보 자체가 개인정보로 취급됩니다. 지갑은 제공자가 정한 규칙을 따릅니다. 기간에 제한이 있는지, 부분 환불이 되는지도 제공자와 계약에 따라 다르므로 확인 대상으로 남겨 둡니다. 확인 없이 화면에 환불 버튼부터 만들면 눌러도 되지 않는 버튼이 됩니다.

그래서 정책을 먼저 정합니다. 언제까지 환불이 가능한지, 부분 환불을 허용할지, 취소에 따르는 비용을 고객에게 물릴지, 누가 승인하는지, 승인 뒤 며칠 안에 처리된다고 안내할지를 정해야 합니다. 이건 개발 결정이 아니라 사업 결정입니다. 결정이 없으면 화면을 만들 수 없고, 개발사가 임의로 정하면 나중에 전부 뒤집힙니다. 이 항목들은 요구사항 문서의 앞쪽에 적어 두는 편이 낫습니다.

정산 쪽에서 개발사가 만드는 것은 대조에 쓰는 원장 형태의 데이터입니다. 주문과 거래를 잇는 식별자, 사용한 수단, 상태와 시각, 제공자 쪽 거래 번호가 한 줄에 모여 있어야 회계가 맞춰 볼 수 있습니다. 실제 자금이 언제 들어오는지, 수수료가 어떻게 차감되는지, 세금 처리를 어떻게 하는지는 고객사와 결제 처리 사업자, 은행 사이의 영역입니다. 결제업 인허가나 자금 취급에 관한 요건 판단은 관할 기관과 자문사가 확인할 사항이고 개발사가 대신 판단하지 않습니다.

개발을 시작하기 전에 답이 있어야 하는 질문들은 대체로 정해져 있습니다. 계약의 주체가 누구인지, 어떤 수단을 열 것인지, 완료 통지를 어떤 방식으로 받고 거기에 어떤 항목이 실리는지, 시험 계정은 언제 받을 수 있는지, 운영으로 넘기는 절차가 무엇인지, 환불을 시스템에서 처리할 수 있는 범위가 어디까지인지, 회계가 필요로 하는 자료의 형식이 무엇인지입니다. 이 답이 비어 있는 상태에서 화면부터 만들면 만든 것을 되돌리는 비용이 붙습니다.

시작은 작게 하는 편이 낫습니다. 가장 익숙한 수단 하나로 열고, 한 달 동안 실제 대조를 사람이 돌려 봅니다. 그 한 달에 들어오는 문의가 다음에 무엇을 붙여야 하는지 알려 줍니다. 어디서 사용자가 멈추는지, 어떤 오해가 반복되는지, 확인 업무에 하루 몇 분이 드는지가 그때 보입니다. 이 관찰 없이 수단을 늘리면 화면만 복잡해지고 운영은 더 무거워집니다.

결제는 기능이라기보다 절차에 가깝습니다. 화면은 며칠이면 붙지만 절차는 사람이 굴립니다. 그래서 무엇을 만들 것인지보다 무엇을 확인하고 누가 결정할 것인지를 먼저 정리하는 프로젝트가 결국 빨리 끝납니다. 결제 화면을 마지막에 급하게 붙이는 일정만 피해도 대부분의 사고는 줄어듭니다.