비교 / 카테고리
결제 게이트웨이 vs 결제 오케스트레이션
두 용어는 흔히 혼용되지만 의미는 다릅니다. 게이트웨이는 결제를 받습니다. 결제수단을 제시하고, 승인하고, 매입하고, 정산합니다. 오케스트레이션 플랫폼은 게이트웨이 위에서 거래마다 어느 게이트웨이를 쓸지 결정합니다. 두 번째가 필요한지는 이미 몇 개의 제공사를 쓰고 있는지, 그리고 왜 쓰고 있는지에 거의 전적으로 달려 있습니다.
카테고리 비교
각 레이어는 실제로 무엇을 위한 것인가
게이트웨이만으로 충분한 경우
제공사가 하나이거나 처음 고르는 단계라면, 오케스트레이션 레이어가 오케스트레이션할 대상이 없습니다. 매입사 간 라우팅, 거절 건의 두 번째 제공사 캐스케이딩, 구간별 요율 차익 활용 같은 이점은 이미 여러 제공사와 거래하고 있다는 전제에서 성립합니다. 게이트웨이 하나 위에 레이어를 얹으면 수수료와 불필요한 홉만 늘어납니다. 이 단계에서 실제로 수치를 움직이는 것은 결제 수단 커버리지, 전환율 높은 체크아웃, 깔끔한 대사입니다.
- 01제공사가 하나이거나 처음 선택하는 단계입니다
- 02전환율 문제의 원인이 라우팅이 아니라 결제 수단 커버리지입니다
- 03여러 매입사와의 관계를 직접 관리하고 싶지 않습니다
- 04승인율 1%p보다 하나의 대사 모델이 더 중요합니다
오케스트레이션이 수수료값을 하는 경우
거래량이 커서 0.1%가 실제 금액으로 의미를 갖고, 시장, 리스크 프로파일, 요율을 한 곳에서 모두 충족할 수 없어 이미 여러 매입 계약을 보유한 경우입니다. 이 규모에서는 발급사·구간별 라우팅, 소프트 디클라인의 두 번째 매입사 캐스케이딩, 제공사 간 리포트 표준화가 좋은 아이디어를 넘어 손익계산서의 한 항목이 됩니다. 전제 조건은 언제나 같습니다. 유지할 이유가 있는 복수의 제공사입니다.
- 01커버리지, 이중화, 요율을 위해 이미 여러 매입사를 운영하고 있습니다
- 02거래량 덕분에 승인율 1%p의 가치가 레이어 수수료보다 큽니다
- 03서로 다른 기준을 쓰는 제공사들을 하나의 리포트 모델로 통합해야 합니다
- 04제공사 간 페일오버는 있으면 좋은 기능이 아니라 비즈니스 요건입니다
Protocore의 위치
Protocore Gateway는 결제를 받고 자금을 정산하는 첫 번째 레이어입니다. 단일 제공사 비즈니스에 필요한 두 번째 레이어의 기능은 위에 얹어 파는 대신 내장했습니다. 읽을 수 있는 라우팅 정책, 고객에게 실패가 보이기 전에 대체 경로로 수행하는 재시도, 운영자가 바로 조치할 수 있는 언어로 제공하는 거절 사유입니다. 직접 보유한 매입사 간에 라우팅이 정말 필요한 시점이 오면, 화이트라벨 플랫폼에서 고객사의 매입사를 저희 매입사와 함께 연결합니다. 솔직한 결론은, 이 질문을 하는 대부분의 기업에 필요한 것은 지금 쓰는 게이트웨이 위의 레이어가 아니라 더 나은 게이트웨이라는 점입니다.
- 01라우팅 및 재시도 정책이 포함된, 정산까지 하는 게이트웨이
- 02카드, 월렛, 계좌이체, USDC를 하나의 페이지와 하나의 레퍼런스로
- 03화이트라벨 플랫폼에서 보유 매입사를 Protocore 매입사와 함께 연결
- 04단일 제공사 오케스트레이션에 레이어 수수료 없음
문제는 어느 레이어에 있나요?
운영 중인 제공사 수와 결제가 실패하는 지점을 알려 주세요. 해결책이 라우팅인지 게이트웨이 자체인지 말씀드리겠습니다.