Multi Payment Providers

들어가며

저희는 통합 결제 중계사를 A사만 사용했었는데, 이번에 추가로 B사와 함께 복합적으로 사용하게 되었습니다.
개발자라면 누구나 예상하시겠지만, 저희 결제 로직은 A사에 특화되어 작성되어 있었고, B사에 맞게 변경하는 작업이 필요했습니다.
Multi Payment Providers를 구현하면서 얻은 설계 경험을 공유하고자 합니다.

결제 흐름

고객 —> e-commerce(노머스) —> 통합 결제 중계사(A사, B사) —> PG사(결제대행사) —> 카드사/은행

기존에 통합 결제 중계사 A사만 사용했을 때에, 결제 방식이 추가될 때마다 PG사가 추가되는 형태였습니다.

그런데 추가로 통합 결제 중계사 B사를 같이 사용하게 되면서, 저희 결제 로직에서는 A사와 B사를 구분하는 일종의 router 역할이 필요하게 되었습니다.

구현

결제에서는 단건 결제, 정기 결제(빌링키), 결제 취소(환불), 웹훅 구현이 주요 interface 같습니다.

단건 결제 (인증 결제)

단건 결제에서 통합 결제 중계사에 따라 결제 🔔승인🔔 확정 위치가 다릅니다.

정기 결제 (빌링키)

정기 결제도 통합 결제 중계사에 따라, 빌링키 🔔승인🔔 확정 위치가 다릅니다.

결제 취소(환불)

결제 취소 flow는 통합 결제 중계사의 차이가 없습니다.

웹훅 (Webhook)

웹훅 등록 방식은 각 통합 결제 중계사마다 스타일이 다릅니다.

스타일1

• 결제 요청시 webhook URL을 같이 전달합니다.
• webhook response 안에 Billing Key 정보가 선택적으로 포함되어 있습니다.

스타일2

• 다음의 webhook URL을 별도로 등록합니다.
  • 단건 결제
  • 환불
  • 정기 결제

스타일3

• 상점(mid)별로 webhook URL을 등록합니다.
• 각 상점에서 발생할 수 있는 이벤트를 선택적으로 구독합니다.

아키텍처 설계

환경변수는 통합 결제 중계사별로 다른 구조를 가집니다:

• A사: 하나의 통합 환경변수
• B사: mid(상점 ID)별로 각각의 환경변수

PG 라우터 구현

API interface에서 <pg>.<mid> 형태로 요청을 받고, 이 값으로 어떤 통합 결제 중계사인지 구분합니다.

routePaymentProvider({ pg, mid, currency }: { pg: string; mid: string; currency: string }): PaymentProvider {
    switch (pg) {
        case 'PayLetter':
            return currency === 'KRW' ? PaymentProvider.A : PaymentProvider.A;

        case 'TossPayments':
            return this.hasTossPaymentsMid(mid) ? PaymentProvider.B : PaymentProvider.A;

        case 'Naver':
            return PaymentProvider.B;

        case 'PaymentWall':
        case 'Kakao':
        case 'Paypal':
            return PaymentProvider.A;

        default:
            throw new Error(`Unsupported payment provider: ${pg}`);
    }
}

PG 라우터는 pg, mid, currency 정보를 받아서 어떤 통합 결제 중계사를 사용할지 결정합니다.

다음과 같은 layered architecture로 설계했습니다.

에러 처리

저는 통합 결제 중계사마다 Custom Error를 정의하였습니다.

export class PaymentProviderAError extends Error {
  constructor(
          message: string,
          public readonly status?: number,
          public readonly code?: string,
          public readonly contextMethod?: string,
          public readonly errorDetails?: string
  ) {
    super(message);
    this.name = 'PaymentProviderAError';
  }
}

export class PaymentProviderBError extends Error {
  ...
}

각 통합 결제 중계사의 응답 포멧은 각기 다르고, 에러 코드 또한 다릅니다.
통합 결제 중계사와의 HTTP 통신에서 에러로 표현되는 여러가지 중에
고객의 상태가 정상적이지 않아 결제가 실패한 경우는, 고객에게 에러 메시지를 그대로 전달하고,
저희 시스템에서 인지해야할 에러는 내부 알람 시스템으로 전송하기 위해 Custom Error를 정의하였습니다.

마치며

통합 결제 중계사를 1개만 사용할 당시에, 0원 결제 상품이 등장하였는데, 0원이기 때문에, 통합 결제 중계사를 호출할 필요가 없었고, 저희 내부적으로만 처리하면 되었습니다.
이를 추가적인 argument로 처리하는 것보다, 가상의 Knowmerce Payment Provider를 만들어 사용했다면 좀 더 깔끔한 구조가 되었을 것 같습니다.

노머스 백엔드 전체 로직은 try catch를 즐겨 사용하지 않고, global exception filter에 주로 의존하는데,
각 PG사의 에러를 해석하여 변환처리해야 하는 부분이 있어, 결제 부분에는 try catch가 사용되는 곳이 있습니다.

감사합니다.