결제 요청 API

PaymentRequest는 제공된 PaymentMethodData methodData 시퀀스(해당 결제 방식별 data 포함), PaymentDetailsInit details, 그리고 PaymentOptions options를 사용하여 구성됩니다.

PaymentRequest(methodData, details, options) 생성자는 다음과 같이 동작해야 합니다(MUST):

1. this의 관련 전역 객체의 연결된 Document가 사용이 허용되지 않은 경우 "payment" 권한에 대해, "SecurityError" DOMException을 throw합니다.
2. 요청의 id를 설정합니다:
   1. details.id가 없으면 details에 id 멤버를 추가하고 그 값을 UUID [RFC4122]로 설정합니다.
3. serializedMethodData를 빈 목록으로 둡니다.
4. 결제 방식을 처리합니다:
   1. methodData 시퀀스의 길이가 0이면 throw를 통해 TypeError를 발생시키며, 선택적으로 개발자에게 최소 하나의 결제 방식이 필요함을 알립니다.
   2. seenPMIs를 빈 집합으로 둡니다.
   3. methodData의 각 paymentMethod에 대해:
      1. paymentMethod.supportedMethods로 결제 방식 식별자를 검증하는 단계를 실행합니다. 결과가 false이면 RangeError 예외를 던집니다. 선택적으로, 결제 방식 식별자가 유효하지 않음을 개발자에게 알립니다.
      2. pmi를 paymentMethod.supportedMethods를 기본 URL 파서로 파싱한 결과로 둡니다:
         1. 실패라면, pmi를 paymentMethod.supportedMethods로 설정합니다.
      3. seenPMIs가 contains로 pmi를 이미 포함한다면 RangeError DOMException을 던지며, 선택적으로 해당 결제 방식 식별자가 중복임을 개발자에게 알립니다.
      4. Append를 통해 pmi를 seenPMIs에 추가합니다.
      5. paymentMethod의 data 멤버가 없으면 serializedData를 null로 둡니다. 그렇지 않으면 serialize를 사용해 paymentMethod.data를 JSON 문자열로 변환한 결과를 serializedData로 둡니다. 예외가 발생하면 재던집니다.
      6. serializedData가 null이 아니고, paymentMethod.supportedMethods를 정의하는 명세가 추가 데이터 유형을 지정하는 경우:
         1. serializedData를 JSON-파싱한 결과를 object로 둡니다.

         2. converting을 통해 object를 추가 데이터 유형의 IDL 값으로 변환한 결과를 idl로 둡니다. 예외가 발생하면 재던집니다.

         3. 해당 명세에서 정의한 paymentMethod.supportedMethods에 대해 결제 방식 데이터를 검증하는 단계를 object에 대해 실행합니다. 예외가 발생하면 재던집니다.

            참고

            이 단계들은 IDL 타입 변환 및 검증 오류가 가능한 한 이른 시점에 포착되도록 보장합니다.

      7. 튜플 (paymentMethod.supportedMethods, serializedData)를 serializedMethodData에 추가합니다.
5. 총액을 처리합니다:
   1. 총액을 확인하고 정규화합니다: details.total.amount. 예외가 발생하면 재던집니다.
6. details의 displayItems 멤버가 존재하면, details.displayItems의 각 item에 대해:
   1. 금액을 확인하고 정규화합니다: item.amount. 예외가 발생하면 재던집니다.
7. selectedShippingOption을 null로 둡니다.
8. options의 requestShipping 멤버가 존재하고 true로 설정된 경우, 배송 옵션을 처리합니다:
   1. options를 빈 sequence<PaymentShippingOption>로 둡니다.
   2. details의 shippingOptions 멤버가 존재하면:
      1. seenIDs를 빈 집합으로 둡니다.
      2. details.shippingOptions의 각 option에 대해:
         1. 금액을 확인하고 정규화합니다: item.amount. 예외가 발생하면 재던집니다.
         2. seenIDs에 option.id가 포함되어 있으면 TypeError를 던집니다. 선택적으로, 배송 옵션 ID는 고유해야 함을 개발자에게 알립니다.
         3. 그 외의 경우, option.id를 seenIDs에 추가합니다.
         4. option.selected가 true이면, selectedShippingOption을 option.id로 설정합니다.
   3. details.shippingOptions를 options로 설정합니다.
9. serializedModifierData를 빈 목록으로 둡니다.
10. 결제 세부사항 수정자를 처리합니다:
    1. modifiers를 빈 sequence<PaymentDetailsModifier>로 둡니다.
    2. details의 modifiers 멤버가 존재하면:
       1. modifiers를 details.modifiers로 설정합니다.
       2. modifiers의 각 modifier에 대해:
          1. modifier의 total 멤버가 존재하면:
             1. 총액을 확인하고 정규화합니다: modifier.total.amount. 예외가 발생하면 재던집니다.
          2. additionalDisplayItems 멤버가 modifier에 존재하면, modifier.additionalDisplayItems의 각 item에 대해:
             1. 금액을 확인하고 정규화합니다: item.amount. 예외가 발생하면 재던집니다.
          3. modifier의 data 멤버가 없으면 serializedData를 null로 둡니다. 그렇지 않으면 serialize를 통해 modifier.data를 JSON 문자열로 변환한 결과를 serializedData로 둡니다. 예외가 발생하면 재던집니다.
          4. 튜플 (modifier.supportedMethods, serializedData)를 serializedModifierData에 추가합니다.
          5. 존재하는 경우 modifier의 data 멤버를 제거합니다.
    3. details.modifiers를 modifiers로 설정합니다.
11. request를 새로운 PaymentRequest로 둡니다.
12. request의 [[handler]]를 null로 설정합니다.
13. request의 [[options]]를 options로 설정합니다.
14. request의 [[state]]를 "created"로 설정합니다.
15. request의 [[updating]]을 false로 설정합니다.
16. request의 [[details]]를 details로 설정합니다.
17. request의 [[serializedModifierData]]를 serializedModifierData로 설정합니다.
18. request의 [[serializedMethodData]]를 serializedMethodData로 설정합니다.
19. request의 [[response]]를 null로 설정합니다.
20. request의 shippingOption 속성 값을 selectedShippingOption으로 설정합니다.
21. request의 shippingAddress 속성 값을 null로 설정합니다.
22. options.requestShipping이 true로 설정되어 있으면, request의 shippingType 속성 값을 options.shippingType으로 설정합니다. 그렇지 않으면 null로 설정합니다.
23. request를 반환합니다.

가져올 때, id 속성은 이 PaymentRequest의 [[details]].id를 반환합니다.

show(optional detailsPromise) 메서드는 다음과 같이 동작해야 합니다(MUST):

1. request를 this로 둡니다.
2. request의 관련 전역 객체에 일시적 활성화가 없는 경우, 사용자 에이전트는 다음을 수행해도 됩니다(MAY):
   1. 거부된 프라미스를 "SecurityError" DOMException과 함께 반환합니다.
   참고

   이는 예를 들어 리디렉트 후 사용자 활성화가 없을 수 있는 리디렉트 플로우를 지원하기 위해 사용자 에이전트가 사용자 활성화를 요구하지 않도록 허용합니다. 보안 고려사항은 19.9 사용자 활성화 요구사항을 참고하십시오.

   또한 issue #1022에서 사용자 에이전트가 show()에 대해 사용자 활성화를 요구해야 하는지에 대한 보다 구체적인 지침을 명세에 제공하는 방안에 관해 논의하고 있습니다.

3. 그렇지 않으면, 사용자 활성화를 소모합니다(해당 관련 전역 객체의).
4. document를 request의 관련 전역 객체의 연결된 Document로 둡니다.
5. document가 완전히 활성화됨이 아니면, "AbortError" DOMException으로 거부된 프라미스를 반환합니다.
6. document의 가시성 상태가 "visible"이 아니면, "AbortError" DOMException으로 거부된 프라미스를 반환합니다.

7. 선택적으로, 사용자 에이전트가 사용자를 보호하기 위해 show() 호출을 허용하지 않으려는 경우, "SecurityError" DOMException으로 거부된 프라미스를 반환합니다. 예를 들어, 사용자 에이전트는 show()를 페이지가 호출할 수 있는 빈도를 제한할 수 있습니다. 자세한 내용은 19. 개인정보 보호 및 보안 고려사항을 참고하십시오.

8. request의 [[state]]가 "created"가 아니면, "InvalidStateError" DOMException으로 거부된 프라미스를 반환합니다.
9. 사용자 에이전트의 payment request is showing 불리언이 true이면:
   1. request의 [[state]]를 "closed"로 설정합니다.
   2. "AbortError" DOMException으로 거부된 프라미스를 반환합니다.
10. request의 [[state]]를 "interactive"로 설정합니다.
11. acceptPromise를 새 프라미스로 둡니다.
12. request의 [[acceptPromise]]를 acceptPromise로 설정합니다.

13. 선택적으로:

    1. acceptPromise를 "AbortError" DOMException으로 거부합니다.
    2. request의 [[state]]를 "closed"로 설정합니다.
    3. acceptPromise를 반환합니다.
    참고

    이는 사용자 에이전트가 재량에 따라 사용자가 즉시 결제 요청을 중단한 것처럼 동작하도록 허용합니다. 예를 들어, "프라이빗 브라우징" 모드 등에서 사용자 에이전트는 이 단계를 활용할 수 있습니다.

14. request의 결제 관련 브라우징 컨텍스트의 payment request is showing 불리언을 true로 설정합니다.
15. acceptPromise를 반환하고, 나머지 단계를 병렬로 수행합니다.
16. handlers를 빈 리스트로 둡니다.
17. request의 [[serializedMethodData]]의 각 paymentMethod 튜플에 대해:
    1. identifier를 해당 paymentMethod 튜플의 첫 번째 요소로 둡니다.
    2. data를 paymentMethod 튜플의 두 번째 요소를 JSON-파싱한 결과로 둡니다.
    3. identifier를 정의하는 명세가 추가 데이터 유형을 지정한다면, 변환하여 data를 그 타입의 IDL 값으로 둡니다. 그렇지 않으면, 변환하여 data를 object로 둡니다.
    4. 변환이 예외 error를 발생시키면:
       1. request의 [[state]]를 "closed"로 설정합니다.
       2. acceptPromise를 error로 거부합니다.
       3. request의 결제 관련 브라우징 컨텍스트의 payment request is showing 불리언을 false로 설정합니다.
       4. 이 알고리즘을 종료합니다.
    5. registeredHandlers를 리스트로 두고, 결제 방식 identifier에 대해 등록된 결제 핸들러들을 포함시킵니다.
       참고: 결제 핸들러 등록
    6. registeredHandlers의 각 handler에 대해:
       1. handler의 결제를 할 수 있는지 확인하는 단계를 data와 함께 실행한 결과를 canMakePayment로 둡니다.
       2. canMakePayment가 true이면, handler를 handlers에 추가합니다.
18. handlers가 비어 있으면:
    1. request의 [[state]]를 "closed"로 설정합니다.
    2. acceptPromise를 "NotSupportedError" DOMException으로 거부합니다.
    3. request의 결제 관련 브라우징 컨텍스트의 payment request is showing 불리언을 false로 설정합니다.
    4. 이 알고리즘을 종료합니다.

19. 사용자에게 handlers와 상호작용할 수 있는 사용자 인터페이스를 표시합니다. 사용자 에이전트는 결제 방식을 표시할 때 사용자의 선호도를 SHOULD 우선시해야 합니다. 사용자 인터페이스는 가능하다면 document의 문서 요소의 언어와 일치하는 언어 및 로케일 기반 형식으로 표시되어야 하며(SHOULD), 그렇지 않다면 적절한 대체값을 사용해야 합니다.

    참고: 결제 사용자 인터페이스의 현지화
20. detailsPromise가 전달되었다면:
    1. detailsPromise, request, 그리고 null을 사용하여 PaymentRequest의 세부 정보 업데이트 알고리즘을 실행합니다.
    2. detailsPromise가 완료(settle)될 때까지 기다립니다.
       참고

       detailsPromise가 어떻게 완료되는지에 따라 PaymentRequest의 세부 정보 업데이트 알고리즘이 결제 UI 동작 방식을 결정합니다. 즉, detailsPromise가 거부되면 결제 요청은 중단되고, detailsPromise가 이행되면 사용자 에이전트는 결제 요청 UI를 다시 활성화하고 결제 흐름이 계속될 수 있습니다.

21. request의 [[handler]]를 최종 사용자가 선택한 결제 핸들러로 설정합니다.
22. modifiers를 빈 리스트로 둡니다.
23. [[serializedModifierData]]의 각 tuple에 대해:
    1. tuple의 첫 번째 요소(PMI)가 request의 [[handler]]의 결제 방식 식별자와 일치하면, tuple의 두 번째 요소(직렬화된 메서드 데이터)를 modifiers에 추가합니다.

24. paymentMethod 튜플의 두 번째 요소(변환된 값)를 변환하여 전달하고, modifiers도 함께 전달합니다. 선택적으로, 사용자 에이전트는 사용자 선택 결제 핸들러가 사용자를 결제 과정으로 안내할 수 있도록 request에서 적절한 데이터를 보내야 합니다(SHOULD). 여기에는 request의 다양한 속성과 기타 내부 슬롯이 포함됩니다(적절한 경우 개인정보 보호 사유로 일부는 제외될 수 있음).

    [[serializedModifierData]] 내부 슬롯에서 적용 가능한 여러 수정자를 처리하는 방식은 결제 핸들러마다 다르며 본 명세의 범위를 벗어납니다. 그럼에도 불구하고 결제 핸들러는 리스트의 항목에 대해 "마지막 항목 우선(last one wins)" 접근 방식을 사용할 것을 RECOMMENDED합니다: 즉, 리스트 끝의 항목이 리스트 시작의 어떤 항목보다 항상 우선합니다(아래 예시 참조).

    acceptPromise는 이후 사용자 인터페이스와의 상호작용을 통해 트리거되는 사용자가 결제 요청을 수락하는 알고리즘이나 사용자가 결제 요청을 중단하는 알고리즘에 의해 해결되거나 거부됩니다.

    사용자 인터페이스가 표시되는 동안 document가 완전히 활성화됨이 아니게 되거나, 이 단계에 도달할 때까지 그렇게 되었다면:

    1. 사용자 인터페이스를 닫습니다.
    2. request의 결제 관련 브라우징 컨텍스트의 payment request is showing 불리언을 false로 설정합니다.

abort() 메서드는 다음과 같이 동작해야 합니다(MUST):

1. request를 this로 둡니다.
2. request.[[response]]가 null이 아니고, request.[[response]].[[retryPromise]] 가 null이 아니면, "InvalidStateError" DOMException으로 거부된 프라미스를 반환합니다.
3. request.[[state]]의 값이 "interactive"가 아니면, "InvalidStateError" DOMException으로 거부된 프라미스를 반환합니다.
4. promise를 새 프라미스로 둡니다.
5. promise를 반환하고 나머지 단계를 병렬로 수행합니다.
6. 결제 핸들러와의 현재 사용자 상호작용을 중단하고 남아 있는 사용자 인터페이스를 닫으려고 시도합니다.
7. 작업을 큐에 추가하고 사용자 상호작용 작업 소스에서 다음 단계를 수행합니다:
   1. 현재 사용자 상호작용을 중단할 수 없으면, "InvalidStateError" DOMException으로 promise를 거부하고 이 단계를 중단합니다.
   2. request.[[state]]를 "closed"로 설정합니다.
   3. request.[[acceptPromise]]를 "AbortError" DOMException으로 거부합니다.
   4. promise를 undefined로 해결합니다.

canMakePayment() 메서드는 can make payment 알고리즘을 실행해야 합니다(MUST).

PaymentRequest의 shippingAddress 속성은 사용자가 배송 주소를 제공할 때 채워지며, 기본값은 null입니다. 사용자가 배송 주소를 제공할 때 shipping address changed 알고리즘이 실행됩니다.

PaymentRequest의 shippingType 속성은 거래를 이행하기 위해 사용되는 배송 유형입니다. 이 값은 PaymentShippingType 열거형 값이거나, 개발자가 구성 시점에 제공하지 않은 경우 null입니다. (참조: PaymentOptions의 shippingType 멤버).

PaymentRequest의 onshippingaddresschange 속성은 EventHandler로, PaymentRequestUpdateEvent 중 shippingaddresschange와 명명된 이벤트를 처리합니다.

PaymentRequest의 shippingOption 속성은 사용자가 배송 옵션을 선택할 때 채워지며, 기본값은 null입니다. 사용자가 배송 옵션을 선택할 때 shipping option changed 알고리즘이 실행됩니다.

PaymentRequest의 onshippingoptionchange 속성은 EventHandler로, PaymentRequestUpdateEvent 중 shippingoptionchange와 명명된 이벤트를 처리합니다.

PaymentRequest의 onpaymentmethodchange 속성은 EventHandler로, PaymentMethodChangeEvent 중 "paymentmethodchange"와 명명된 이벤트를 처리합니다.

PaymentRequest의 인스턴스는 아래 표에 나열된 내부 슬롯과 함께 생성됩니다:

내부 슬롯	설명 (비규범적)
[[serializedMethodData]]	생성자에 제공된 methodData로, 지원되는 메서드와 문자열 또는 null로 표현된 데이터(원래 객체 형식 대신)로 구성된 튜플로 나타냅니다.
[[serializedModifierData]]	각 data 멤버의 직렬화된 문자열 형식을 포함하는 리스트로, 이는 해당 시퀀스 [[details]].modifier의 각 항목과 일치하거나, 그러한 멤버가 없는 경우 null입니다.
[[details]]	결제 요청의 현재 PaymentDetailsBase로, 생성자에 처음 제공된 후 updateWith() 호출로 업데이트됩니다. 참고로 data 멤버는 PaymentDetailsModifier 인스턴스의 modifiers 멤버에서 제거되며, 대신 직렬화된 형식으로 [[serializedModifierData]] 내부 슬롯에 저장됩니다.
[[options]]	생성자에 제공된 PaymentOptions.
[[state]]	결제 요청의 현재 상태로, 아래 상태로 전환됩니다: "created" 결제 요청이 생성되었으며 아직 사용자에게 표시되지 않은 상태. "interactive" 결제 요청이 사용자에게 표시되고 있는 상태. "closed" 결제 요청이 완료된 상태. 상태 전환은 아래 그림에 설명되어 있습니다:
[[updating]]	updateWith() 호출로 결제 요청을 업데이트하기 위한 대기 중인 작업이 있으면 true, 그렇지 않으면 false입니다.
[[acceptPromise]]	show() 호출 시 생성된 대기 중인 Promise로, 사용자가 결제 요청을 수락하면 해결됩니다.
[[response]]	null이거나, 이 PaymentRequest에 의해 인스턴스화된 PaymentResponse입니다.
[[handler]]	이 PaymentRequest와 연관된 결제 핸들러. 초기값은 null입니다.

JavaScript 문자열이 유효한 소수 통화 값인지 여부는 다음 순서로 구성된 코드 포인트로 판단됩니다:

1. 선택적으로, 단일 U+002D (-)로 금액이 음수임을 나타냅니다.
2. U+0030 (0)에서 U+0039 (9) 범위의 코드 포인트 하나 이상.
3. 선택적으로, 단일 U+002E (.) 뒤에 U+0030 (0)에서 U+0039 (9) 범위의 코드 포인트 하나 이상.

^-?[0-9]+(\.[0-9]+)?$

금액 확인 및 정규화를 PaymentCurrencyAmount amount에 대해 실행하려면, 다음 단계를 따르십시오:

1. IsWellFormedCurrencyCode(amount.currency) 결과가 false인 경우 RangeError 예외를 발생시키고, 선택적으로 개발자에게 통화가 유효하지 않음을 알립니다.
2. amount.value가 유효한 소수 통화 값이 아닌 경우, TypeError를 발생시키고, 선택적으로 개발자에게 통화가 유효하지 않음을 알립니다.
3. amount.currency를 ASCII 대문자로 변환한 결과로 설정합니다: amount.currency.

총 금액 확인 및 정규화를 PaymentCurrencyAmount amount에 대해 실행하려면, 다음 단계를 따르십시오:

1. 금액 확인 및 정규화 amount. 모든 예외를 다시 발생시킵니다.
2. amount.value의 첫 번째 코드 포인트가 U+002D (-)인 경우, TypeError를 발생시키고, 선택적으로 개발자에게 총 금액의 값은 음수일 수 없음을 알립니다.

WebIDLdictionary PaymentDetailsBase {
  sequence<PaymentItem> displayItems;
  sequence<PaymentShippingOption> shippingOptions;
  sequence<PaymentDetailsModifier> modifiers;
};

displayItems 멤버

PaymentItem 사전의 시퀀스는 사용자 에이전트가 표시할 수 있는 결제 요청의 항목을 포함합니다.

참고

shippingOptions 멤버

사용자가 선택할 수 있는 다양한 배송 옵션을 포함하는 시퀀스입니다.

시퀀스 내 항목에 selected 멤버가 true로 설정된 경우, 이 배송 옵션이 기본적으로 사용되며 shippingOption은 이 옵션의 id로 설정됩니다. 시퀀스 내에서 여러 항목이 selected로 true로 설정된 경우, 사용자 에이전트가 시퀀스의 마지막 항목을 선택합니다.

shippingOptions 멤버는 PaymentRequest가 PaymentOptions와 requestShipping이 true로 설정된 상태로 생성된 경우에만 사용됩니다.

참고

modifiers 멤버

특정 결제 방법 식별자에 대한 수정자를 포함하는 PaymentDetailsModifier 사전의 시퀀스입니다. 예를 들어, 결제 방법을 기준으로 총 금액을 조정할 수 있습니다.

WebIDLdictionary PaymentDetailsInit : PaymentDetailsBase {
  DOMString id;
  required PaymentItem total;
};

PaymentDetailsBase 사전에서 상속된 멤버 외에도, 다음 멤버가 PaymentDetailsInit 사전의 일부입니다:

id 멤버

이 결제 요청에 대한 자유 형식 식별자입니다.

참고

total 멤버

결제 요청에 대한 0 이상의 총 금액을 포함하는 PaymentItem입니다.

참고

WebIDLdictionary PaymentDetailsUpdate : PaymentDetailsBase {
  DOMString error;
  PaymentItem total;
  AddressErrors shippingAddressErrors;
  PayerErrors payerErrors;
  object paymentMethodErrors;
};

PaymentDetailsUpdate 사전은 updateWith()를 사용하여 결제 요청을 업데이트하는 데 사용됩니다.

PaymentDetailsBase 사전에서 상속된 멤버 외에도, 다음 멤버가 PaymentDetailsUpdate 사전의 일부입니다:

error 멤버

선택한 배송 주소로 상품을 배송할 수 없는 이유 또는 배송 옵션이 제공되지 않는 기타 이유를 설명하는 사람이 읽을 수 있는 문자열입니다. 결제 요청이 updateWith()를 사용하여 업데이트될 때, PaymentDetailsUpdate는 error 멤버에 메시지를 포함할 수 있으며, 이는 PaymentDetailsUpdate에 유효한 shippingOptions가 포함되지 않는 경우 사용자에게 표시됩니다. (결제 요청이 PaymentRequest의 requestShipping 옵션을 true로 설정하여 생성된 경우)

total 멤버

0 이상의 PaymentItem을 포함합니다.

참고

이 명세의 알고리즘은 PaymentDetailsUpdate 사전을 허용하며 total.amount.value가 음수인 경우 예외를 발생시킵니다.

shippingAddressErrors 멤버

잠재적인 이벤트 타겟과 연관된 배송 주소의 유효성 검사 오류를 나타냅니다.

payerErrors 멤버

지불자 세부정보와 관련된 유효성 검사 오류입니다.

paymentMethodErrors 멤버

결제 방법과 관련된 구체적인 오류입니다.

retry(errorFields) 메서드는 다음과 같이 반드시 동작해야 합니다:

1. response를 this로 둔다.
2. request를 response.[[request]]로 둔다.
3. document를 request의 관련 전역 객체의 연결된 Document로 둔다.
4. document가 완전히 활성 상태가 아니면, "AbortError" DOMException으로 거부된 프로미스를 반환한다.
5. response.[[complete]]가 true이면, "InvalidStateError" DOMException으로 거부된 프로미스를 반환한다.
6. response.[[retryPromise]]가 null이 아니면, "InvalidStateError" DOMException으로 거부된 프로미스를 반환한다.
7. request.[[state]]를 "interactive"로 설정한다.
8. retryPromise를 새로운 프로미스로 둔다.
9. response.[[retryPromise]]를 retryPromise로 설정한다.
10. errorFields가 전달되었다면:
    1. 다음 중 하나라도 참이면, 선택적으로 개발자 콘솔에 경고를 표시한다:
       1. request.[[options]].requestPayerName 가 false이고, errorFields.payer.name 이 존재하는 경우.
       2. request.[[options]].requestPayerEmail 이 false이고, errorFields.payer.email 이 존재하는 경우.
       3. request.[[options]].requestPayerPhone 이 false이고, errorFields.payer.phone 이 존재하는 경우.
       4. request.[[options]].requestShipping 이 false이고, errorFields.shippingAddress 가 존재하는 경우.
    2. errorFields.paymentMethod 멤버가 전달되었고, response.methodName를 정의하는 명세에서 이를 요구하는 경우에는, 변환하여 errorFields의 paymentMethod 멤버를 거기서 지정된 타입의 IDL 값으로 만든다. 그렇지 않으면 변환하여 object로 만든다.
    3. request의 결제 관련 브라우징 컨텍스트의 결제 요청 표시 중 불리언을 false로 설정한다.
    4. 변환 결과가 예외 error를 발생시키면:
       1. retryPromise를 error로 거부한다.
       2. 사용자 에이전트의 결제 요청 표시 중 불리언을 false로 설정한다.
       3. 반환한다.
    5. errorFields의 멤버를 사용자 에이전트의 UI에 있는 입력 필드와 매칭시켜, 최종 사용자에게 결제 응답 데이터에 문제가 있음을 알린다. 예를 들어, 사용자 에이전트는 브라우저 UI에서 잘못된 errorFields에 사용자의 주의를 끌고, 각 필드의 값을 사용자가 각 오류를 수정하는 데 도움이 되는 방식으로 표시할 수 있다. 마찬가지로 error 멤버가 전달된 경우, 그 오류를 사용자 에이전트의 UI에 표시한다. 멤버의 값이 빈 문자열인 경우, 사용자 에이전트는 대체할 수 있다 적절한 오류 메시지로 값을 대체해도 된다.
11. 그 밖에, errorFields가 전달되지 않았다면, 최종 사용자에게 결제를 다시 시도하라고 신호를 보낸다. 결제 요청 수락을 다시 시도할 수 있게 하는 모든 UI 요소를 다시 활성화한다.
12. 사용자 인터페이스가 표시되는 동안 또는 이 단계에 도달할 때까지의 사이에 document가 완전히 활성 상태가 아니게 되면, 다음을 수행한다:
    1. 사용자 인터페이스를 닫는다.
    2. request의 결제 관련 브라우징 컨텍스트의 결제 요청 표시 중 불리언을 false로 설정한다.
13. 마지막으로, retryPromise가 결정(settle)되면, response.[[retryPromise]]를 null로 설정한다.
14. retryPromise를 반환한다.
    참고

    retryPromise는 이후 사용자가 결제 요청을 수락하는 알고리즘에 의해 이행되거나, 사용자가 결제 요청을 중단하는 알고리즘 또는 업데이트 중단에 의해 거부된다.

WebIDLdictionary PaymentValidationErrors {
  PayerErrors payer;
  AddressErrors shippingAddress;
  DOMString error;
  object paymentMethod;
};

WebIDLdictionary PayerErrors {
  DOMString email;
  DOMString name;
  DOMString phone;
};

const payer = {
  email: "The domain is invalid.",
  phone: "Unknown country code.",
  name: "Not in database.",
};
await response.retry({ payer });

사용자가 거래를 이행하기 위해 선택한 결제 방법 식별자로서, 해당 결제 방법을 나타냅니다.

가맹점이 거래를 처리하거나 검증하는 데 사용할 수 있도록 사전 또는 object 형태로 결제 방법에 의해 생성됩니다(선택된 결제 방법에 따라 다름).

requestShipping 멤버가 PaymentOptions에서 true로 설정된 상태로 PaymentRequest 생성자에 전달된 경우, shippingAddress는 사용자가 선택한 전체이자 최종 배송 주소가 됩니다.

requestShipping 멤버가 PaymentOptions에서 true로 설정된 상태로 PaymentRequest 생성자에 전달된 경우, shippingOption은 선택된 배송 옵션의 id 속성이 됩니다.

requestPayerName 멤버가 PaymentOptions에서 true로 설정된 상태로 PaymentRequest 생성자에 전달된 경우, payerName은 사용자가 제공한 이름이 됩니다.

requestPayerEmail 멤버가 PaymentOptions에서 true로 설정된 상태로 PaymentRequest 생성자에 전달된 경우, payerEmail은 사용자가 선택한 이메일 주소가 됩니다.

requestPayerPhone 멤버가 PaymentOptions에서 true로 설정된 상태로 PaymentRequest 생성자에 전달된 경우, payerPhone은 사용자가 선택한 전화번호가 됩니다.

이 결제 응답을 생성한 해당 결제 요청의 id입니다.

결제 요청이 수락되어 호출자에게 PaymentResponse가 반환되었지만, 호출자가 complete()를 호출하기 전까지는 결제 요청 사용자 인터페이스는 보류 상태로 남습니다. 이때에는 결제 요청이 수락되어 반환되었으므로 사용자 인터페이스가 취소 명령을 제공해서는 안 됩니다. 그러나 문제가 발생하여 개발자가 complete()를 호출하지 않으면 사용자 인터페이스가 차단됩니다.

이러한 이유로, 구현은 개발자가 complete()를 호출해야 하는 제한 시간을 둘 수 있습니다. 제한 시간이 만료되면 구현은 인자가 없는 상태로 complete()가 호출된 것처럼 동작합니다.

complete() 메서드는 다음과 같이 반드시 동작해야 합니다:

1. response를 this로 둔다.
2. response.[[complete]]가 true이면, "InvalidStateError" DOMException으로 거부된 프로미스를 반환한다.
3. response.[[retryPromise]]가 null이 아니면, "InvalidStateError" DOMException으로 거부된 프로미스를 반환한다.
4. promise를 새로운 프로미스로 둔다.
5. serializedData를 직렬화의 결과로서 details.data를 JSON 문자열로 변환한 값으로 둔다.
6. 예외를 던지는 일이 직렬화 중 발생하면, 그 예외로 거부된 프로미스를 반환한다.
7. response.methodName을 정의하는 명세에서 요구하는 경우:
   1. json을 JSON의 parse()를 serializedData로 호출한 결과로 둔다.
   2. idl을 변환을 통해 json을 해당 명세에서 지정한 타입의 IDL 값으로 얻은 결과로 둔다.
   3. IDL 값으로의 변환이 예외를 던지면, 그 예외로 거부된 프로미스를 반환한다.
   4. 또한 그 명세에서 요구하는 경우, idl의 멤버들을 검증한다. 어떤 멤버의 값이 유효하지 않으면 거부된 프로미스를 TypeError로 반환한다.
      참고: 복구 기회
8. response.[[complete]]를 true로 설정한다.
9. promise를 반환하고, 나머지 단계를 병렬로 수행한다.
10. document가 사용자 인터페이스가 표시되는 동안 또는 이 단계에 도달할 때까지의 사이에 완전히 활성 상태가 아니게 되면:
    1. 사용자 인터페이스를 닫는다.
    2. request의 결제 관련 브라우징 컨텍스트의 결제 요청 표시 중 불리언을 false로 설정한다.
11. 그 밖의 경우:
    1. 남아 있는 모든 사용자 인터페이스를 닫는다. 사용자 에이전트는 result와 serializedData 값을 사용하여 사용자 경험에 영향을 줄 수 있다.
    2. request의 결제 관련 브라우징 컨텍스트의 결제 요청 표시 중 불리언을 false로 설정한다.
    3. promise를 undefined로 이행(resolve)한다.

개발자가 "payerdetailchange" 이벤트를 처리할 수 있도록 합니다.

PaymentResponse의 인스턴스는 다음 표의 내부 슬롯과 함께 생성됩니다:

WebIDLdictionary AddressErrors {
  DOMString addressLine;
  DOMString city;
  DOMString country;
  DOMString dependentLocality;
  DOMString organization;
  DOMString phone;
  DOMString postalCode;
  DOMString recipient;
  DOMString region;
  DOMString sortingCode;
};

AddressErrors 사전의 멤버들은 물리적 주소의 특정 부분에 대한 유효성 검사 오류를 나타냅니다. 각 사전 멤버는 이중 기능을 갖습니다: 첫째, 멤버가 존재한다는 것은 주소의 특정 부분에 유효성 검사 오류가 있음을 의미합니다. 둘째, 문자열 값은 개발자가 유효성 검사 오류(그리고 최종 사용자가 오류를 어떻게 수정할 수 있는지)를 설명할 수 있게 해줍니다.

addressLine 멤버

주소 행에 유효성 검사 오류가 있음을 나타냅니다. 사용자 에이전트의 UI에서, 이 멤버는 ContactAddress의 addressLine 속성 값을 제공한 입력 필드에 대응됩니다.

city 멤버

도시에 유효성 검사 오류가 있음을 나타냅니다. 사용자 에이전트의 UI에서, 이 멤버는 ContactAddress의 city 속성 값을 제공한 입력 필드에 대응됩니다.

country 멤버

국가에 유효성 검사 오류가 있음을 나타냅니다. 사용자 에이전트의 UI에서, 이 멤버는 ContactAddress의 country 속성 값을 제공한 입력 필드에 대응됩니다.

dependentLocality 멤버

하위 지역에 유효성 검사 오류가 있음을 나타냅니다. 사용자 에이전트의 UI에서, 이 멤버는 ContactAddress의 dependentLocality 속성 값을 제공한 입력 필드에 대응됩니다.

organization 멤버

조직에 유효성 검사 오류가 있음을 나타냅니다. 사용자 에이전트의 UI에서, 이 멤버는 ContactAddress의 organization 속성 값을 제공한 입력 필드에 대응됩니다.

phone 멤버

전화번호에 유효성 검사 오류가 있음을 나타냅니다. 사용자 에이전트의 UI에서, 이 멤버는 ContactAddress의 phone 속성 값을 제공한 입력 필드에 대응됩니다.

postalCode 멤버

우편번호에 유효성 검사 오류가 있음을 나타냅니다. 사용자 에이전트의 UI에서, 이 멤버는 ContactAddress의 postalCode 속성 값을 제공한 입력 필드에 대응됩니다.

recipient 멤버

수취인에 유효성 검사 오류가 있음을 나타냅니다. 사용자 에이전트의 UI에서, 이 멤버는 ContactAddress의 addressLine 속성 값을 제공한 입력 필드에 대응됩니다.

region 멤버

지역에 유효성 검사 오류가 있음을 나타냅니다. 사용자 에이전트의 UI에서, 이 멤버는 ContactAddress의 region 속성 값을 제공한 입력 필드에 대응됩니다.

sortingCode 멤버

정렬 코드에 유효성 검사 오류가 있습니다. 사용자 에이전트의 UI에서, 이 멤버는 ContactAddress의 sortingCode 속성 값을 제공한 입력 필드에 대응됩니다.

WebIDL[SecureContext, Exposed=Window]
interface PaymentMethodChangeEvent : PaymentRequestUpdateEvent {
  constructor(DOMString type, optional PaymentMethodChangeEventInit eventInitDict = {});
  readonly attribute DOMString methodName;
  readonly attribute object? methodDetails;
};

WebIDLdictionary PaymentMethodChangeEventInit : PaymentRequestUpdateEventInit {
  DOMString methodName = "";
  object? methodDetails = null;
};

WebIDL[SecureContext, Exposed=Window]
interface PaymentRequestUpdateEvent : Event {
  constructor(DOMString type, optional PaymentRequestUpdateEventInit eventInitDict = {});
  undefined updateWith(Promise<PaymentDetailsUpdate> detailsPromise);
};

PaymentRequestUpdateEvent는 사용자 상호작용에 응답하여 결제 요청의 세부 정보를 업데이트할 수 있도록 합니다.

WebIDLdictionary PaymentRequestUpdateEventInit : EventInit {};

결제 가능 여부 알고리즘은 사용자 에이전트가 결제 방법을 사용해 결제를 지원하는지 확인합니다. 이 결제 방법들은 PaymentRequest가 구성될 때 지정된 것들입니다.

1. request를, 메서드가 호출된 PaymentRequest 객체로 둔다.
2. request.[[state]]가 "created"가 아니면, "InvalidStateError" DOMException으로 거부된 프로미스를 반환한다.
3. 선택적으로, 최상위 브라우징 컨텍스트의 재량으로 "NotAllowedError" DOMException으로 거부된 프로미스를 반환할 수 있다.
   참고

   이는 사용자 에이전트가 지문 채취 목적의 남용을 감지하고 방지하기 위한 휴리스틱을 적용할 수 있도록 합니다. 예를 들어 다양한 지원되는 PaymentRequest 객체를 생성하고 여러 결제 방법에 대해 결제 가능 여부 알고리즘을 연달아 트리거하는 것과 같은 경우입니다. 예를 들어, 사용자 에이전트는 해당 호출이 이루어진 최상위 브라우징 컨텍스트나 호출이 이루어진 시간대에 따라 허용되는 성공적인 호출의 수를 제한할 수 있습니다.

4. hasHandlerPromise를 새로운 프로미스로 둔다.
5. hasHandlerPromise를 반환하고, 나머지 단계를 병렬로 수행한다.
6. paymentMethod 튜플 각각에 대해 request의 [[serializedMethodData]] 안에서:
   1. paymentMethod 튜플의 첫 번째 요소를 identifier로 둔다.
   2. 사용자 에이전트에 identifier에 대한 결제 요청을 처리할 수 있는 결제 처리기가 있다면, hasHandlerPromise를 true로 이행(resolve)하고 이 알고리즘을 종료한다.
7. hasHandlerPromise를 false로 이행(resolve)한다.

배송 주소 변경 알고리즘은 사용자가 새로운 배송 주소를 제공할 때 실행됩니다. 이 알고리즘은 다음 단계를 반드시 수행합니다:

1. request를, 사용자가 상호작용 중인 PaymentRequest 객체로 둔다.
2. 다음 단계를 실행하기 위해 작업을 큐에 넣고, 사용자 상호작용 작업 소스에서 실행한다:
   1. 참고: 수취인 정보의 프라이버시

      redactList는 API가 가맹점과 공유하는 수취인 개인 정보의 양을 제한합니다.

      가맹점의 경우, 결과로 얻는 ContactAddress 객체는 예를 들어 배송비를 계산하기에 충분한 정보를 제공하지만, 대부분의 경우 수취인을 물리적으로 특정하고 고유하게 식별하기에는 충분하지 않습니다.

      불행히도 redactList가 있더라도 수취인의 익명성이 보장되는 것은 아닙니다. 일부 국가에서는 우편번호가 매우 세분화되어 특정 수취인을 고유하게 식별할 수 있기 때문입니다.

   2. redactList를 빈 리스트로 둔다. redactList를 « "organization", "phone", "recipient", "addressLine" »로 설정한다.
   3. address를, redactList와 함께 사용자가 제공한 입력으로부터 contactaddress를 생성하는 단계를 실행한 결과로 둔다.
   4. request의 shippingAddress를 address로 설정한다.
   5. request와 "shippingaddresschange"를 사용하여 PaymentRequest 업데이트 알고리즘을 실행한다.

배송 옵션 변경 알고리즘은 사용자가 새로운 배송 옵션을 선택할 때 실행됩니다. 이 알고리즘은 다음 단계를 반드시 수행합니다:

1. request를, 사용자가 상호작용 중인 PaymentRequest 객체로 둔다.
2. 다음 단계를 실행하기 위해 작업을 큐에 넣고, 사용자 상호작용 작업 소스에서 실행한다:
   1. request의 shippingOption 속성을, 사용자가 제공한 PaymentShippingOption의 id 문자열로 설정한다.
   2. request와 "shippingoptionchange"를 사용하여 PaymentRequest 업데이트 알고리즘을 실행한다.

사용자가 methodDetails(이는 사전 또는 object 또는 null)과 methodName(사용자가 상호작용 중인 payment method identifier를 나타내는 DOMString)과 함께 결제 방법을 변경할 때, 결제 처리기는 MAY 결제 방법 변경 알고리즘을 실행할 수 있다.

1. request를, 사용자가 상호작용 중인 PaymentRequest 객체로 둔다.
2. 다음 단계를 실행하기 위해 작업을 큐에 넣고, 사용자 상호작용 작업 소스에서 실행한다:
   1. Assert: request.[[updating]]은 false이다. 한 번에 하나의 업데이트만 수행될 수 있다.
   2. Assert: request.[[state]]는 "interactive"이다.
   3. 이벤트를 발생시킨다. 이름은 "paymentmethodchange"이며, PaymentMethodChangeEvent를 사용하여 request에서 발생시킨다. 이때 그 methodName 속성은 methodName으로 초기화하고, methodDetails 속성은 methodDetails로 초기화한다.

PaymentRequest 업데이트 알고리즘은 위의 다른 알고리즘들에 의해 실행되어, 사용자가 PaymentRequest request에 변경을 가했음을 나타내는 이벤트를 발생시키며, 이벤트 이름은 name이다:

1. Assert: request.[[updating]]은 false이다. 한 번에 하나의 업데이트만 수행될 수 있다.
2. Assert: request.[[state]]는 "interactive"이다.
3. event를, 이벤트 생성을 통해 PaymentRequestUpdateEvent 인터페이스를 사용하여 만든 결과로 둔다.
4. event의 type 속성을 name으로 초기화한다.
5. 디스패치 event를 request에서 수행한다.
6. event.[[waitForUpdate]]가 true이면, 또 다른 업데이트 이벤트가 발생할 수 있는 사용자 인터페이스의 모든 부분을 비활성화한다.
7. 그 밖의 경우, event.[[waitForUpdate]]를 true로 설정한다.

사용자 에이전트는 사용자가 사용자 인터페이스에서 payer name 또는 payer email 또는 payer phone을 변경할 때 MUST 지불자 세부정보 변경 알고리즘을 실행해야 한다:

1. request를, 사용자가 상호작용 중인 PaymentRequest 객체로 둔다.
2. request.[[response]]가 null이면, 반환한다.
3. response를 request.[[response]]로 둔다.
4. 다음 단계를 실행하기 위해 작업을 큐에 넣고, 사용자 상호작용 작업 소스에서 실행한다:
   1. Assert: request.[[updating]]은 false이다.
   2. Assert: request.[[state]]는 "interactive"이다.
   3. options를 request.[[options]]로 둔다.
   4. payer name이 변경되었고 options.requestPayerName이 true이면:
      1. response의 payerName 속성을 payer name으로 설정한다.
   5. payer email이 변경되었고 options.requestPayerEmail 이 true이면:
      1. response의 payerEmail을 payer email로 설정한다.
   6. payer phone이 변경되었고 options.requestPayerPhone 이 true이면:
      1. response의 payerPhone을 payer phone으로 설정한다.
   7. event를, 이벤트 생성을 통해 PaymentRequestUpdateEvent를 사용하여 만든 결과로 둔다.
   8. event의 type 속성을 "payerdetailchange"로 초기화한다.
   9. 디스패치 event를 response에서 수행한다.
   10. event.[[waitForUpdate]]가 true이면, 지불자 세부정보에 또 다른 변경을 발생시킬 수 있는 사용자 인터페이스의 모든 부분을 비활성화한다.
   11. 그 밖의 경우, event.[[waitForUpdate]]를 true로 설정한다.

사용자가 결제 요청을 수락하는 알고리즘은 사용자가 결제 요청을 수락하고 결제 의사를 확인할 때 실행된다. 다음 단계를 수행하기 위해 작업을 큐에 넣어야 한다 (작업 소스: 사용자 상호작용 작업 소스):

1. request를 사용자가 상호작용 중인 PaymentRequest 객체로 둔다.
2. request.[[updating]]이 true이면, 이 알고리즘을 종료하고 추가 동작을 하지 않는다. 사용자 에이전트의 사용자 인터페이스는 이러한 상황이 발생하지 않도록 권장된다.
3. request.[[state]]가 "interactive"가 아니면, 이 알고리즘을 종료하고 추가 동작을 하지 않는다. 사용자 에이전트의 사용자 인터페이스는 이러한 상황이 발생하지 않도록 권장된다.
4. request.[[options]]의 requestShipping 값이 true이면, request의 shippingAddress 속성이 null이거나 shippingOption 속성이 null이면, 이 알고리즘을 종료하고 추가 동작을 하지 않는다. 사용자 에이전트는 이러한 상황이 발생하지 않도록 권장된다.
5. isRetry를, request.[[response]]가 null이 아니면 true, 그렇지 않으면 false로 둔다.
6. response를, isRetry가 true이면 request.[[response]]로, 그렇지 않으면 새로운 PaymentResponse로 둔다.
7. isRetry가 false이면, 새로 생성한 response를 초기화한다:
   1. response.[[request]]를 request로 설정한다.
   2. response.[[retryPromise]]를 null로 설정한다.
   3. response.[[complete]]를 false로 설정한다.
   4. response의 requestId 속성 값을, request의 [[details]].id의 값으로 설정한다.
   5. request.[[response]]를 response로 설정한다.
8. handler를 request.[[handler]]로 둔다.
9. response의 methodName 속성 값을, handler의 결제 방법 식별자로 설정한다.
10. response의 details 속성 값을, handler의 결제 요청에 응답하는 단계를 실행한 결과로 얻은 객체로 설정한다.
11. request.[[options]]의 requestShipping 값이 false이면, response의 shippingAddress 속성 값을 null로 설정한다. 그렇지 않으면:
    1. shippingAddress를, 사용자가 제공한 입력으로부터 contactaddress를 생성한 결과로 둔다.
    2. response의 shippingAddress 속성 값을 shippingAddress로 설정한다.
    3. request의 shippingAddress 속성 값을 shippingAddress로 설정한다.
12. request.[[options]]의 requestShipping 값이 true이면, response의 shippingOption 속성을 request의 shippingOption 속성 값으로 설정한다. 그렇지 않으면 null로 설정한다.
13. request.[[options]]의 requestPayerName 값이 true이면, response의 payerName 속성을 사용자가 제공한 지불자 이름으로 설정하고, 제공되지 않았으면 null로 설정한다. 그렇지 않으면 null로 설정한다.
14. request.[[options]]의 requestPayerEmail 값이 true이면, response의 payerEmail 속성을 사용자가 제공한 지불자 이메일 주소로 설정하고, 제공되지 않았으면 null로 설정한다. 그렇지 않으면 null로 설정한다.
15. request.[[options]]의 requestPayerPhone 값이 true이면, response의 payerPhone 속성을 사용자가 제공한 지불자 전화번호로 설정하고, 제공되지 않았으면 null로 설정한다. payerPhone 값을 설정할 때, 사용자 에이전트는 [E.164]를 준수하도록 번호를 권장되는 방식으로 서식화해야 한다.
16. request.[[state]]를 "closed"로 설정한다.
17. isRetry가 true이면, response.[[retryPromise]]를 undefined로 이행(resolve)한다. 그렇지 않으면, request.[[acceptPromise]]를 response로 이행(resolve)한다.

사용자가 결제 요청을 중단하는 알고리즘은 사용자가 현재 상호작용 중인 사용자 인터페이스를 통해 결제 요청을 중단할 때 실행된다. 다음 단계를 수행하기 위해 작업을 큐에 넣어야 한다 (작업 소스: 사용자 상호작용 작업 소스):

1. request를 사용자가 상호작용 중인 PaymentRequest 객체로 둔다.
2. request.[[state]]가 "interactive"가 아니면, 이 알고리즘을 종료하고 추가 동작을 하지 않는다. 사용자 에이전트의 사용자 인터페이스는 이러한 상황이 발생하지 않도록 권장된다.
3. request.[[state]]를 "closed"로 설정한다.
4. request의 결제 관련 브라우징 컨텍스트의 결제 요청 표시 중 불리언을 false로 설정한다.
5. error를 "AbortError" DOMException으로 둔다.
6. response를 request.[[response]]로 둔다.
7. response가 null이 아니면:
   1. response.[[complete]]를 true로 설정한다.
   2. Assert: response.[[retryPromise]]는 null이 아니다.
   3. response.[[retryPromise]]를 error로 거부(reject)한다.
8. 그 밖의 경우, request.[[acceptPromise]]를 error로 거부(reject)한다.
9. 현재 사용자 상호작용을 중단하고, 남아 있는 모든 사용자 인터페이스를 닫는다.

PaymentRequest의 details 업데이트 알고리즘은 PaymentDetailsUpdate detailsPromise와 PaymentRequest request, 그리고 DOMString 또는 null(즉, payment method identifier)인 pmi를 인자로 받는다. 단계들은 detailsPromise의 이행/거부에 따라 조건부로 수행된다. detailsPromise가 끝내 완료되지 않으면 결제 요청은 차단된다. 사용자 에이전트는 사용자가 결제 요청을 중단할 수 있는 수단을 제공하는 것이 SHOULD이며, 구현체는 detailsPromise가 합리적인 시간 내에 완료되지 않을 경우 대기 중 업데이트에 대해 타임아웃을 구현할 수 MAY 있다.

타임아웃이 발생하거나, 사용자가 수동으로 중단하거나, payment handler가 해당 결제를 중단하기로 결정한 경우, 사용자 에이전트는 user aborts the payment request algorithm을 MUST 실행해야 한다.

1. request.[[updating]]을 true로 설정한다.
2. 병렬로, 사용자가 결제 요청을 수락할 수 있는 사용자 인터페이스를 비활성화한다. 이는 사용자 인터페이스가 새로운 세부정보로 업데이트되기 전에는 결제가 수락되지 않도록 보장하기 위함이다.
3. 거부될 때 detailsPromise에 대해:
   1. 업데이트를 중단하고, request와 "AbortError" DOMException을 전달한다.
4. 이행될 때 detailsPromise가 값 value로:
   1. details를 변환을 통해 value를 PaymentDetailsUpdate 사전으로 얻은 결과로 둔다. 이 과정에서 예외가 발생하면, 업데이트를 중단하고 request와 발생한 예외를 전달한다.
   2. serializedModifierData를 빈 리스트로 둔다.
   3. selectedShippingOption을 null로 둔다.
   4. shippingOptions를 빈 sequence<PaymentShippingOption>로 둔다.
   5. details를 검증하고 정규화한다:
      1. details의 total 멤버가 존재하면:
         1. 총액 확인 및 정규화를 수행한다: details.total.amount. 예외가 발생하면 업데이트를 중단하고 request와 해당 예외를 전달한다.
      2. details의 displayItems 멤버가 존재하면, 각 item ∈ details.displayItems에 대하여:
         1. 금액 확인 및 정규화를 수행한다: item.amount. 예외가 발생하면 업데이트를 중단하고 request와 해당 예외를 전달한다.
      3. details의 shippingOptions 멤버가 존재하고, request.[[options]].requestShipping 이 true이면:
         1. seenIDs를 빈 집합으로 둔다.
         2. 각 option ∈ details.shippingOptions에 대하여:
            1. 금액 확인 및 정규화를 수행한다: option.amount. 예외가 발생하면 업데이트를 중단하고 request와 해당 예외를 전달한다.
            2. seenIDs[option.{{PaymentShippingOption/id}]가 존재하면, 업데이트를 중단하고 request와 TypeError를 전달한다.
            3. option.id를 seenIDs에 추가한다.
            4. option을 shippingOptions에 추가한다.
            5. option.selected 가 true이면, selectedShippingOption을 option.id로 설정한다.
      4. details의 modifiers 멤버가 존재하면:
         1. modifiers를 시퀀스 details.modifiers로 둔다.
         2. serializedModifierData를 빈 리스트로 둔다.
         3. 각 PaymentDetailsModifier modifier ∈ modifiers에 대하여:
            1. payment method identifier 검증 단계를 modifier.supportedMethods에 대해 실행한다. false를 반환하면 업데이트를 중단하고 request와 RangeError 예외를 전달한다. 선택적으로, 결제 방법 식별자가 유효하지 않음을 개발자에게 알린다.
            2. modifier의 total 멤버가 존재하면:
               1. 총액 확인 및 정규화를 수행한다: modifier.total.amount. 예외가 발생하면 업데이트를 중단하고 request와 해당 예외를 전달한다.
            3. additionalDisplayItems 멤버가 modifier에 존재하면, 각 PaymentItem item ∈ modifier.additionalDisplayItems에 대하여:
               1. 금액 확인 및 정규화를 수행한다: item.amount. 예외가 발생하면 업데이트를 중단하고 request와 해당 예외를 전달한다.
            4. modifier의 data 멤버가 없으면 serializedData를 null로 둔다. 그렇지 않으면 직렬화를 통해 modifier.data를 JSON 문자열로 변환한 결과를 serializedData로 둔다. 예외가 발생하면 업데이트를 중단하고 request와 해당 예외를 전달한다.
            5. serializedData를 serializedModifierData에 추가한다.
            6. 존재한다면 modifier의 data 멤버를 제거한다.
   6. paymentMethodErrors 멤버가 존재하고 identifier가 null이 아니면:
      1. pmi를 정의하는 명세에서 요구하는 경우, 변환을 통해 paymentMethodErrors를 IDL 값으로 변환한다.
      2. 변환이 exception error를 초래하면, 업데이트를 중단하고 error를 전달한다.
      3. payment handler는 관련 오류 필드 각각에 대해 paymentMethodErrors를 사용하여 오류를 표시하는 것이 SHOULD이다.
   7. 새로운 details를 사용하여 PaymentRequest를 업데이트한다:
      1. details의 total 멤버가 존재하면:
         1. request.[[details]].total을 details.total로 설정한다.
      2. details의 displayItems 멤버가 존재하면:
         1. request.[[details]].displayItems을 details.displayItems로 설정한다.
      3. details의 shippingOptions 멤버가 존재하고, request.[[options]].requestShipping 이 true이면:
         1. request.[[details]].shippingOptions을 shippingOptions로 설정한다.
         2. request의 shippingOption 속성 값을 selectedShippingOption으로 설정한다.
      4. details의 modifiers 멤버가 존재하면:
         1. request.[[details]].modifiers을 details.modifiers로 설정한다.
         2. request.[[serializedModifierData]]를 serializedModifierData로 설정한다.

      5. 만약 request.[[options]].requestShipping 이 true이고, request.[[details]].shippingOptions가 비어 있다면, 이는 개발자가 현재 선택된 배송 주소(즉, request의 shippingAddress로 주어진)에 대해 유효한 배송 옵션이 없음을 나타낸다.

         이 경우, 사용자 에이전트는 이를 나타내는 오류를 표시하는 것이 SHOULD이며, 현재 선택된 배송 주소가 어떤 방식으로든 유효하지 않음을 표시할 수 MAY 있다. 사용자 에이전트는 error 멤버가 details에 존재한다면 이를 사용하여 해당 주소에 유효한 배송 옵션이 없는 이유에 대한 추가 정보를 제공하는 것이 SHOULD이다.

         또한, details["shippingAddressErrors"] 멤버가 존재한다면, 사용자 에이전트는 배송 주소의 오류가 있는 각 필드에 대해 구체적인 오류를 표시하는 것이 SHOULD이다. 이는 AddressErrors의 각 존재하는 멤버를 표시된 사용자 인터페이스 내의 해당 입력 필드에 매칭하여 수행한다.

         마찬가지로, details["payerErrors"] 멤버가 존재하고 request.[[options]]의 requestPayerName, requestPayerEmail, 또는 requestPayerPhone 가 true이면, 오류가 있는 각 필드에 대해 구체적인 오류를 표시한다.

         이와 같이, details.paymentMethodErrors가 존재한다면, 해당 결제 방법의 오류가 있는 각 입력 필드에 대해 구체적인 오류를 표시한다.

5. request.[[updating]]을 false로 설정한다.
6. 변경된 request의 값에 따라 사용자 인터페이스를 업데이트한다. 이 알고리즘을 실행하기 전에 비활성화했던 사용자 인터페이스 요소들을 다시 활성화한다.

결제 방법 소유자는 결제 방법을 위해 수집된 사용자 데이터가 어떻게 사용될지에 대한 개인정보 보호정책을 수립합니다. Payment Request API는 데이터가 거래 완료 및 이 API와 관련된 사용자 경험의 목적에 사용될 것이라는 분명한 기대치를 설정합니다. 결제 수취인은 모든 데이터 사용이 결제 방법 정책을 준수하도록 보장할 책임이 있습니다. 거래 완료를 넘어서는 허용된 사용이 있는 경우, 수취인은 그 사용을 사용자에게 명확히 전달해야 합니다.

사용자 에이전트는 사용자 동의 없이 (예: 배송 주소)와 같은 사용자 정보를 개발자와 공유해서는 안 됩니다.

특히, PaymentMethodData의 data 및 PaymentResponse의 details 멤버는 임의의 데이터 교환을 허용합니다. 기존 결제 방법에서 사용되는 다양한 데이터 모델을 고려할 때, 이 API에서 데이터의 특정 형식을 규정하면 유용성이 제한됩니다. details 멤버는 웹 기반(Payment Handler API에 의해 정의됨) 또는 독점적인 결제 처리기에서 온 데이터를 담습니다. 사용자 에이전트는 적절한 사용자 동의 메커니즘(예: 거래 당사자에 대한 인지와 데이터 공유 의사 표시 메커니즘)을 포함하지 않는 결제 처리기를 지원해서는 안 됩니다.

사용자 에이전트는 displayItems 멤버 또는 additionalDisplayItems 멤버의 값을 거래 완료를 용이하게 하는 목적 외의 어떤 목적으로도 공유해서는 안 됩니다.

PaymentMethodChangeEvent는 수취인이 선택된 결제 방법에 특정한 정보에 기반하여 표시된 총액을 업데이트할 수 있게 합니다. 예를 들어, 선택된 결제 방법과 연관된 청구지 주소는 세금 계산(예: VAT)에 영향을 줄 수 있으며, 지불자가 거래를 완료하기 전에 사용자 인터페이스가 총액을 정확히 표시하는 것이 바람직합니다. 동시에, 결제 완료 이전에는 가능한 한 적은 정보를 공유하는 것이 바람직합니다. 따라서, 결제 방법이 사용자가 결제 방법을 변경할 때의 단계를 정의하는 경우, PaymentMethodChangeEvent의 methodDetails 속성을 통해 공유되는 데이터를 최소화하는 것이 중요합니다. 공유 데이터 최소화에 대한 요구사항과 접근 방식은 결제 방법에 따라 달라질 수 있으며 다음을 포함할 수 있습니다:

• 물리적 주소에 대한 "redactList" 사용. 현재 명세는 address line, organization, phone number, recipient를 shippingAddress에서 마스킹하기 위해 "redactList"를 사용합니다.
• 수취인이 결제 방법 응답 데이터( PaymentResponse.details로 반환)에서 제외/포함할 특정 요소를 식별하는 지시사항 지원. 수취인은 이러한 지시사항을 PaymentMethodData.data를 통해 제공하여, 현재 API를 변경하지 않고도 결제 방법 정의가 발전할 수 있게 할 수 있습니다.

사용자에게 프라이버시 민감 정보의 공유가 명백하지 않을 수 있는 경우(예: 결제 방법 변경 시), 사용자 에이전트가 어떤 정보가 상인과 공유되는지 정확히 사용자에게 알리도록 하는 것이 권고됩니다.

canMakePayment() 메서드는 다양한 결제 방법에 대한 기능 감지를 제공합니다. 향후 다수의 결제 방법이 사용 가능해지는 경우, 이는 지문 채취 벡터가 될 수 있습니다. 사용자 에이전트는 이 메서드의 남용으로부터 사용자를 보호할 것으로 기대됩니다. 예를 들어, 사용자 에이전트는 다음과 같이 사용자 지문 채취를 줄일 수 있습니다:

• 서로 다른 매개변수로 호출되는 빈도를 속도 제한(rate-limiting)합니다.

속도 제한을 위해 사용자 에이전트는 반복 호출을 다음 기준으로 살펴볼 수 있습니다:

• 동일한 등록 가능 도메인.
• 최상위 브라우징 컨텍스트. 또는 사용자 에이전트는 악성 행위자로 알려진 origin에 대해 API 접근을 전면적으로 차단할 수 있습니다.
• iframe 또는 팝업 창의 origin.

이러한 속도 제한 기법은 반복 호출과 연관된 비용을 증가시키는 것을 목표로 합니다. 이는 여러 등록 가능 도메인을 관리하는 비용이거나, 여러 창(탭 또는 팝업)을 여는 사용자 경험상의 마찰일 수 있습니다.

사용자 에이전트가 show() 메서드의 일부로 사용자 활성화를 요구하지 않는 경우, 추가적인 보안 완화를 고려해야 합니다. 사용자 활성화를 요구하지 않으면, 사용자가 페이지와 즉시 상호작용하지 않고도 Payment Request UI를 시작할 수 있게 되어 스팸 및 클릭재킹 공격의 위험이 증가합니다.

스팸을 완화하기 위해, 사용자 에이전트는 특정 임계값 이후 사용자 활성화 요구를 강제할 수 있습니다. 예를 들어, 현재 페이지에서 사용자 활성화 없이 이미 Payment Request UI가 표시된 이후와 같은 경우입니다. 클릭재킹 공격을 완화하기 위해, 사용자 에이전트는 대화 상자가 표시된 직후의 클릭을 무시하는 시간 임계값을 구현할 수 있습니다.

또 다른 관련 완화책은 show()의 6단계에 존재하며, 사용자 상호작용을 시작하려면 문서가 가시 상태여야 합니다.