B2B SaaS 다중 통화 가격표시·청구·정산 비교 2026, 환율·반올림·환불 정책을 고르는 기준

해외 고객을 받기 시작한 B2B SaaS는 “달러 가격을 그대로 보여줄지, 고객 국가의 통화로 보여줄지”를 결정해야 합니다. 그러나 가격표에 표시되는 통화와 실제 결제에 사용되는 통화, 사업자 계좌에 정산되는 통화가 항상 같지는 않습니다. 이 세 가지를 하나의 currency 값으로 처리하면 환율·반올림·환불·매출 보고서에서 원인을 찾기 어려워집니다.

이 글은 신규 checkout 화면을 어떻게 구현할지 비교하는 글이 아닙니다. B2B SaaS hosted checkout·embedded payment form 비교가 화면 구현과 3DS·상태 검증을 다룬다면, 여기서는 통화별 가격 정책과 금액의 증거를 어떻게 보존할지에 집중합니다. 고객용 결제수단 변경과 인보이스 조회는 셀프서비스 빌링 포털 비교의 범위입니다.

환율·세금·회계·규제 준수에 관한 법률 또는 세무 자문이 아니며 특정 provider의 가입이나 결제를 권유하지 않습니다. 실제 지원 통화, 결제수단, 환불 가능 범위와 계약 요금은 계정·국가·gateway 설정에 적용되는 최신 공식 문서를 다시 확인해야 합니다.

먼저 세 가지 통화를 분리합니다

다중 통화 설계에서 가장 먼저 정할 것은 provider 이름이 아니라 각 단계의 의미입니다. 같은 주문에 다음 세 값이 있을 수 있습니다.

예를 들어 고객에게 EUR 가격을 보여주고 EUR로 결제하더라도, 사업자 정산은 USD일 수 있습니다. 반대로 USD 기준 가격을 고객 국가에 맞춰 현지 통화로 표시하되 실제 invoice는 기준 통화로 남는 구성도 있습니다. 이 차이를 “환율이 적용됐다”라는 한 문장으로 닫지 말고, 가격 결정·승인·정산의 사건을 각각 기록하십시오.

provider별 접근 방식은 네 가지 질문으로 비교합니다

아래 비교는 기능이 항상 동일하다는 뜻이 아닙니다. 국가, 결제수단, merchant 계정, gateway와 계약 조건에 따라 결과가 달라질 수 있으므로 기능명보다 어떤 값을 직접 관리하고 어떤 값을 provider가 계산하는지를 확인하는 표로 사용하십시오.

Stripe의 통화 지원 문서와 가격 현지화 문서는 지원 통화와 localized price 흐름을 확인하는 출발점입니다. Paddle은 localized pricing과 pricing preview API에서 국가·위치에 따른 미리보기와 가격 선택을 확인할 수 있습니다. Chargebee는 multi-currency 안내와 currency 객체, differential price 객체를 함께 봐야 합니다. Recurly는 gateway별 통화 지원과 고급 통화 설정을 구분해서 확인하십시오.

자동 환율과 통화별 고정 가격 중 무엇을 선택할까

다중 통화 가격은 크게 자동 변환과 통화별 고정 가격으로 나뉩니다. 어느 쪽이 더 좋은지는 고객에게 가격 예측 가능성을 줄지, 운영자가 가격표를 직접 통제할지에 따라 달라집니다.

자동 변환을 쓰면서도 최종 고객에게 보인 금액을 다시 계산하지 마십시오. 주문 당시의 가격 ID, 통화, 금액, 환율 관련 provider 응답과 가격표 버전을 보존해야 환불 문의와 매출 보고서에서 동일한 화면을 재현할 수 있습니다. 고정 가격을 쓰더라도 “고정”은 정산 통화까지 고정한다는 뜻이 아니므로 presentment와 settlement를 분리해 기록해야 합니다.

환율 정책은 ‘언제, 누가, 어떤 금액에’ 적용했는지 기록합니다

환율을 비교할 때 운영자가 확인할 질문은 단순히 “오늘 환율인가?”가 아닙니다.

1. 환율은 가격표를 만들 때, checkout을 생성할 때, 승인할 때, invoice를 확정할 때 중 언제 결정되는가?
2. 환율 변환 전 금액은 base price인가, 할인 후 금액인가?
3. 결제수단 수수료·provider 수수료가 환율에 포함되는가, 별도 line item인가?
4. 고객에게 표시한 금액과 실제 승인 요청 금액이 다를 때 어느 값을 영수증과 invoice에 남기는가?
5. 환불이나 credit note가 원 결제 통화로 생성되는가, 현재 가격표 통화로 재계산되는가?

이 질문에 답하지 않은 채 내부 매출 테이블에 amount와 currency만 저장하면, 나중에 같은 금액이 gross인지 net인지, 어느 환율을 적용한 것인지 구분할 수 없습니다. 최소한 다음처럼 원문과 계산 결과를 나누십시오.

base_price_amount / base_price_currency
presentment_amount / presentment_currency
charged_amount / charged_currency
settlement_gross / settlement_currency
provider_fee / fee_currency
fx_rate_reference / fx_rate_timestamp / rounding_mode

환율 참조값이나 timestamp를 provider가 제공하지 않는다면 임의로 만들어 정산 환율처럼 표시하지 마십시오. “provider 화면에서 확인한 값”, “내부 보고용 환산값”, “은행 정산 명세서 값”을 서로 다른 source type으로 구분하는 편이 안전합니다.

반올림과 minor unit을 별도 테스트합니다

현지 통화를 지원한다는 말만으로 모든 통화의 소수점 처리가 같은 것은 아닙니다. JPY처럼 일반적인 소수 단위가 없는 통화, 소수점 정밀도가 다른 통화, provider API가 major unit과 minor unit 중 하나를 요구하는 경우가 있습니다. 가격표·invoice·refund·reporting 각각의 단위를 확인하십시오.

다음 테스트 케이스를 실제 sandbox 또는 provider가 제공하는 preview 기능으로 확인합니다.

• 기준 가격을 환산했을 때 0.5 단위가 발생하는 금액
• 할인율 적용 전후에 반올림하는 경우
• 여러 seat 또는 usage line을 합산한 뒤 반올림하는 경우
• 세금·수수료 line을 별도로 반올림하는 경우
• 부분 환불과 전액 환불의 잔액이 원 invoice와 맞는 경우
• zero-decimal 통화와 소수점 통화를 같은 코드 경로로 처리하는 경우

예를 들어 내부에서 모든 금액을 부동소수점으로 계산한 뒤 마지막에만 반올림하는 방식은 provider의 line item별 반올림과 다를 수 있습니다. 가격 계산 코드에는 currency, minor unit 규칙, rounding mode, 적용 시점을 함께 전달하고, 테스트 결과에는 원문 provider 응답을 연결하십시오.

환불·크레딧은 새 가격으로 다시 계산하지 않습니다

환불 정책은 가격표 정책과 별개입니다. 가격표를 바꿨다고 해서 과거 결제의 환불 금액을 현재 현지 가격으로 다시 계산하면 안 됩니다. 실제 환불 가능 금액과 통화는 원 결제, provider 상태, 계약·정책에 따라 확인해야 합니다.

운영 데이터에는 다음 연결을 남기십시오.

결제 event와 환불 event가 서로 다른 통화로 표시되는 경우에는 provider API의 원문을 우선 보존하고, 내부 보고서의 기준 통화 환산값은 별도 열로 둡니다. Chargebee unbilled charges 대사 체크리스트에서 다루는 invoice·charge 연결과 invoice adjustment evidence schema도 이 단계의 후속 검증에 참고할 수 있지만, 이 글의 중심은 일반 대사가 아니라 통화 정책입니다.

도입 전 선택 기준

다음과 같은 경우에는 자동 변환 또는 간단한 현지화부터 시작할 수 있습니다.

• 시장별 가격 차이를 아직 실험하지 않고, 기준 가격을 빠르게 여러 국가에 표시해야 하는 경우
• 가격표와 invoice에 어떤 통화가 노출되는지만 명확하면 되고, 정산은 단일 통화로 관리하는 경우
• provider의 pricing preview와 sandbox 결과를 주문 전후에 재현할 수 있는 경우

반대로 다음 조건이면 통화별 고정 가격과 별도 승인 흐름을 검토할 필요가 있습니다.

• 국가별 가격 전략이나 연간 계약 가격이 서로 다른 경우
• 환율 변동보다 고객에게 약속한 반복 청구 금액의 예측 가능성이 중요한 경우
• refund·credit·proration을 여러 통화로 처리하고 finance 보고서와 연결해야 하는 경우
• 사업자·site·merchant 계정별 settlement 통화가 달라지는 경우

이 선택은 결제 화면 구현과도 연결되지만 같은 문제는 아닙니다. 결제 라우팅 A/B 테스트 체크리스트처럼 processor 선택과 승인율을 최적화하는 글의 기준을 그대로 가져오면, 통화 정책과 gateway routing을 혼동하게 됩니다.

WordPress 글로 공개하기 전 운영 체크리스트

• [ ] presentment, charge/integration, settlement 통화를 데이터 모델에서 분리했습니다.
• [ ] 자동 FX와 통화별 고정 가격의 환율 기준 시각·가격 버전·반올림 규칙을 기록합니다.
• [ ] provider별 지원 통화와 gateway·결제수단 조건을 공식 문서에서 재확인했습니다.
• [ ] 국가 판정과 price override의 결과를 고객에게 보인 가격과 함께 저장합니다.
• [ ] zero-decimal·minor unit·line item별 반올림 테스트를 완료했습니다.
• [ ] 환불·credit을 현재 가격표로 재계산하지 않고 원 결제와 연결합니다.
• [ ] gross·fee·net·payout과 settlement currency를 별도 필드로 보존합니다.
• [ ] price ID, invoice ID, payment ID, refund ID, payout ID를 서로 연결할 수 있습니다.
• [ ] 결제수단 변경·인보이스 조회는 billing portal 글, 신규 checkout 구현은 checkout 비교 글과 범위를 나눴습니다.
• [ ] 실제 가격과 지원 범위는 Stripe 가격 페이지, Paddle 가격 페이지, Chargebee 가격 페이지, Recurly 가격 페이지에서 계정 조건과 함께 재확인합니다.

마무리

다중 통화의 핵심은 통화를 많이 추가하는 것이 아니라, 고객에게 보인 가격과 실제 청구·정산된 금액의 관계를 나중에도 설명할 수 있게 만드는 것입니다. 자동 FX는 도입 속도와 가격표 관리 편의성이 있지만 환율·반올림·재현성 확인이 필요하고, 통화별 고정 가격은 예측 가능성이 높지만 price와 승인·환불·변경 이력이 늘어납니다.

Stripe·Paddle·Chargebee·Recurly를 비교할 때는 “어느 provider가 가장 싸다”처럼 단정하기보다, 현재 국가·결제수단·merchant 구조에서 presentment → charge/integration → settlement가 어떻게 이어지는지 sandbox와 공식 문서로 검증하십시오. 숫자 가격, 환율, 수수료와 정산 일정은 변경될 수 있으므로 이 글의 표는 도입 결정을 대신하지 않고 확인 순서를 정하는 기준으로 사용해야 합니다.

공식 출처

• Stripe currencies
• Stripe localize prices
• Stripe pricing
• Paddle localized pricing
• Paddle pricing preview API
• Paddle pricing
• Chargebee multi-currency
• Chargebee currency object
• Chargebee differential price object
• Chargebee pricing
• Recurly currency support by gateway
• Recurly advanced currency
• Recurly pricing

최종 확인일: 2026-08-09. 지원 통화, 가격 현지화, 환율·환불·정산 필드는 provider 문서와 계정 설정에 따라 변경될 수 있으므로 실제 도입 전에 최신 공식 문서를 다시 확인하세요.