결제 오케스트레이션 플랫폼 비교 2026, Primer·Spreedly·Recurly를 routing·vault·reconciliation 기준으로 고르는 법
결제 오케스트레이션 플랫폼 비교 2026, Primer·Spreedly·Recurly를 routing·vault·reconciliation 기준으로 고르는 법
결제 오케스트레이션 플랫폼을 고를 때 “PSP를 몇 개 연결할 수 있는가”만 비교하면 실제 운영 난이도를 놓치기 쉽습니다. 장애가 났을 때 어떤 거래를 어느 경로로 넘길지, 저장된 결제수단을 새 경로에서 다시 쓸 수 있는지, 승인·취소·환불·정산 데이터를 월말에 한 건씩 맞출 수 있는지가 더 중요합니다.
Primer·Spreedly·Recurly는 모두 여러 결제 게이트웨이와 결제 운영을 다루지만 완전히 같은 범위의 제품은 아닙니다. Primer와 Spreedly는 여러 결제 서비스 제공업체를 연결하고 routing·vault·운영 최적화를 구성하는 범용 결제 인프라 성격이 강합니다. Recurly는 구독 청구와 갱신, 결제 복구를 기준 시스템으로 운영하면서 여러 gateway를 활용하려는 팀에 더 가까운 후보입니다.
기능과 공식 페이지는 2026년 7월 31일 확인 기준입니다. 세 제품 모두 공개 페이지만으로 모든 가격, 국가별 연결 범위, 계약별 기능을 확정하기 어렵습니다. 거래량, 결제수단, PSP 계약, vault 이전, 전문 서비스, 지원 수준을 포함한 개별 견적을 받아야 합니다.
이 글은 제품 비교와 운영 체크리스트이며 법률·세무·회계·PCI DSS 준수 조언이 아닙니다. 특정 플랫폼을 도입한다고 규제, 보안 또는 카드 데이터 책임이 자동으로 해소되는 것도 아닙니다. 승인율 상승이나 결제 비용 절감 역시 보장되지 않으며, 같은 거래군을 이용한 통제된 pilot로 검증해야 합니다.
먼저 결론: 오케스트레이션 계층의 역할부터 정합니다
세 후보의 이름보다 먼저 “오케스트레이션 계층이 무엇을 소유할 것인가”를 정해야 합니다.
| 선택 상황 | 우선 검토 후보 | 반드시 확인할 경계 |
|---|---|---|
| checkout부터 여러 결제 processor 연결, workflow, vault, reconciliation과 observability를 한 운영 계층에서 검토 | Primer | 필요한 connector, 국가·결제수단, workflow 실행 조건, 대사 데이터의 실제 범위 |
| 기존 checkout·상거래 시스템을 유지하면서 portable vault와 여러 gateway 연결, routing 최적화를 검토 | Spreedly | token portability, gateway별 기능 차이, Optimize 적용 조건과 통제권 |
| 구독·invoice·갱신을 중심으로 여러 gateway와 결제 복구를 함께 운영 | Recurly | subscription이 기준 시스템인지, gateway routing 범위, 결제수단 이전과 청구 상태 전이 |
선택 전에 다음 질문에 답합니다.
- subscription·invoice는 기존 billing 시스템에 남길 것인가.
- 결제 orchestration이 checkout과 payment workflow까지 소유할 것인가.
- 카드 등 결제수단 토큰의 기준 vault는 어디인가.
- routing 규칙을 누가 만들고 승인하며 되돌릴 것인가.
- processor 응답, platform event, 정산 파일의 공통 거래키는 무엇인가.
- 플랫폼 장애 때 bypass 또는 rollback 경로가 있는가.
기존 billing 시스템을 유지해야 하는데 새 플랫폼이 subscription 상태까지 소유하도록 설계하면 두 기준 시스템이 충돌합니다. 반대로 구독 청구를 새로 통합하려는 팀이 범용 routing 계층만 도입하면 invoice·dunning·갱신 문제는 그대로 남습니다.
Primer는 workflow와 운영 가시성을 함께 봅니다
Primer의 Unified Payment Infrastructure는 결제 연결과 workflow를 통합 인프라 관점에서 설명합니다. Primer를 평가할 때는 connector 목록뿐 아니라 checkout 또는 서버 결제 요청이 어떤 workflow를 거쳐 processor로 전달되고, 실패·3DS·취소·환불이 어떤 상태로 남는지 확인해야 합니다.
Primer가 후보가 되기 쉬운 상황은 다음과 같습니다.
- 여러 시장에서 processor와 결제수단을 추가하면서 애플리케이션 코드를 매번 크게 바꾸고 싶지 않습니다.
- routing, retry, fraud 관련 단계와 사후 결제 작업을 한 workflow로 통제하려고 합니다.
- 결제수단을 중앙 vault에 저장하고 processor 변경 가능성을 확보하려고 합니다.
- finance와 payment operations가 거래 흐름과 대사 예외를 같은 운영 계층에서 추적해야 합니다.
Primer Centralized Vault는 중앙화된 결제수단 저장 구조를 검토하는 출발점입니다. 다만 “중앙 vault”라는 이름만으로 모든 token이 어떤 processor에서도 즉시 사용된다고 가정하면 안 됩니다. 원본 결제수단 수집 방식, network token 또는 processor token과의 관계, 지원 결제수단, 고객 재인증, export 절차와 계약 종료 시 이전 조건을 서면으로 확인합니다.
Primer Reconciliation과 Primer Observability는 결제 이후 운영을 평가할 때 확인할 공식 자료입니다. pilot에서는 dashboard가 보기 좋은지보다 authorization, capture, refund, dispute, processor fee, payout을 공통 거래키로 추적할 수 있는지 확인합니다. 데이터 도착 지연과 누락, 수동 조정, export·API 범위도 실제 월말 표본으로 검증해야 합니다.
Primer가 결제 workflow를 통합해도 processor 계약, acquiring 조건, chargeback 운영과 규제 책임까지 대신 확정해 주는 것은 아닙니다. 어떤 기능이 선택한 connector와 계약에서 제공되는지 따로 확인해야 합니다.
Spreedly는 vault 이동성과 gateway 추상화 수준을 봅니다
Spreedly Payment Orchestration은 여러 결제 서비스와 연결해 결제를 운영하는 오케스트레이션 범위를 설명합니다. Spreedly를 검토하는 핵심은 gateway 수를 세는 것이 아니라 기존 상거래 시스템과 Spreedly 사이의 책임선을 정하는 것입니다.
예를 들어 주문·가격·세금·subscription은 기존 시스템이 소유하고, Spreedly는 결제수단과 gateway 호출을 담당할 수 있습니다. 이때 주문 ID, payment attempt ID, Spreedly transaction ID와 gateway transaction ID를 모두 저장해야 장애와 환불을 추적할 수 있습니다.
Spreedly Vault를 평가할 때는 다음 항목을 확인합니다.
| vault 항목 | 확인 질문 |
|---|---|
| 수집 | 브라우저와 모바일에서 민감 데이터를 어떤 방식으로 token화하는가 |
| 재사용 | 저장 token을 어떤 gateway·merchant account 조합에서 사용할 수 있는가 |
| 이동 | 기존 vault import와 향후 export는 어떤 절차와 비용이 필요한가 |
| 수명주기 | 카드 갱신, 계정 업데이트, 삭제 요청과 보존 정책을 어떻게 처리하는가 |
| 장애 | vault 또는 API가 지연될 때 신규 결제와 기존 token 결제가 어떻게 달라지는가 |
Spreedly Optimize는 routing과 결제 성능 개선 기능을 검토할 출발점입니다. 그러나 Optimize 또는 smart routing을 켰다는 사실만으로 승인율 상승을 확정하면 안 됩니다. merchant account, issuer, 국가, 통화, 결제수단, 고객군과 시간대가 결과에 영향을 줍니다.
자동 최적화를 도입해도 고액 거래, 인증이 필요한 거래, 특정 지역의 local acquiring처럼 우선 경로가 고정돼야 하는 조건은 별도 guardrail로 둡니다. 알고리즘 추천과 사업 규칙이 충돌할 때 무엇이 우선하는지, 결정 이유를 나중에 감사할 수 있는지도 확인합니다.
Spreedly가 범용 결제 계층이라는 점은 장점이면서 범위 제한입니다. subscription catalog, invoice, proration, dunning의 기준 시스템이 필요하다면 별도 billing 제품과의 통합 비용을 견적에 포함해야 합니다.
Recurly는 구독 청구 중심의 오케스트레이션으로 구분합니다
Recurly Payments Orchestration는 구독 비즈니스의 결제 routing과 recovery 맥락에서 제품을 설명합니다. Recurly를 Primer·Spreedly와 비교할 때는 범용 payment layer와 동일한 범위라고 보지 말고, subscription·invoice·renewal을 Recurly에서 운영할 것인지 먼저 결정합니다.
Recurly가 우선 후보가 되기 쉬운 상황은 다음과 같습니다.
- 구독 상품, 고객, invoice, 갱신과 결제 실패 상태를 하나의 billing 계층에서 운영하려고 합니다.
- 여러 gateway를 연결하되 routing의 목적이 반복 결제 성공과 revenue recovery에 가깝습니다.
- finance·support가 결제 결과를 subscription 상태와 함께 확인해야 합니다.
- billing migration을 감수하고 기존 자체 청구 로직을 줄이려 합니다.
Recurly Payment Gateways 문서에서 gateway 구성의 공식 범위를 확인할 수 있습니다. 실제 비교에서는 지원 목록만 보지 말고 선택한 국가, 통화, 결제수단, merchant account와 Recurly site 조합을 대입해야 합니다. gateway별로 authorization, capture, refund, 3DS, network token, account updater와 실패 응답 처리 범위가 다를 수 있습니다.
기존 billing 시스템을 유지한 채 routing만 바꾸려는 팀에는 Recurly 도입이 과도한 데이터 모델 변경이 될 수 있습니다. 반대로 subscription migration까지 계획한 팀은 결제 routing만이 아니라 미청구 usage, credit, coupon, cancel 예약, dunning 중인 invoice와 결제수단을 함께 이전해야 합니다. 세 후보의 총비용을 비교할 때 이 범위 차이를 반드시 반영합니다.
Routing은 “실패하면 다른 PSP”보다 정교해야 합니다
routing 규칙은 단순한 우선순위 목록이 아닙니다. 첫 결제가 실패한 이유를 구분하지 않고 다른 processor로 즉시 재시도하면 중복 승인, 추가 비용, issuer의 fraud 의심과 고객 불만이 생길 수 있습니다.
최소 routing matrix는 다음 조건을 포함합니다.
| 조건 | routing 설계 질문 |
|---|---|
| 국가·통화 | local acquiring 또는 특정 merchant account가 필요한가 |
| 결제수단 | 카드, wallet, 계좌 방식별 지원 경로가 무엇인가 |
| 고객 인증 | 3DS·SCA 같은 추가 인증을 어느 경로에서 처리하는가 |
| 실패 코드 | 일시 오류, hard decline, 인증 필요, 설정 오류를 구분하는가 |
| 거래 유형 | 최초 결제, 반복 결제, 카드 저장, 환불의 경로가 다른가 |
| 위험·비용 | fraud 정책과 비용 조건이 승인 가능성보다 우선하는 경우가 있는가 |
| 장애 상태 | health signal을 누가 판단하고 언제 자동 전환·복구하는가 |
failover는 B2B SaaS 결제 공급사 failover·multi-gateway 준비 체크리스트와 연결해 준비합니다. 이미 발생한 장애의 대응 역할과 고객 공지는 B2B SaaS 결제 공급사 장애 대응 체크리스트를 함께 적용합니다.
pilot에서는 성공 거래만 보내지 말고 timeout, processor 5xx, 인증 필요, hard decline, 부분 capture, 중복 webhook을 의도적으로 만듭니다. 첫 경로가 timeout인 상태에서 두 번째 경로로 넘기기 전에 원거래 결과를 조회하는지, 늦게 도착한 성공 응답을 중복 주문으로 막는지도 확인합니다.
Vault는 저장 기능보다 미래의 이동 가능성을 봅니다
vault 도입의 핵심은 카드번호를 직접 보지 않는 것만이 아닙니다. processor 종속을 낮추려는 목적이라면 token이 실제로 어느 merchant account와 gateway에서 사용 가능한지 알아야 합니다.
도입 전 다음 문서를 요청합니다.
- 기존 processor 또는 vault에서 import할 수 있는 데이터 형식과 절차
- 플랫폼 종료 시 export 가능한 결제수단과 제외 항목
- processor token, platform token, network token의 매핑 방식
- 고객 재인증 또는 결제수단 재등록이 필요한 조건
- 삭제·보존·접근 권한과 audit log 정책
- vault 장애, key rotation과 incident notification 절차
PCI 범위는 플랫폼 설명만으로 판단하지 않습니다. checkout 구현, 서버가 받는 데이터, 로그와 지원 도구, 위탁업체 구조에 따라 책임 범위가 달라질 수 있습니다. 필요한 SAQ나 계약상 역할은 보안·법무 담당자 및 자격 있는 전문가와 별도로 확인해야 합니다.
Reconciliation은 월말에 설명 가능한지를 봅니다
승인 성공은 현금 정산 완료와 같지 않습니다. authorization 뒤 capture가 실패할 수 있고, partial refund·chargeback·processor fee·환전·reserve 때문에 주문 금액과 payout 금액도 다를 수 있습니다.
대사 모델에는 적어도 다음 키와 상태가 필요합니다.
order_id
subscription_id 또는 invoice_id
payment_attempt_id
orchestration_transaction_id
gateway_transaction_id
authorization_id / capture_id / refund_id
payout_id
currency / gross / fee / net
event_time / settlement_date
한 개의 transaction ID만 데이터 웨어하우스에 저장하면 processor portal과 payout 파일을 연결하기 어렵습니다. 플랫폼 event, gateway 보고서, bank 입금의 세 계층을 구분하고 차이를 예외 queue로 보냅니다.
월말 pilot에서는 정상 승인 외에 부분 capture, 전액·부분 환불, 다음 달 도착한 dispute, 서로 다른 통화, fee 조정, payout 지연을 포함합니다. invoice와 정산을 연결하는 실무 절차는 B2B SaaS 구독 청구 월말 대사 체크리스트를 적용할 수 있습니다.
대시보드에서 총액이 맞아 보여도 원천 데이터 export, 재처리, 수동 조정의 승인 기록이 없으면 감사 가능한 운영이라고 보기 어렵습니다. 누락 데이터의 재수집 시간과 대사 예외를 닫는 평균 시간도 제품 비교 지표에 포함합니다.
가격은 공개 숫자 대신 같은 거래 시나리오로 견적을 받습니다
Primer·Spreedly·Recurly의 공개 정보만으로 모든 팀에 적용되는 총비용을 계산하기 어렵습니다. 계약 문의 전에 같은 조건표를 세 후보에 보내야 범위가 다른 견적을 잘못 비교하지 않습니다.
| 견적 항목 | 포함할 조건 |
|---|---|
| 거래 | 월 authorization·capture·refund 수, 평균 금액, peak TPS |
| 시장 | 국가, 통화, 카드·wallet·계좌 결제 비중 |
| 연결 | processor, gateway, merchant account 수와 추가 계획 |
| vault | 저장 결제수단 수, import·export, updater·network token 요구 |
| routing | 규칙 수, 자동 최적화, retry와 failover 범위 |
| 운영 | reconciliation, observability, raw data export, 보존 기간 |
| 지원 | SLA, incident 지원, sandbox, 전문 서비스와 교육 |
| billing | subscription·invoice 기능 포함 여부와 migration 범위 |
플랫폼 요금 외에도 processor fee, cross-border·환전, fraud 도구, 개발·운영 인력, 데이터 파이프라인, migration, 장애 대응 비용을 합칩니다. 계약 최소액, 초과 과금, connector 추가 비용, 지원 등급과 종료 시 데이터 반출 비용도 확인합니다.
“승인율이 몇 퍼센트 오른다”거나 “비용이 자동으로 줄어든다”는 표현은 자체 데이터로 검증하기 전 예산안에 확정 수치로 넣지 않습니다. 기존 경로를 control group으로 유지하고 같은 국가·issuer·금액·고객군을 나눠 승인율, 순매출, processor 비용, false decline, chargeback과 고객 문의를 함께 비교합니다.
같은 pilot로 세 후보를 검증하는 방법
2~4주의 작은 pilot에서도 제품 범위 차이를 확인할 수 있습니다.
[checkout 또는 subscription invoice]
↓
[vault token + payment attempt ID]
↓
[routing 규칙 → PSP A / PSP B]
↓
[승인·capture·refund·dispute event]
↓
[gateway report → payout → 월말 대사]
검증 시나리오는 다음처럼 고정합니다.
- 국내·해외 카드의 정상 최초 결제와 반복 결제
- PSP A timeout 뒤 결과 조회와 조건부 PSP B 전환
- 인증 필요 거래와 hard decline의 재시도 차단
- 같은 idempotency key로 중복 요청과 순서가 뒤바뀐 webhook
- 부분 capture, 부분 환불과 늦게 도착한 dispute
- vault token을 다른 gateway 경로에서 사용하는 테스트
- platform·gateway·payout 데이터의 거래 단위 대사
- routing 변경의 승인, audit log와 rollback
구독 청구 자체를 바꾼다면 B2B SaaS 구독 관리 플랫폼 비교로 제품 경계를 먼저 확인하고, B2B SaaS 구독 청구 플랫폼 마이그레이션 체크리스트에 따라 customer·subscription·invoice·payment method 상태를 함께 검증합니다.
결과표에는 평균 승인율만 쓰지 않습니다. 국가·issuer·결제수단별 승인율, 중복 결제 수, 수동 복구 시간, 대사 예외율, 환불 완료 시간, 고객 문의, 전체 비용을 나눠 기록합니다. 표본이 작거나 실험군의 거래 구성이 다르면 성과 판단을 보류합니다.
도입 전 최종 체크리스트
- 범용 결제 인프라가 필요한지 구독 billing 중심 플랫폼이 필요한지 구분했는가.
- subscription·invoice·order·payment의 기준 시스템을 각각 정했는가.
- Primer·Spreedly와 Recurly의 제품 범위 차이를 견적에 반영했는가.
- 국가·통화·결제수단별 connector와 gateway 지원을 서면 확인했는가.
- routing 규칙의 owner, 승인, audit log와 rollback 절차가 있는가.
- timeout과 decline을 구분하고 무조건적인 교차 PSP 재시도를 막았는가.
- vault token의 import·export와 gateway 간 재사용 범위를 시험했는가.
- platform, gateway, payout을 잇는 공통 거래키를 저장하는가.
- 부분 capture·환불·dispute·fee를 포함해 월말 대사를 실행했는가.
- 공개 가격만 믿지 않고 같은 거래 조건으로 총비용 견적을 받았는가.
- 승인율·비용 효과를 통제된 pilot에서 순매출과 고객 영향까지 측정했는가.
- 플랫폼 장애 때 bypass, 고객 공지, 복구와 사후 검토 절차가 있는가.
- 법률·세무·회계·PCI 판단을 제품 마케팅 문구로 대신하지 않았는가.
마무리
Primer·Spreedly·Recurly 중 어느 제품이 항상 우월한 것은 아닙니다. 결제 workflow와 vault, reconciliation, observability를 넓은 운영 계층에서 통합하려면 Primer를, 기존 상거래 시스템을 유지하며 portable vault와 여러 gateway 연결·최적화를 원하면 Spreedly를 우선 검토할 수 있습니다. 구독·invoice·갱신을 기준 시스템으로 두고 결제 routing과 recovery를 함께 운영하려면 Recurly가 더 가까운 후보입니다.
최종 선택은 connector 수가 아니라 실패한 거래를 안전하게 복구하고, 저장 결제수단을 계획대로 이동하며, 월말에 정산 차이를 설명할 수 있는지로 결정해야 합니다. 같은 실패 시나리오와 같은 거래 표본을 세 후보에 적용하고, 성과를 보장 문구가 아닌 실제 운영 증거로 비교하십시오.
함께 보면 좋은 글
- B2B SaaS 결제 공급사 failover·multi-gateway 준비 체크리스트
- B2B SaaS 결제 공급사 장애 대응 체크리스트
- B2B SaaS 구독 관리 플랫폼 비교
- B2B SaaS 구독 청구 플랫폼 마이그레이션 체크리스트
- B2B SaaS 구독 청구 월말 대사 체크리스트
- 결제 토큰 이전 체크리스트: vault export·고객 매핑·재인증
\n
\n
공식 출처
- Primer – Unified Payment Infrastructure
- Primer – Centralized Vault
- Primer – Reconciliation
- Primer – Observability
- Spreedly – Payment Orchestration
- Spreedly – Vault
- Spreedly – Optimize
- Recurly – Payments Orchestration
- Recurly Docs – Payment Gateways
최종 확인일: 2026-07-31. 가격, 기능, connector, 지원 범위와 계약 조건은 변경될 수 있으므로 도입 직전 공식 페이지와 개별 견적을 다시 확인하세요.
About The Author
