웹·앱 결제 연동 안내

온라인으로 결제를 받으려면 무엇이 필요한지, 준비 기간과 비용은 어느 정도인지 정리한 문서입니다.
예약 시스템에 결제를 붙이는 경우를 중심으로 설명합니다.

한눈에 보기

• 결제 기능은 직접 만드는 것이 아니라 PG(결제대행사)를 붙이는 일입니다. 카드사와 개별 계약하거나 카드 승인 로직을 구현하지 않습니다.
• 고객의 카드 정보는 우리 서버를 거치지 않습니다. PG 화면에서만 입력되고 처리되므로, 카드 정보 유출 위험을 사업장이 떠안지 않습니다.
• 실제로 어려운 부분은 카드 처리가 아니라 금액이 조작되지 않았는지 서버에서 검증하고, 결제·취소·환불 상태를 어긋나지 않게 관리하는 일입니다. 개발 비용은 대부분 여기에 들어갑니다.
• PG 계약은 사업자 명의로 직접 하셔야 합니다. 심사에 보통 며칠이 걸리므로, 개발과 병행해 일찍 시작하는 편이 좋습니다.
• 계약 전에도 테스트 키로 전 과정을 미리 구현하고 확인할 수 있습니다. 계약을 기다리며 개발이 멈추지 않습니다.

1. PG(결제대행사)란 무엇인가

카드 결제를 받으려면 원래 카드사마다 가맹점 계약을 맺고, 카드 정보를 안전하게 다루는 보안 인증까지 갖춰야 합니다. 개별 사업장이 감당하기 어려운 일이라, 이 과정을 대신해 주는 회사가 PG입니다.

PG를 쓰면 이렇게 정리됩니다.

• 카드사·간편결제사와의 계약을 PG가 묶어서 처리합니다. 한 번 계약으로 신용카드, 계좌이체, 간편결제를 함께 받을 수 있습니다.
• 카드번호는 PG가 띄운 결제창에서만 입력됩니다. 사업장 서버에는 카드번호가 저장되지도, 지나가지도 않습니다.
• 결제 승인, 취소, 환불, 정산을 API로 처리합니다.

즉 개발 작업의 본질은 "결제 시스템 개발"이 아니라 "PG 연동" 입니다. 이 구분이 견적과 기간을 이해하는 출발점입니다.

2. 결제 한 건이 처리되는 과정

국내 PG는 세부 명칭이 조금씩 다를 뿐 흐름은 거의 같습니다. 아래는 토스페이먼츠를 기준으로 한 순서입니다.

1. 주문 생성: 고객이 결제 버튼을 누르면, 서버가 주문 번호와 결제할 금액을 먼저 기록합니다. 이 기록이 나중에 금액 검증의 기준이 됩니다.
2. 결제창 호출: PG가 제공하는 결제창이 열리고 고객이 카드 또는 간편결제를 선택해 인증을 마칩니다.
3. 인증 결과 수신: 인증이 끝나면 주문 번호, 금액, 그리고 결제를 식별하는 고유 키와 함께 사업장 페이지로 돌아옵니다.
4. 서버에서 결제 승인: 서버가 PG에 승인을 요청해야 결제가 최종 확정됩니다. 이 단계를 거치지 않으면 결제는 완료되지 않습니다. 토스페이먼츠 기준으로 인증 후 10분 안에 승인을 요청해야 하며, 넘기면 그 결제는 만료됩니다.
5. 결과 저장과 알림: 승인 결과를 주문에 기록하고, 고객에게 완료 안내를, 사업장에는 접수 알림을 보냅니다.

여기에 더해 가상계좌 입금처럼 나중에 결과가 확정되는 결제 수단이 있어, PG가 상태 변화를 알려주는 웹훅을 함께 처리합니다.

개발자용 세부 사항

• 인증 성공 시 successUrl로 paymentKey, orderId, amount가 전달되고, 서버는 결제 승인 API를 호출해 확정합니다. 승인 전까지는 결제가 성립하지 않습니다.
• paymentKey는 승인·취소·조회에 모두 쓰이는 식별자이므로 반드시 저장합니다.
• 승인 요청 시 클라이언트가 보낸 금액을 그대로 신뢰하지 않고, 1단계에서 서버에 저장해 둔 주문 금액과 대조합니다. 이 검증이 빠지면 브라우저에서 금액을 바꿔 소액 결제로 통과시킬 수 있습니다.
• 웹훅은 서명을 검증해 위조 요청을 걸러냅니다.
• 취소·환불은 중복 호출과 부분 취소를 함께 고려해 멱등하게 처리합니다.
• 데이터 구조는 주문(금액, 상태)과 결제(식별자, 승인 시각, 취소 내역)를 나누고, 상태를 결제대기 → 결제완료 → 취소/부분취소처럼 단순하게 유지하는 편이 사고를 줄입니다.

3. 어떤 PG를 쓰나

선택지	어떤 경우에 적합한가
토스페이먼츠	처음 결제를 도입하는 경우. 결제창 하나로 카드·간편결제·계좌이체를 함께 받을 수 있고 문서와 테스트 환경이 잘 갖춰져 있습니다.
포트원	여러 PG를 한 방식으로 다뤄야 하거나, 이미 특정 PG와 계약이 있거나, 카카오페이·네이버페이 등을 개별로 붙여야 하는 경우.

어느 쪽을 쓰든 앞서 설명한 흐름과 개발 범위는 크게 다르지 않습니다. 기존 계약이나 정산 조건이 있으시면 그에 맞춰 정합니다.

4. 사업자께서 준비하실 것

PG 계약은 사업자 명의로 진행합니다. 개발사가 대신 계약할 수 없는 부분입니다.

• 사업자등록증, 통신판매업 신고 등 서류를 갖춰 PG에 가입을 신청하고 심사를 받습니다. 업종과 서류 상태에 따라 보통 며칠이 걸립니다.
• 결제 수수료와 정산 주기는 사업자와 PG 사이의 조건입니다. 업종·매출 규모에 따라 우대 요율이 적용되기도 하므로, 정확한 수치는 계약 시점에 PG에서 안내받으시는 것이 정확합니다.
• 취소·환불 규정을 미리 정해 두셔야 합니다. 이 규정이 그대로 화면 문구와 시스템 동작이 됩니다.

개발은 계약을 기다리지 않고 시작할 수 있습니다. 테스트 키로 결제부터 취소까지 전부 구현해 두고, 계약이 끝나면 운영 키로 바꿔 검증하는 순서로 진행합니다.

5. 예약·결제 시스템 옵션

예약과 결제는 따로 보면 각각 단순하지만, 붙이는 순간 결정할 것이 늘어납니다. 실제 작업 범위는 대개 이렇게 구성됩니다.

• 예약 가능한 시간대 관리와 중복 예약 차단. 두 사람이 같은 시간을 동시에 누르는 상황을 서버에서 막아야 합니다.
• 결제 방식 선택: 전액 선결제, 예약금만 선결제, 현장 결제 중 무엇을 쓸지에 따라 구조가 달라집니다.
• 취소·환불 정책의 자동화. 이용 며칠 전까지는 전액 환불, 그 이후는 부분 환불처럼 규정을 시스템에 반영합니다. 부분 환불이 들어가면 작업량이 눈에 띄게 늘어납니다.
• 노쇼 처리, 예약 변경, 관리자 대리 예약과 대리 취소.
• 고객 알림(문자·카카오톡·메일)과 사업장 알림.

듀오랩스 견적기에서는 이 작업을 웹사이트의 "예약·결제 기능" 옵션으로 선택하실 수 있습니다. 정해진 범위의 예약과 결제 연동을 기준으로 한 금액이며, 회원 등급별 요금이나 정기 결제처럼 범위가 넓어지는 요구사항은 상담에서 따로 산정합니다.

기간은 예약 로직의 복잡도에 따라 달라지지만, 결제 연동 자체(결제·취소·웹훅)는 대체로 며칠 규모이고 예약 시스템에 결합하는 작업까지 1주에서 2주 정도로 보시면 큰 차이가 없습니다.

6. 앱에서 판매하는 경우는 규칙이 다릅니다

모바일 앱은 무엇을 파느냐에 따라 결제 방식이 갈립니다. 이 구분을 놓치면 앱 심사에서 반려됩니다.

• 앱 안에서만 쓰는 디지털 상품(구독, 아이템, 유료 기능 해제 등)은 원칙적으로 앱 마켓의 인앱결제를 사용해야 하며 마켓 수수료가 붙습니다.
• 실물 상품이나 앱 밖에서 제공되는 서비스(예약, 방문 서비스, 배달, 오프라인 이용권 등)는 인앱결제 대상이 아니어서 일반적인 PG 결제를 사용할 수 있습니다. 예약 시스템은 보통 여기에 해당합니다.

수수료와 외부 결제 허용 범위는 최근에도 계속 바뀌고 있습니다. 구글은 2026년에 플레이스토어 수수료를 일회성 결제 30퍼센트에서 15퍼센트로, 정기 구독 15퍼센트에서 10퍼센트로 낮추겠다고 발표했고 한국 적용은 2026년 12월 31일로 예고되어 있습니다. 외부 결제 링크를 함께 제공하는 조건도 마켓 정책에 따라 달라집니다.

정책이 자주 바뀌는 영역이므로, 앱 결제가 포함된 프로젝트는 착수 시점에 각 마켓의 최신 정책을 다시 확인하고 범위를 정합니다. 이 문서의 수치도 발표 기준이며 시행 내용이 달라질 수 있습니다.

7. 안전하게 만들기 위해 지키는 원칙

결제에서 사고가 나는 지점은 대체로 정해져 있습니다. 듀오랩스가 작업할 때 반드시 지키는 것들입니다.

• 카드 정보를 어떤 형태로도 저장하지 않습니다. 저장할 이유도, 저장해도 되는 형식도 없습니다.
• 금액은 항상 서버에 기록된 주문 금액을 기준으로 검증합니다. 화면에서 넘어온 금액을 믿지 않습니다.
• 웹훅은 서명을 검증한 뒤에만 반영합니다. 검증 없이 처리하면 위조된 입금 통보로 주문이 완료 처리될 수 있습니다.
• 취소와 환불은 중복 요청이 들어와도 결과가 달라지지 않게 처리합니다.
• 결제 관련 기록은 나중에 대사할 수 있도록 남깁니다. 문제가 생겼을 때 무엇이 언제 일어났는지 확인할 수 없으면 대응이 불가능합니다.

자주 묻는 질문

결제 기능만 따로 붙일 수 있나요?

가능합니다. 이미 운영 중인 사이트나 시스템에 결제만 추가하는 작업도 진행합니다. 다만 주문 정보를 어디에 어떻게 기록하고 있는지에 따라 작업량이 달라지므로, 기존 구조를 먼저 확인한 뒤 범위를 정합니다.

정기 결제(구독)도 되나요?

됩니다. 다만 카드 자동 결제는 실패 재시도, 구독 변경과 해지, 결제 실패 시 서비스 중단 시점 같은 규칙을 따로 정해야 해서 일회성 결제보다 범위가 넓습니다. 상담에서 별도로 산정합니다.

현금영수증이나 세금계산서도 처리되나요?

현금영수증은 PG에서 발행을 지원하는 경우가 많아 결제 흐름에 함께 넣을 수 있습니다. 세금계산서는 회계 처리와 얽히므로 사용 중인 방식에 맞춰 연동 여부를 정합니다.

결제가 실패하거나 중간에 창을 닫으면 어떻게 되나요?

승인 단계를 거치지 않은 결제는 확정되지 않으므로 금액이 빠져나가지 않습니다. 다만 주문 기록은 "결제 대기" 상태로 남으므로, 일정 시간이 지난 미완료 주문을 정리하는 처리를 함께 넣습니다.

테스트는 어떻게 확인하나요?

PG가 제공하는 테스트 환경에서 결제, 취소, 부분 환불, 가상계좌 입금까지 실제와 같은 흐름으로 확인하실 수 있습니다. 운영 전환 전에 함께 점검합니다.

다음 단계

결제 도입을 검토 중이시라면 아래 세 가지를 먼저 정리해 주시면 상담이 빨라집니다.

1. 무엇을 파는지 (실물, 오프라인 서비스, 디지털 상품 중 어느 쪽인지)
2. 전액 선결제인지, 예약금만 받는지, 현장 결제인지
3. 취소와 환불 규정을 어떻게 가져갈지

정해진 것이 없어도 괜찮습니다. 상담에서 함께 정리해 드립니다.