6가지 결제 방식 비교

핵심 요약

• 결제 방식은 6가지로 갈린다: 결제창 · 결제위젯 · 브랜드페이 · 결제링크 · 자동결제(빌링) · 예약결제​. 이름이 비슷해 보여도 각자 쓰는 자리가 달라요.
• 한 서비스가 하나만 쓰는 경우는 드물이에요. 보통 "상시 결제 UI 1개 + 특수 용도 1~2개" 조합으로 간다 (예: 결제위젯 + 자동결제 + 결제링크).
• 먼저 갈라야 할 건 "반복 청구가 필요한가"​​예요. 월 구독처럼 서버가 다시 청구해야 하면 자동결제·예약결제 쪽이고, 고객이 그때그때 결제하는 흐름이면 결제창/위젯/브랜드페이/결제링크 쪽이에요. 빌링키 방식인 자동결제·예약결제는 서버가 원하는 시점과 금액으로 청구를 요청할 수 있어요.
• 그다음에는 "결제 요청을 누가 시작하는가"​​를 봐요. 고객이 사이트 안에서 직접 시작하면 결제창/위젯/브랜드페이, 판매자·관리자가 링크를 보내 시작하면 결제링커요.

이런 상황이라면

김대리는 식단·운동 코칭 서비스​​를 운영하는 팀의 PM예요. 개인 고객에게는 2주 무료 체험 후 월 구독 상품을 팔고, 추가로 1회성 상담 패키지​​도 판매해요. 기업 복지 담당자나 헬스장 제휴 고객처럼 단체 이용권​​을 사는 경우는 상담 후 견적을 확정해 결제를 받아요. 사이트 안 주문서에는 첫 달 할인, 추천인 쿠폰, 결제수단별 혜택 문구​​까지 넣어야 해요.

문제는 결제 요구가 한 가지가 아니라는 점이에요. 개인 고객 첫 결제는 사이트 안에서 자연스럽게 끝나야 하고, 체험 종료 뒤에는 자동으로 월 구독이 이어져야 해요. 이미 결제한 회원에게는 원클릭 재결제도 붙이고 싶어요. 반면 단체 이용권은 상담 후 확정 금액으로 링크를 보내 결제받는 쪽이 더 편해요. 그러다 보니 팀 안에서는 "이건 결제창이면 충분한가, 쿠폰·할인 제어가 많으니 결제위젯을 써야 하나, 구독은 자동결제로 따로 봐야 하나, 단체 결제는 링크로 빼야 하나" 같은 질문이 한꺼번에 터져요.

이 글은 결제 방식 6가지를 구독/단건/견적형으로 먼저 나누고​, 그다음 결제창·결제위젯·브랜드페이·결제링크를 언제 조합하는지​​까지 한눈에 정리해요.

1결제 방식 6가지 한눈 지도

각 방식은 "누가 결제 시점을 결정하는가"​​와 "UI를 어디에 두는가" 두 축으로 나뉘어요.

여기서 말하는 결제 시점은 "최종 승인 버튼을 누가 누르느냐"보다 "결제 요청을 언제 시작하느냐"​​에 가까워요. 그래서 결제링크는 고객이 최종 결제를 완료하더라도, 결제 요청 시점을 여는 쪽은 판매자·관리자​​로 봐요.

결제창 — 가장 기본

버튼을 누르면 PG 결제 화면이 열려요. 가장 빨리 붙이고 가장 넓은 결제수단​​을 지원하는 기본형이에요. 주문서 로직이 단순하고, 빠르게 오픈해야 할 때 먼저 검토해요.

결제위젯 — 주문서 안에 붙이는 결제 UI

결제수단 목록, 약관 동의, 결제 버튼이 내 주문서 페이지 안에 렌더링돼요. 특히 쿠폰, 적립금, 결제수단별 할인처럼 조건에 따라 최종 결제금액이 계속 달라지는 주문서​​라면 UX상 더 유리해요. 고객이 주문서 안에서 할인 적용 결과와 최종 결제금액 변화를 바로 확인한 뒤 결제​​할 수 있기 때문이에요.

브랜드페이 — 서비스 전용 원클릭

쉽게 설명하면 브랜드페이는 결제위젯 안에서 동작하는 우리 서비스용 간편결제​​예요. 회원 토큰(user_token)​​으로 저장된 카드를 불러와 원클릭 결제를 만들어요. 즉, 고객 입장에서는 카드를 다시 입력하지 않고 바로 결제하는 흐름에 가까워요. 다만 이를 쓰려면 로그인·회원 시스템·결제위젯 연동이 모두 전제돼야 해요. 재구매가 반복되는 멤버십 커머스, 예약 서비스, 콘텐츠 결제에 효과가 커요.

결제링크 — 사이트 없이도 결제

관리자에서 결제 링크를 만들어 카톡·DM·메일로 보낸이에요​. 고객이 링크를 열면 결제 페이지가 뜨고, 결제 결과는 웹훅으로 받아요. 사이트 없는 1인 판매자, 상담 기반 B2B 견적 결제, 오프라인 매장 원격 결제에 써요.

자동결제(빌링) — 서버가 청구 시점을 제어

첫 결제에서 빌링키​​를 발급받고, 이후에는 판매자(서버)가 원하는 시점과 금액으로 청구를 반복 요청​​해요. 고객이 매번 결제 버튼을 누르지 않아요. 기획 관점에서는 예약결제를 판매자가 원하는 시점마다 계속 실행하는 운영 방식​​으로 이해하면 쉬워요. 월 구독 자동 청구, 사용량 기반 과금(배달·택시), 원터치 재주문에 써요.

예약결제 — 특정 시점 1회 청구 예약

예약결제도 자동결제와 같은 빌링키 방식​​이에요. 차이는 판매자가 원하는 미래 시점과 금액으로 1회 청구를 예약한다​​는 데 있어요. 그래서 예약결제가 1회 버전이고, 자동결제는 그 요청을 판매자가 원하는 주기와 시점에 반복 운영하는 버전​​으로 보면 돼요. 체크인 당일 과금, 렌터카 반납 후 정산, 예약금·잔금 분할처럼 주문 시점과 청구 시점이 분리되는 서비스​​에 맞아요. 자체 cron 운영 부담이 없어요.

2단건 결제 흐름으로 좁혀보면 — 결제창 vs 결제위젯 vs 결제링크

6가지 방식 전체 지도에서 한 번 더 좁혀보면, 고객이 직접 결제하거나 판매자가 링크를 보내는 단건 흐름​​은 결국 결제창 · 결제위젯 · 결제링크 중에서 고르는 문제로 모여요.

결제 UI 선택 가이드

통합 결제창이 맞는 경우

주문서가 단순하고, 상품/금액 확인 후 바로 결제만 되면 되는 상황​​이에요. PG가 제공하는 화면을 쓰므로 구현 속도와 안정성이 좋아요. 초기 스타트업, 일반 쇼핑몰, 빠른 MVP 오픈에 기본값이에요.

결제위젯이 맞는 경우

쿠폰, 적립금, 결제수단별 할인, 혜택 배지, 프로모션 문구​​처럼 주문서 안에서 계속 금액이 바뀌는 요소가 많을 때예요. 이 경우 고객은 할인이 어떻게 반영됐는지, 최종 결제금액이 얼마로 바뀌었는지​​를 같은 화면에서 확인해야 안심하고 결제해요. 그래서 결제위젯은 단순히 예쁜 UI가 아니라, 변하는 금액을 한 화면 안에서 설명하는 UX 도구​​에 가까워요.

결제링크가 맞는 경우

사이트 주문서 안에서 고르는 문제가 아니라, 판매자·관리자가 먼저 결제 요청을 보내는 구조​​일 때예요. 견적 기반 B2B, 수동 예약, DM 판매처럼 고객이 링크를 받아 결제하는 흐름이면 결제링크가 더 자연스러워요.

3우리 서비스엔 뭐가 맞나 — 시나리오별 조합

한 서비스가 하나만 쓰는 경우는 드물이에요. 아래는 현실에서 자주 보이는 조합이에요.

일반 온라인 쇼핑몰

결제창 또는 결제위젯 1개만으로 충분해요. 고객이 주문할 때마다 카드를 다시 골라요. 재구매가 많아지면 브랜드페이 추가를 검토.

D2C 브랜드 커머스 (브랜딩 중요)

결제위젯 + 브랜드페이. 결제 화면까지 브랜드 톤을 유지하고, 회원 재구매 마찰을 없애요.

SaaS 월 구독

결제창(첫 결제) + 자동결제(월 청구). 첫 결제에서 빌링키를 발급받고, 이후 매달 1일마다 판매자가 정한 금액으로 반복 청구를 요청해요. 결제창 대신 결제위젯·브랜드페이로 첫 결제를 받아도 돼요.

상담 기반 B2B

결제링크 중심. 견적 확정 후 링크를 보내요. 사이트에 결제 UI를 붙이지 않아도 돼요. 같은 고객이 재결제가 많아지면 자동결제도 병행.

숙박·렌탈·예약 서비스

결제창/위젯(예약금) + 예약결제(잔금). 주문 시 예약금만 받고, 체크인·반납 시점에 서버가 잔금 금액으로 청구를 예약해요.

1인 판매자·인스타 셀러

결제링크만. 사이트를 만들지 않아요. DM으로 링크 보내고 결제 결과를 웹훅이나 관리자에서 확인해요.

멤버십·콘텐츠 구독

결제위젯 + 브랜드페이 + 자동결제. 첫 가입은 결제위젯, 재결제는 브랜드페이로 원클릭, 월 구독 연장은 자동결제.

4뭐부터 정할까요

결제 방식 6개를 한 번에 비교하면 혼란스러워요. 아래 순서로 좁혀가면 빨라요.

① 반복 청구가 필요한가요

월 구독·체험 종료 후 전환·사용량 청구처럼 판매자가 원하는 시점과 금액으로 다시 청구해야 하면 자동결제 또는 예약결제부터 봐요. 고객이 그때그때 결제하는 단건 흐름이면 결제창·위젯·브랜드페이·결제링크 중에서 골라요.

② 결제 요청을 누가 시작하는가

고객이 사이트 안에서 직접 시작하면 결제창·위젯·브랜드페예요. 판매자·관리자가 카톡·DM·메일로 결제 요청을 보내면 결제링커요.

③ 사이트 안에서 받는가, 링크로 보내는가

사이트 안에서 바로 받는이에요​: 결제창·위젯·브랜드페이. 카톡·DM·메일로 결제 요청을 보낸이에요​: 결제링크.

④ (사이트 안에서 받는다면) 주문서가 단순한가, 혜택 설계가 복잡한가

쿠폰·적립금·결제수단별 할인·혜택 배지처럼 주문서 안에서 제어할 요소가 많이에요 → 결제위젯. 상품/금액 확인 후 바로 결제하면 되고 PG 기본 UI로 충분하예요 → 결제창. 재구매 회원 원클릭을 만들고 싶이에요 → 브랜드페이 (결제위젯 + 회원 시스템 전제).

이 4단계를 지나면 보통 주 결제 방식 1개 + 특수 용도 1~2개​​로 좁혀져요.

5자주 혼동하는 지점 3가지

"브랜드페이 = 간편결제" 가 아니에요

간편결제(카카오페이·네이버페이)는 간편결제사 계정에 카드가 저장​​돼 있고, 매 결제마다 간편결제사 인증 팝업이 떠요. 브랜드페이는 우리 서비스 안에 저장​​된 카드로 인증 없이 원클릭 결제해요. 둘은 공존할 수 있어요.

"자동결제 = 구독" 이 아니에요

자동결제(빌링)는 기술 원자​​예요. 정확히는 "고객이 카드를 등록해두면, 판매자(서버)가 빌링키로 원하는 시점과 금액의 청구를 반복 요청할 수 있어요"​​는 기능이에요. 기획 관점에서는 예약결제 요청을 반복 운영하는 방식​​에 가까워요. 구독 설계(플랜·체험·일할계산·해지 처리 등)는 별도 레이어예요. 커머스 API를 쓰면 구독 관리까지 포함되고, 결제 API만 쓰면 자동결제만 지원해요.

"결제링크 = 약식 결제" 가 아니에요

결제링크도 동일한 PG 승인 흐름을 타요. 다만 사이트를 안 만든다​​는 선택이에요. 1인 판매자가 약식으로 쓰는 도구라기보다, "결제 UI를 사이트 안에 둘지 외부 링크로 둘지"​​의 구조 선택에 가까워요.

실제로 붙이려면

상품 선택이 끝났다면 구현 범위는 다음 문서에서 확인해요.

• 상품 매트릭스 — /guide/products
• 왜 Bootpay 결제 SDK — /guide/why-bootpay-sdk