홈페이지에 결제를 연동하기 전, 개발보다 먼저 정리해야 하는 것들

심사는 개발이 끝난 뒤가 아니라 그 전에 시작됩니다

온라인에서 대금을 받으려면 사업자 등록이 되어 있어야 하고, 소비자를 상대로 판매한다면 통신판매업 신고가 필요합니다. 신고 절차와 대상은 공정거래위원회의 전자상거래 관련 안내와 정부24의 민원 안내에서 확인할 수 있습니다. 면제 대상 여부도 여기서 함께 확인해야 합니다.

결제 대행사 심사에서는 서류만 보지 않습니다. 실제로 접속 가능한 사이트를 확인하는 경우가 많습니다. 즉 판매할 상품이 무엇인지, 가격과 배송·환불 조건이 어떻게 안내되는지가 화면에 이미 있어야 합니다. 결제 버튼만 아직 동작하지 않는 상태로 사이트를 먼저 공개해 두는 방식이 실무적으로 자주 쓰입니다.

취급 품목에 따라 추가 인허가가 필요한 경우도 있습니다. 식품, 건강기능식품, 화장품, 의료기기, 주류 등은 별도의 규제가 붙습니다. 이 부분은 개발사가 대신 판단할 수 없는 영역이며, 사업자 본인이 소관 기관 안내로 확인해야 합니다.

• ●사업자 등록과 통신판매업 신고 여부를 먼저 확인합니다
• ●심사 시점에 접속 가능한 사이트가 있어야 하는 경우가 많습니다
• ●상품·가격·배송·환불 안내가 화면에 이미 존재해야 합니다
• ●취급 품목별 추가 인허가는 사업자가 소관 기관에서 직접 확인합니다

사이트에 반드시 존재해야 하는 안내 영역

전자상거래에서는 판매자가 누구인지와 거래 조건을 소비자가 확인할 수 있어야 합니다. 관련 의무는 전자상거래 등에서의 소비자보호에 관한 법률에 따르며, 구체적인 표시 항목은 공정거래위원회 안내를 통해 확인할 수 있습니다. 실무적으로는 사이트 하단과 별도 안내 페이지에 나누어 배치합니다.

자주 빠지는 것은 교환·반품·환불 조건입니다. 상품 페이지에서는 잘 보이지 않는 곳에 두고 약관 안에만 넣어 두는 경우가 많은데, 이 조건이 불분명하면 결제 이후 분쟁이 그대로 늘어납니다. 배송 소요 기간과 배송비 기준도 마찬가지입니다.

개인정보 처리에 관한 안내도 필요합니다. 주문 과정에서 이름, 연락처, 주소를 받게 되므로 어떤 정보를 왜 받고 얼마나 보관하는지 알려야 합니다. 구체적인 문구는 취급 범위에 따라 달라지므로 법률 검토를 받는 편이 안전합니다.

• ●판매자 정보와 연락 수단을 확인 가능한 위치에 둡니다
• ●이용약관과 개인정보 처리 관련 안내 페이지를 준비합니다
• ●교환·반품·환불 조건과 배송 기준을 눈에 띄는 위치에 배치합니다
• ●고객 문의 경로와 응답 가능 시간을 명시합니다

국내 결제와 해외 결제는 서로 다른 문제입니다

국내 고객을 대상으로 원화로 판매하는 경우와, 해외 고객에게 외화로 판매하는 경우는 준비할 것이 다릅니다. 두 가지를 한 번에 붙이려다 일정이 늘어지는 경우가 많으므로, 어느 쪽이 지금 매출의 중심인지부터 정하는 편이 낫습니다.

국내 결제에서는 신용카드 외에 간편결제와 계좌 기반 결제까지 어디까지 지원할지가 선택지가 됩니다. 지원 수단을 늘릴수록 결제 화면과 취소 처리, 정산 확인 절차가 복잡해집니다. 처음에는 실제로 많이 쓰이는 수단부터 열고 이후에 넓히는 방식이 관리하기 쉽습니다.

해외 판매를 함께 한다면 통화 표시, 세금 처리, 배송 조건, 환불 정책이 국내와 달라집니다. 사이트 언어도 함께 고려해야 합니다. 다만 언어를 늘리는 것과 해외 결제를 여는 것은 별개의 결정이며, 실제 문의가 들어오는 지역이 있는지부터 확인한 뒤 판단하는 편이 낭비가 적습니다.

• ●국내 원화 판매와 해외 판매 중 우선순위를 먼저 정합니다
• ●지원 결제 수단은 필요한 것부터 열고 단계적으로 넓힙니다
• ●해외 판매 시 통화·세금·배송·환불 정책을 별도로 정의합니다
• ●언어 확장과 해외 결제 개설은 각각 따로 판단합니다

개발 쪽에서 실제로 사고가 나는 지점

가장 중요한 원칙은 결제 결과를 화면 쪽 신호만으로 믿지 않는 것입니다. 사용자의 브라우저에서 돌아온 값은 조작될 수 있으므로, 서버가 결제 대행사에 다시 확인해 금액과 주문 정보가 일치하는지 검증한 뒤에야 주문을 확정해야 합니다. 이 절차를 생략한 사이트는 실제로 금액이 어긋난 주문이 들어올 수 있습니다.

다음은 통신이 끊기는 상황입니다. 결제는 성공했는데 사용자가 결과 화면으로 돌아오지 못하는 경우가 반드시 발생합니다. 이럴 때를 위해 결제 대행사가 서버로 직접 보내는 알림을 받아 처리하고, 같은 알림이 여러 번 와도 주문이 중복 생성되지 않도록 처리해야 합니다.

취소와 부분 취소도 초기에 설계해야 합니다. 나중에 붙이려면 주문 구조를 다시 손봐야 하는 경우가 많습니다. 마지막으로 정산 대사를 위한 기록이 필요합니다. 주문 번호, 결제 식별자, 금액, 시각, 상태 변경 이력을 남겨 두면 나중에 금액이 맞지 않을 때 원인을 찾을 수 있습니다.

• ●결제 결과는 반드시 서버에서 재확인한 뒤 주문을 확정합니다
• ●서버로 오는 알림을 받아 처리하고 중복 처리를 방지합니다
• ●취소와 부분 취소 흐름을 초기 설계에 포함합니다
• ●주문·결제 식별자와 상태 변경 이력을 남겨 정산 대사를 가능하게 합니다
• ●연동 키는 코드에 넣지 않고 서버 설정으로 분리합니다

자체 결제를 붙이지 않는 편이 나은 경우

솔직하게 말하면, 모든 회사가 자체 사이트에 결제를 붙일 필요는 없습니다. 판매 건수가 아직 적고 상품 종류도 몇 개뿐이라면, 기존 판매 채널을 쓰면서 자체 사이트는 브랜드와 문의 접수에 집중하는 편이 비용 대비 효율이 좋을 수 있습니다.

기업 간 거래가 중심이고 견적과 계약이 앞서는 사업이라면, 결제 화면보다 견적 요청과 발주 흐름을 정리하는 쪽이 실제 매출에 더 가깝습니다. 이 경우 결제는 기존 방식대로 처리하고 사이트는 문의와 자료 제공을 담당하게 하는 구성이 자연스럽습니다.

반대로 자체 결제가 분명히 유리한 경우도 있습니다. 재구매가 반복되는 상품, 정기 결제가 필요한 서비스, 판매 채널 수수료 부담이 큰 구조, 고객 정보를 직접 확보해야 하는 사업이 그렇습니다. 판단 기준은 기능의 유무가 아니라 지금의 거래 구조입니다.

• ●판매 건수가 적고 품목이 단순하면 기존 채널 활용이 나을 수 있습니다
• ●견적·계약 중심의 기업 간 거래는 결제보다 문의 흐름이 우선입니다
• ●재구매·정기 결제·수수료 부담이 크면 자체 결제의 이점이 큽니다
• ●결정 기준은 기능 욕심이 아니라 현재의 거래 구조입니다

자주 묻는 질문