국가별 통화 아키텍처를 정하기 전에 각 PG 사가 멀티 통화에 대해 어느정도의 범위를 지원하는지 알아볼 필요가 있다.

다음은 Paypal payments 가 지원하는 멀티 통화에 대한 범위이다.

여기서 말하는 멀티 통화란, Paypal 상인 계정, 즉 빌링 프레임워크의 테넌트 관리자의 Local Currency 대비 구매자가 다른 통화로 결제하였을 경우, Paypal 이 테넌트 관리자의 계좌로 판매대금을 입금하는 과정에서 Currency rating 이 일어나야 하는데, 국가별로 금융법이 다르기 때문에 지원하는 영역이 제한적일 수 있다.

찾아본 몇몇 PG 사들도 모든 Currency 에 대해 지원하는 것이 아니다. 이러한 기반 사항을 알아두고 몇몇 빌링 프레임워크의 멀티 통화 지원 정책을 살펴보도록 한다.

국가별 통화 정책은 두개의 플랫폼을 벤치마킹 했을 때, 다음과 같은 차이점이 있는 것을 볼 수 있었다.

• killbill: 모든 plan 에 대해 currency 별로 가격 책정을 해놓고, 상품을 판매할 때 해당 currency 풀 내에서 사용자가 선택할 수 있다.
• Zoho: 테넌트 의 기본 currency 가 있고, 테넌트 관리자는 currency 리스트를 작성하고 기본 currency 와의 환율을 책정할 수 있다.

두가지 차이점에 대해 Static currency 와 Flexible currency 라 명명하겠다.

killbill 의 카달로그에서 Static currency 를 차용한 모습은 다음과 같다.

<plans>
     <plan name="standard-monthly">
         <product>Standard</product>
         <initialPhases>
             <phase type="TRIAL">
                 <duration>
                     <unit>DAYS</unit>
                     <number>30</number>
                 </duration>
                 <billingPeriod>NO_BILLING_PERIOD</billingPeriod>
                 <fixedPrice> <!-- empty price implies $0 -->
                 </fixedPrice>
             </phase>
         </initialPhases>
         <finalPhase type="EVERGREEN">
             <duration>
                 <unit>UNLIMITED</unit>
             </duration>
             <billingPeriod>MONTHLY</billingPeriod>
             <recurringPrice>
                 <price>
                      <currency>GBP</currency>
                      <value>75.00</value>
                 </price>
                 <price>
                      <currency>USD</currency>
                      <value>100.00</value>
                  </price>
             </recurringPrice>
         </finalPhase>
     </plan>
     ...
</plans>

위의 경우, EVERGREEN 플랜에 대해 구매자는 GBP 과 USD 두가지 환율만 선택할 수 있고, 다른 선택의 여지는 없다.

위 그림은 Zoho 의 테넌트 메뉴에서 currency 설정 화면이다.

위 상황에서 테넌트의 기본 currency 는 USD 이고, 이 테넌트가 독일에서 거주하는 구매자를 확보하였는데, 이 독일인이 가입당시 자신의 결제 통화를 GBP 로 설정하였다.

이 독일인에게 새 구독을 만들어줄때, 아래와 같은 그림을 볼 수 있다.

이 방식의 경우 제품 플랜은 USD 로만 책정할 수 있다. 이후 구매자의 통화가 GBR 이기 때문에, 미리 설정해놓은 USD 와 GBR 의 환율에 맞추어서 청구금액이 달라지게 된다. 구매 당시의 환율에 맞추어 청구 된 GBR AMOUNT 는 후에 환율이 달라지더라도 구매자와 계약한 금액으로 계속 청구가 되게 된다.(고객이 동의하면 업데이트 할 수 있다.)

두 방식은 장단점이 있다고 생각하는데, 표로 정리하면 다음과 같다.

아래의 시나리오들은 환불이 일어날 수 있는 상황들이다.

• 서브스크립션의 계약 금액을 변동했을경우(downgrade)
• 할인 쿠폰을 즉시 적용했을 경우
• 구매자의 구독기간이 남아있는 상태에서 취소했을 경우
• 구매자의 문의로 타당한 환불 사유가 있을 경우
• 구매자가 더 저렴한 플랜으로 변경했을 경우

위의 상황에서, killbill 은 해당 트랜잭션에 대해 PG 사에 refund API 를 요청하지만, Zoho 에서는 아래와 같은 Credit 가 생성된다.

환불이 일어날 경우 Credit(가상 화폐)를 먼저 구매자에게 지급 한 후, 관리자가 검토 후 Refund 요청을 하였을 때 최종 환불이 되는 구조이다.

이러한 방식과 또 Credit 를 사용하여 환불 혹은 생성 하게 해 줄 수 있는 UI 는 관리측면에서 필요한 것으로 생각된다.

PG 트랜잭션이 모든 상황에 대해 100% 인 것이 아니고, Sass 운영 중 일어날 수 있는 다양한 상황에 가상화폐의 개념은 고객 매니지먼트의 유연성을 가져다 줄 것이다.

또한 PG 트랜잭션 이 UNDEFINED 인 상황에 봉착할 경우 관리자가 문제점을 되집어 가도록 하거나 복잡한 Retry 스케쥴을 수행할 알고리즘을 적용하는 것 보다, UNDEFINED 혹은 FAIL 발생시 적용하려 했던 AMOUNT 의 증감을 사용자에게 가상화폐로 부여하고, 관리자가 이를 체크하는 방식이 더 유연해 보인다.

인보이스 발행에서 killbill 과 zoho 는 모두 동일한 기능을 가지는 가운데, 한가지 차이점이 있다.

• killbill: 구매자의 BCD(결제일) 에 구독건들이 일괄청구하는 기능이 있음.(구매자 일할 청구일 지정)
• zoho: 개별 구독건마다 인보이스가 발송.

포시에스 같이 마켓플레이스의 주 고객층이 개인이 아닌 회사이고 많은 Product 를 구매할 수 있는 여지가 있을 경우 구매자 일할 청구일 지정 기능은 필요해 보인다.