3DS1 및 3DS2 지원 추가

3DS1 및 3DS2 모두 작업 센터 약속 엔드 투 엔드 통합에 사용할 수 있습니다. 통합을 위해 둘 중 하나 또는 둘 다를 구현할 수 있습니다.

3DS1 또는 3DS2는 PSD2의 강력한 고객 인증 요구사항을 충족하지만 몇 가지 주요 차이점이 있습니다.

  • 3DS1: 허위 청구라는 신호가 있는 경우 거래에 3DS1을 트리거하기로 결정할 수 있습니다.
    • 3DS1을 구현하려면 예약 서버를 변경해야 합니다.
  • 3DS2: 3DS2는 PSD2가 적용되는 거래 (거래 은행과 고객의 은행이 EEA에 있는 경우)에만 사용됩니다.
    • 3DS2를 구현하려면 판매자 피드를 변경해야 합니다.

3DS2 구현

3DS2를 구현하려면 TokenizationConfig 메시지 내의 판매자 피드에 필드를 추가해야 합니다. 모든 결제가 동일한 계정으로 전달되는 경우 각 판매자 항목 내에서 값을 반복합니다. 판매 대금이 다른 계좌로 입금되는 경우 각 판매자 항목의 값은 거래 내에서 금액을 받는 계정에 대한 값이어야 합니다.

판매자 피드 변경

  • merchant_of_record_name: 등록된 판매자(MOR)의 이름입니다. 사용자에게 표시되는 이 이름은 3DS2 챌린지에서 표시됩니다.
  • payment_country_code: 거래가 처리되는 국가이며, ISO 3166-1 alpha-2 형식입니다.
  • CardNetworkParameters 메시지: 이 메시지는 서로 다른 네트워크에 적용되는 값으로 반복됩니다 (Visa 및 American Express에만 필요).
    • card_network: 이러한 값이 적용되는 네트워크 (Visa, American Express)
    • acquirer_bin: 카드 처리에 사용된 거래 은행의 은행 식별 번호입니다.
    • acquirer_merchant_id: (Visa 및 American Express 거래의 경우) 거래 승인에 사용하기 위해 획득자가 판매자에게 할당한 판매자 식별자입니다.

이 필드를 판매자 피드에 추가하면 PSD2가 거래에 적용될 때마다 예약 서버에서 수신한 unparsed_payment_method_token 내에서 3DS2 비밀번호를 받게 됩니다. unparsed_payment_method_token 및 삽입된 암호는 사양에 따라 처리 파트너에게 전달해야 합니다.

3DS1 구현

예약 서버 변경

Google에서 CreateBooking 요청을 하고 거래에 3DS1이 필요하다고 판단될 경우 CreateBooking 메서드에서 Booking Failure를 반환하고 PAYMENT_REQUIRES_3DS1을 원인으로 지정합니다. 이 실패 응답에서 PaymentFailureInformation 메시지 내에 ThreeDS1Parameters 메시지도 지정해야 합니다.

  • acs_url = 인증을 위해 사용자에게 표시할 양식을 로드할 URL입니다.
  • pa_req = PaymentAuthentication 요청으로 ACSUrl 양식에 게시됩니다.
  • transaction_id = ACS 제공업체에서 사용하는 식별자로 ACSUrl 양식에 게시됩니다.
  • md_merchant_data = ACS 공급자와 공유할 작업 센터의 데이터입니다(제공되는 경우).

그런 다음 PaymentInformation 메시지 내에 있는 pa_response와 함께 원래의 CreateBooking 요청을 다시 전송합니다. pa_response 필드에는 ACS 제공업체에서 Google에 반환하는 페이로드가 포함되며, 개발자가 대행업체와의 트랜잭션을 승인하는 데 이 필드를 사용해야 합니다.

다음은 3DS1 흐름을 설명하는 다이어그램입니다.

그림 1: 3DS1 프로세스 다이어그램
그림 1: 3DS1 프로세스 다이어그램