3DS1 및 3DS2 지원 추가

3DS1과 3DS2 모두 Actions Center 예약 엔드 투 엔드 통합에 사용할 수 있습니다. 이 중 하나 또는 둘 다 통합에 구현할 수 있습니다.

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 거래의 경우) 거래 승인에 사용하기 위해 취득자가 판매자에게 할당한 판매자 ID입니다.

이 필드를 판매자 피드에 추가하면 거래에 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 제공업체(제공되는 경우)와 공유할 Actions Center 데이터입니다.

그런 다음 원본 CreateBooking 요청을 PaymentInformation 메시지 내에 있는 pa_response와 함께 다시 보냅니다. pa_response 필드에는 ACS 제공업체에서 Google에 반환하는 페이로드가 포함되며 이 페이로드는 대행업체와의 거래를 승인하는 데 사용해야 합니다.

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

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