대안 / 화이트라벨

화이트라벨 결제 게이트웨이 대안을 찾고 계신가요

화이트라벨은 판매하는 쪽에 따라 의미가 크게 다릅니다. 체크아웃에 로고 한 칸을 넣는 수준일 때도 있고, 직접 운영하는 결제 사업 전체일 때도 있습니다. 이 차이가 가치의 대부분이지만 데모에서는 거의 드러나지 않습니다. 이 차이를 가려내는 질문들입니다.

평가 기준

차이를 드러내는 여섯 가지 질문.

01

화면의 얼마만큼이 실제로 내 것인가요?

결제 페이지, 가맹점 백오피스, 운영자 콘솔, 이메일, 영수증, 그리고 이들이 놓이는 도메인입니다. 공급사 이름이 남아 있는 곳마다 가맹점은 실제 운영 주체를 알게 됩니다.

02

멀티 머천트인가요, 서브 계정이 달린 단일 계정인가요?

처음부터 멀티 머천트로 만든 플랫폼은 온보딩, 등급 관리, 권한, 격리를 제공합니다. 단일 가맹점 제품을 개조한 플랫폼에서는 이것들이 로드맵으로만 존재합니다.

03

자체 가격 정책을 구성할 수 있나요?

가맹점별, 결제수단별, 통화별, 거래량 구간별로 요금을 설정하고, 실패한 시도에는 별도 규칙을 적용할 수 있어야 합니다. 요금이 고정된 표라면 수익 모델은 귀사가 아니라 벤더의 것입니다.

04

PCI 범위는 어디에 귀속됩니까?

SaaS에서는 카드 처리 영역을 벤더가 맡고 가맹점이 그 적합성을 이어받아야 합니다. 자체 인프라에 배포하면 그 책임이 귀사로 넘어옵니다. 어느 쪽이든 타당하지만, 어느 쪽을 구매하는지는 알고 계셔야 합니다.

05

보유한 매입사를 연결할 수 있습니까?

기존 거래 관계와 수수료율이 사업성의 근거인 경우가 많습니다. 자체 결제망으로만 라우팅하는 플랫폼은 전혀 다른, 훨씬 작은 제안입니다.

06

SaaS만 가능합니까, 자체 인프라도 가능합니까?

규제 당국이나 리스크 위원회가 결국 시스템을 귀사 내부망에 두도록 요구할 수 있다면, 가맹점을 이전한 뒤가 아니라 지금 가능 여부부터 확인하십시오.

01

실제로 구매하는 것

체크아웃이 아니라 직접 운영할 수 있는 결제 사업입니다. 가맹점 라이프사이클(온보딩, 서류, 등급 관리, 권한, 기존 가맹점 이전), 자금 흐름(수수료 구성, 정산, 롤링 리저브, 대사, 명세서), 운영(역할, 권한, 감사, 큐, 트레이싱), 그리고 카드 브랜드 의무 규정이 적용될 때마다 이 모두를 최신 상태로 유지하는 엔지니어링까지 포함합니다. 이 중 하나라도 빠진 플랫폼은 결국 귀사가 직접 만들어야 하고, 그것이 애초에 피하려던 일입니다.

  1. 01결제 페이지만이 아닌 가맹점 라이프사이클 전체
  2. 02귀사의 요금 체계를 따르는 수수료 구성과 정산
  3. 03역할, 감사, 트레이싱을 갖춘 운영자 콘솔
  4. 04카드 브랜드 규정과 인증 대응을 대신 맡아 주는 파트너
02

너무 늦게 답을 얻는 질문들

기존 가맹점의 이전, 저장된 카드의 토큰 이전 여부, 배포 방식별 PCI 입장 변화, 아직 없는 커넥터가 필요할 때 누가 만드는지가 그 질문들입니다. 이 중 어느 것도 데모에는 나오지 않지만 모두 2년 차에 플랫폼이 제대로 작동할지를 좌우하며, 믿을 만한 벤더라면 계약 전에 구체적으로 답할 수 있습니다.

  1. 01기존 가맹점이 어떻게 이전되며 기간은 얼마나 걸리는가
  2. 02저장된 카드가 토큰으로 이전되는가, 초기화되는가
  3. 03필요한 커넥터를 누가 개발하고 인증하는가
  4. 04배포 방식별로 PCI 입장이 어떻게 달라지는가
03

Protocore의 위치

당사의 화이트라벨 플랫폼은 이 여섯 가지 질문에 이렇게 답합니다. 어느 화면에도 Protocore라는 이름이 나오지 않습니다. 첫 줄부터 멀티 머천트로 설계되었으며 온보딩, 등급 관리, 권한이 포함됩니다. 수수료는 고정이 아니라 구성하는 방식입니다. 카드 처리 영역은 SaaS에서는 당사가, 온프레미스에서는 귀사가 맡습니다. 귀사의 매입사가 당사 매입사와 나란히 연결되며 새 연동은 프로젝트의 일부로 개발합니다. 배포는 SaaS, 귀사 클라우드, 온프레미스 중에서 선택합니다. 정산에 이상이 보일 때 답하는 팀은 그 시스템을 만든 팀입니다. 당사는 프로덕트 스튜디오이며, 이것이 흔히 말하는 “전담 지원”의 솔직한 모습입니다.

  1. 01도메인을 포함한 모든 화면에 귀사의 브랜드 적용
  2. 02라이프사이클까지 포함한 멀티 머천트 설계
  3. 03귀사의 매입사, 귀사의 요금, 귀사의 배포 방식
  4. 04플랫폼을 소유한 엔지니어에게 직접 연락 가능

FAQ

누구에게나 던져볼 만한 질문.

  • 결제 페이지, 가맹점 백오피스, 운영자 콘솔이 귀사의 브랜드와 도메인으로 제공되어야 하며, 가맹점 온보딩, 자체 요금 설정, 정산도 포함되어야 합니다. 이 중 하나라도 벤더의 이름이 보이거나 벤더의 수익 모델을 강제한다면, 화이트라벨 플랫폼이 아니라 브랜드만 바꾼 체크아웃입니다.

  • 운영하는 사업에 대해 해당 시장이 요구하는 라이선스가 필요하며, 소프트웨어 공급사는 규제 대상이 아닙니다. 대부분의 사업자는 자체 매입 또는 소개받은 매입사를 통해 운영합니다. 벤더가 자금 흐름에 관여하는지 반드시 구체적으로 확인하십시오. 그에 따라 답이 달라집니다.

  • 대량 이전이 가능해야 하고, 저장된 카드는 토큰으로 옮겨지며, 기존 플랫폼이 정산을 마무리하는 동안 두 플랫폼이 병행 운영되어야 합니다. 계약 전에 이전 계획서를 요청하십시오. 경험이 없는 벤더는 추상적으로만 설명합니다.

  • 규제 당국, 은행, 리스크 위원회가 시스템을 내부망에 둘 것을 요구하는 등 구체적인 사유가 없다면 SaaS를 권합니다. 온프레미스는 PCI 범위와 운영 부담이 귀사로 넘어오므로, 실제로 필요할 때만 감수할 가치가 있는 비용입니다.

귀사의 브랜드로 직접 확인하십시오.

실제 운영 중인 플랫폼 시연, 체크아웃과 콘솔에 적용된 귀사의 아이덴티티, 그리고 귀사의 거래량 기준으로 본 이전과 수익성에 대한 솔직한 진단을 제공합니다.