B2B SaaS hosted checkout vs embedded payment form vs custom UI/API 비교 2026, PCI·3DS·검증 비용을 고르는 기준

B2B SaaS에서 신규 고객이 플랜을 선택하고 결제하는 화면을 만들 때 hosted checkout, embedded payment form, custom UI/API 중 하나를 선택하게 됩니다. 세 방식은 모두 결제를 받을 수 있지만 개발 범위, 화면 제어권, 3DS 같은 추가 인증 처리, 운영 중 상태를 확인하는 비용이 다릅니다.

먼저 범위를 구분해야 합니다. checkout은 신규 가입·구매 시점의 화면이고, 결제 후 카드 변경·인보이스 조회·구독 해지는 billing portal의 영역입니다. 고객용 포털 비교는 B2B SaaS 고객용 셀프서비스 빌링 포털 비교에서 다뤘으므로 이 글에서는 checkout 구현 선택에 집중합니다.

세 방식의 차이부터 정리합니다

여기서 hosted가 자동으로 더 안전하거나 custom이 항상 더 유연하다고 단정하면 안 됩니다. 실제 책임 범위는 어떤 데이터를 브라우저와 서버가 처리하는지, provider의 hosted component를 어떻게 삽입하는지, 로그에 어떤 값을 남기는지에 따라 달라집니다. PCI 범위나 규정 준수를 보장하는 표현도 피해야 합니다.

Hosted checkout은 출시 속도를 우선할 때 맞습니다

Stripe Checkout은 provider가 제공하는 결제 페이지 흐름을 이용해 결제 세션을 만들고 고객을 checkout으로 보낼 수 있는 방식입니다. 제품 팀이 가격표, 주문 생성, 결제 결과 연결에 집중하고 결제 입력 화면의 세부 동작을 직접 모두 만들고 싶지 않을 때 검토할 수 있습니다.

Paddle의 overlay checkout도 제품 화면 위에 결제 흐름을 열어 주는 방식입니다. 화면을 벗어나지 않는 경험을 만들 수 있어도, overlay가 열렸다는 사실과 결제가 확정됐다는 사실은 별도로 확인해야 합니다. Chargebee Hosted Pages API나 Recurly hosted payment pages처럼 provider가 제공하는 hosted 흐름도 같은 원칙으로 평가합니다.

Hosted를 고를 때는 다음을 확인합니다.

• 우리 상품의 통화·결제수단·세금 표시 요구를 지원하는가
• checkout session 또는 transaction 생성 결과를 내부 주문과 어떻게 연결하는가
• 성공 redirect만으로 주문을 paid로 바꾸지 않고 provider 객체와 webhook을 재확인하는가
• 화면의 언어·브랜드·약관·고객지원 안내를 필요한 수준까지 조정할 수 있는가
• 결제 실패나 고객 이탈 후 같은 주문을 중복 생성하지 않는가

Hosted checkout은 구현량이 작다는 장점이 있지만, provider가 제공하는 필드와 상태 모델에 제품 운영을 맞춰야 합니다. provider를 바꾸거나 복수 provider를 함께 운영할 계획이라면 처음부터 내부 주문 상태와 provider 상태를 분리해 두는 편이 좋습니다.

원문: 원문기사 보기

원문: 원문기사 보기

Embedded payment form은 화면 경험과 책임의 절충안입니다

Embedded 방식은 결제 입력 영역을 제품의 가입·결제 화면 안에 배치합니다. Stripe Elements와 Payment Element는 결제 입력 UI를 직접 전부 만들지 않으면서도 제품 화면 안에 결제 요소를 구성하려는 팀이 검토할 수 있는 공식 구성 요소입니다.

이 방식은 페이지 이동을 줄이고 플랜 선택, 쿠폰, 회사 정보, 구매자 확인을 하나의 흐름으로 설계하기 좋습니다. 반면 프런트엔드가 provider element의 이벤트를 받고, 로딩·오류·인증 필요 상태를 사용자에게 설명해야 합니다.

Embedded에서 특히 조심할 점은 submit 버튼 클릭, 결제 요청 성공 응답, 3DS 화면 완료, 최종 결제 상태가 서로 다른 관찰 지점이라는 것입니다. 브라우저가 성공 응답을 받았더라도 네트워크가 끊기거나 서버의 주문 업데이트가 실패할 수 있습니다. 고객에게는 “결제 처리 결과를 확인 중” 상태를 보여 주고, 서버는 provider 객체와 webhook을 기준으로 최종 상태를 확정해야 합니다.

원문: 원문기사 보기

원문: 원문기사 보기

Custom UI/API는 제어권보다 검증 비용을 먼저 계산합니다

Custom UI/API는 제품이 결제 화면과 서버 요청을 더 깊게 통제하는 방식입니다. 가격 계산, 회사 구매 승인, 여러 결제수단, 주문 상태, 내부 ERP 연결까지 하나의 경험으로 묶어야 할 때 매력적입니다.

하지만 custom이라고 해서 provider의 책임이 사라지는 것은 아닙니다. Chargebee Hosted Pages API, Paddle transaction API, 각 provider의 결제 객체와 webhook을 어떻게 연결할지 직접 설계해야 합니다. 카드번호 같은 민감한 원문 값을 불필요하게 서버나 로그에 통과시키지 않는 구조인지도 별도로 점검해야 합니다.

Custom 방식을 검토한다면 최소한 다음 식별자를 분리합니다.

• internal_order_id: 제품 내부 주문의 고유 ID
• checkout_session_id: 결제 화면을 시작한 시도 ID
• provider_transaction_id 또는 payment_intent_id: provider 객체 ID
• customer_id: provider 고객과 내부 고객의 매핑 ID
• webhook_event_id: 상태 변경 이벤트의 중복 제거 키

결제 버튼 클릭마다 새 주문과 새 provider 객체를 만드는 구조는 네트워크 재시도에 취약합니다. 동일한 내부 주문에 이미 진행 중인 checkout이 있는지 확인하고, 서버 재시도에는 idempotency 기준을 두며, provider가 알려 준 상태와 내부 상태가 다르면 예외 큐로 보냅니다.

3DS와 실패 복구는 방식별로 따로 설계합니다

3DS는 결제수단이나 거래 조건에 따라 추가 인증이 필요한 흐름입니다. 인증 화면이 나타났다는 것, 고객이 인증을 마쳤다는 것, provider가 결제를 승인했다는 것, 내부 주문이 유료 상태가 됐다는 것은 같은 이벤트가 아닙니다.

아래 순서로 상태를 나누면 hosted·embedded·custom 모두에서 검증 기준을 통일하기 쉽습니다.

1. 내부 주문을 checkout_started로 기록한다.
2. provider session 또는 transaction ID를 저장한다.
3. 결제 요청의 응답과 인증 필요 여부를 별도 필드로 저장한다.
4. redirect 결과만 보지 말고 provider 객체를 다시 조회한다.
5. webhook의 event ID를 중복 제거하면서 수신한다.
6. provider 상태와 내부 주문 상태가 허용된 전이인지 확인한다.
7. 불일치·timeout·고객 중단은 payment_review 같은 예외 상태로 남긴다.

결제 실패·재시도 가드레일을 설계할 때는 결제 승인 실패·재시도 가드레일 체크리스트를, webhook 수신과 재처리를 점검할 때는 결제 webhook 모니터링·replay 가드레일 체크리스트를 함께 볼 수 있습니다. 결제수단 업데이트와 다음 갱신 확인은 B2B SaaS 결제수단 업데이트·만료 카드 복구 체크리스트의 별도 범위입니다.

도입 비용은 개발 기간보다 운영 확인량으로 비교합니다

가격과 기능만 보고 선택하면 운영 비용을 놓치기 쉽습니다. pilot에서는 실제 결제수단 몇 개만으로 다음 시나리오를 재현합니다.

• 정상 승인 후 redirect가 늦게 도착하는 경우
• 3DS 인증이 필요하지만 고객이 중단하는 경우
• provider 결제는 성공했으나 내부 주문 업데이트가 timeout인 경우
• webhook이 중복 도착하거나 순서가 뒤바뀌는 경우
• 브라우저에는 실패로 보였지만 provider에는 처리 중인 경우
• 같은 주문을 고객이 새로고침해 두 번 제출하는 경우

결제 운영에서 중요한 것은 “결제 버튼이 잘 보이는가”만이 아닙니다. 어떤 시도와 주문이 연결됐는지, 누가 언제 어떤 provider 상태를 확인했는지, 사람이 예외 큐를 어떻게 닫았는지를 재현할 수 있어야 합니다.

어떤 방식을 고를지 결정하는 질문

• 출시를 앞당기는 것이 가장 중요하고 기본 checkout 경험으로 충분한가
• 고객이 제품 화면을 떠나지 않아야 하는가
• 회사별 승인 단계·쿠폰·계약 가격·추가 필드를 결제 흐름에 넣어야 하는가
• 결제수단과 provider를 여러 개 연결할 계획인가
• 팀에 프런트엔드·서버·QA가 장기적으로 상태 대사를 맡을 인력이 있는가
• 결제 성공, invoice 발행, entitlement 부여를 각각 검증할 수 있는가

처음에는 hosted로 시작하고 이후 embedded나 custom으로 옮기는 전략도 가능합니다. 다만 내부 주문 ID, 고객 매핑, provider 객체 ID, webhook event ID를 초기에 남겨 두면 전환 비용을 줄일 수 있습니다. 반대로 처음부터 custom으로 시작해야 한다면 화면 요구사항보다 예외 상태와 운영자 확인 화면을 먼저 정의해야 합니다.

공개 전 체크리스트

• [ ] 신규 구매 checkout과 사후 billing portal의 범위를 분리했다.
• [ ] hosted·embedded·custom의 선택 이유와 책임 경계를 문서화했다.
• [ ] 3DS 필요·완료·실패와 결제 확정 상태를 구분했다.
• [ ] redirect, provider object, webhook, 내부 주문 상태를 각각 확인한다.
• [ ] 내부 주문 ID와 provider session·transaction ID를 매핑한다.
• [ ] 재시도·중복 제출·timeout·webhook 중복 시나리오를 시험했다.
• [ ] PCI·법률·세무 자문 또는 결제 성공 보장처럼 읽히는 표현을 제거했다.
• [ ] 실제 계정·국가·결제수단별 지원 범위와 가격을 공식 문서에서 다시 확인한다.

공식 참고 문서

원문: 원문기사 보기

원문: 원문기사 보기

원문: 원문기사 보기

원문: 원문기사 보기

원문: 원문기사 보기

원문: 원문기사 보기

원문: 원문기사 보기

공식 문서의 기능·지원 결제수단·가격은 provider, 국가, 계정 설정과 시점에 따라 달라질 수 있습니다. 실제 도입 전에는 해당 계정의 현재 문서와 테스트 결과를 기준으로 확인하십시오.