비교 / 체크아웃
호스티드 체크아웃 vs 자체 구축
온라인으로 결제를 받는 모든 가맹점은 한 번쯤 이 질문에 답해야 합니다. 카드 정보를 받는 페이지는 우리 것인가, 결제 제공사의 것인가. 이 답이 PCI 범위, 결제수단을 얼마나 빨리 추가할 수 있는지, 카드 브랜드의 의무 규정이 적용될 때 누가 대응하는지를 결정합니다. 기술 선택이라기보다, 팀이 한 해를 무엇에 쓸 것인가에 대한 결정입니다.
옵션 비교
결정을 가르는 일곱 가지 질문
호스티드 체크아웃이 유리한 경우
대부분의 기업에, 대부분의 경우에 그렇습니다. 결제가 판매하는 상품이 아니라 대금을 받는 수단이라면 체크아웃 페이지는 경쟁력이 있는 곳이 아닙니다. 그런데 이를 직접 소유하는 비용은 가장 눈에 띄지 않는 방식으로 치러집니다. 엔지니어링 역량의 일정 부분이 제품이 아니라 카드 브랜드 의무 규정과 결제수단 연동에 영구적으로 쓰이는 것입니다. 또한 호스티드 페이지는 직접 구축할 때 가장 큰 숨은 비용인 PCI 문제를 한 번에 해소합니다.
- 01결제가 제품 자체가 아니라 매출을 만드는 수단일 때
- 02카드 정보를 조심스럽게 다루기보다 범위 밖에 두고 싶을 때
- 03새 결제수단이 자사 릴리스 없이 추가되어야 할 때
- 04엔지니어의 시간이 고객이 구매하는 제품에 더 가치 있을 때
자체 구축이 유리한 경우
체크아웃이 곧 제품일 때입니다. 타인을 대신해 결제를 처리하는 플랫폼, 어떤 호스티드 페이지로도 표현할 수 없는 플로우를 가진 비즈니스, 전환율 소수점 이하의 차이가 결제팀 인건비보다 큰 거래량의 팀이라면 구축할 만한 정당한 이유가 있습니다. 카드 처리 영역을 자사 경계 안에 두어야 하는 규제상의 위치도 마찬가지입니다. 그 규모에 못 미친다면 자체 구축은 대개 호스티드 체크아웃이 왜 존재하는지를 비싼 값을 치르고 다시 확인하는 일이 됩니다.
- 01결제가 곧 제품이며, 타인을 대신해 처리할 때
- 02거래량이 충분히 커서 한계 전환율의 이득이 팀 비용을 넘어설 때
- 03규제 당국이나 리스크 위원회가 해당 영역을 자사 경계 안에 둘 것을 요구할 때
- 04플로우가 정말 특이해서 어떤 호스티드 페이지로도 표현할 수 없을 때
Protocore의 위치
Protocore Gateway는 호스티드 방식의 답이며, 흔히 따로 판매하는 예외 옵션도 처음부터 포함되어 있습니다. 페이지를 Protocore 도메인이나 귀사 도메인에서 운영하고, 플로우상 필요하면 결제 필드를 귀사 레이아웃 안에 임베드하며, 같은 체크아웃을 앱 안에서 네이티브로 제공할 수도 있습니다. 카드, 월렛, 계좌이체, USDC가 한 페이지에 모이고, 하나의 주문 참조에 대해 하나의 EUR 금액으로 정산됩니다. 그리고 가맹점이 아니라 제공사가 되고 싶다는 것이 솔직한 답이라면, 같은 플랫폼을 whitelabel로 이용할 수 있습니다. 게이트웨이를 처음부터 구축하는 것보다 대개 더 나은 선택입니다.
- 01호스티드 페이지, 자체 도메인, 임베디드 필드, 인앱 — 모두 같은 연동으로
- 02카드, 월렛, 계좌이체, USDC를 한 페이지에서, EUR로 정산
- 03체크아웃부터 영수증, 은행 입금 내역까지 하나의 주문 참조
- 04가맹점이 아닌 제공사가 되고 싶다면 whitelabel로 이용 가능
어느 쪽인지 고민되시나요?
거래량, 결제수단, 엔지니어가 지금 하고 있는 일을 알려 주세요. 직접 구축하는 편이 맞는 경우까지 포함해, 어떤 방식이 맞는지 솔직하게 말씀드리겠습니다.