결제 핸들러 API

결제 핸들러가 상인이 show() 메서드를 호출할 때 등록되어 있지 않다면, 사용자 에이전트는 거래 중에 사용자가 이 결제 핸들러를 등록하도록 허용할 수 있습니다("즉시").

이 섹션의 나머지 내용은 비규범적입니다.

사용자 에이전트는 상인이 요청한 URL 기반 결제 수단 식별자(URL-based payment method identifier)를 통해 찾은 payment method manifest로부터 결제 핸들러 정보를 유도하여 즉시 설치를 수행할 수 있습니다.

WebIDLpartial interface ServiceWorkerRegistration {
  [SameObject] readonly attribute PaymentManager paymentManager;
};

paymentManager 속성은 결제 핸들러 관리 기능을 노출합니다.

WebIDL[SecureContext, Exposed=(Window)]
interface PaymentManager {
  attribute DOMString userHint;
  Promise<undefined> enableDelegations(sequence<PaymentDelegation> delegations);
};

PaymentManager는 결제 핸들러가 지원하는 delegation을 관리하는 데 사용됩니다.

WebIDLenum PaymentDelegation {
  "shippingAddress",
  "payerName",
  "payerPhone",
  "payerEmail"
};

"shippingAddress"

결제 핸들러는 필요할 때 배송 주소를 제공합니다.

"payerName"

결제 핸들러는 필요할 때 지불자 이름을 제공합니다.

"payerPhone"

결제 핸들러는 필요할 때 지불자 전화번호를 제공합니다.

"payerEmail"

결제 핸들러는 필요할 때 지불자 이메일을 제공합니다.

WebIDLpartial interface ServiceWorkerGlobalScope {
  attribute EventHandler oncanmakepayment;
};

CanMakePaymentEvent는 결제 핸들러가 결제 요청에 응답할 수 있는지 여부를 나타내는 신호로 사용됩니다.

WebIDL[Exposed=ServiceWorker]
interface CanMakePaymentEvent : ExtendableEvent {
  constructor(DOMString type);
  undefined respondWith(Promise<boolean> canMakePaymentResponse);
};

PaymentRequest를 수신하면, 사용자 에이전트는 다음 단계를 MUST 수행합니다:

1. 사용자 에이전트 설정이 CanMakePaymentEvent 사용을 금지하는 경우(예: 사생활 보호 모드), 이 단계를 종료합니다.
2. registration을 ServiceWorkerRegistration으로 둡니다.
3. registration을 찾을 수 없으면, 이 단계를 종료합니다.

4. 기능 이벤트 발생 "canmakepayment"를 CanMakePaymentEvent를 사용해 registration에서 수행합니다.

PaymentMethodData와 결제 수단 식별자와 일치하는 결제 핸들러가 주어졌을 때, 이 알고리즘은 해당 결제 핸들러를 결제에 사용할 수 있으면 true를 반환합니다:

1. methodName을 결제 수단 식별자 문자열(이것은 PaymentMethodData에 지정됨)로 둡니다.
2. methodData를 PaymentMethodData의 결제 수단별 데이터로 둡니다.
3. paymentHandlerOrigin을 해당 결제 핸들러의 ServiceWorkerRegistration scope URL의 origin으로 둡니다.
4. paymentMethodManifest를 methodName에 대한 수집되고 파싱된 payment method manifest로 둡니다.
5. 만약 methodName이 URL 기반 결제 수단 식별자이고, paymentMethodManifest의 supported origins에 "*" 문자열이 있다면, true를 반환합니다.
6. 그렇지 않고, methodName인 URL 기반 결제 수단 식별자의 origin이 paymentHandlerOrigin과 동일하다면, 결제 핸들러에서 CanMakePaymentEvent를 발생시키고 그 결과를 반환합니다.
7. 그렇지 않고, paymentMethodManifest의 supported origins이 origin의 정렬된 집합이며 그 집합이 paymentHandlerOrigin을 포함한다면, 결제 핸들러에서 CanMakePaymentEvent를 발생시키고 결과를 반환합니다.
8. 그 외의 경우, false를 반환합니다.

이 명세는 ServiceWorkerGlobalScope 인터페이스를 확장합니다.

WebIDLpartial interface ServiceWorkerGlobalScope {
  attribute EventHandler onpaymentrequest;
};

PaymentRequestDetailsUpdate는 갱신된 총액(선택적으로 modifier와 배송 옵션 포함)과 결제 핸들러 내에서 사용자가 결제 수단, 배송 주소 또는 배송 옵션을 선택한 결과로 발생할 수 있는 에러를 포함합니다.

WebIDLdictionary PaymentRequestDetailsUpdate {
  DOMString error;
  PaymentCurrencyAmount total;
  sequence<PaymentDetailsModifier> modifiers;
  sequence<PaymentShippingOption> shippingOptions;
  object paymentMethodErrors;
  AddressErrors shippingAddressErrors;
};

PaymentRequestEvent는 사용자가 선택한 이후 결제 핸들러에서 사용할 수 있는 데이터와 메서드를 나타냅니다. 사용자 에이전트는 PaymentRequest에서 사용 가능한 데이터의 하위 집합을 결제 핸들러에 전달합니다.

WebIDL[Exposed=ServiceWorker]
interface PaymentRequestEvent : ExtendableEvent {
  constructor(DOMString type, optional PaymentRequestEventInit eventInitDict = {});
  readonly attribute USVString topOrigin;
  readonly attribute USVString paymentRequestOrigin;
  readonly attribute DOMString paymentRequestId;
  readonly attribute FrozenArray<PaymentMethodData> methodData;
  readonly attribute object total;
  readonly attribute FrozenArray<PaymentDetailsModifier> modifiers;
  readonly attribute object? paymentOptions;
  readonly attribute FrozenArray<PaymentShippingOption>? shippingOptions;
  Promise<WindowClient?> openWindow(USVString url);
  Promise<PaymentRequestDetailsUpdate?> changePaymentMethod(DOMString methodName, optional object? methodDetails = null);
  Promise<PaymentRequestDetailsUpdate?> changeShippingAddress(optional AddressInit shippingAddress = {});
  Promise<PaymentRequestDetailsUpdate?> changeShippingOption(DOMString shippingOption);
  undefined respondWith(Promise<PaymentHandlerResponse> handlerResponsePromise);
};

WebIDLdictionary PaymentRequestEventInit : ExtendableEventInit {
  USVString topOrigin;
  USVString paymentRequestOrigin;
  DOMString paymentRequestId;
  sequence<PaymentMethodData> methodData;
  PaymentCurrencyAmount total;
  sequence<PaymentDetailsModifier> modifiers;
  PaymentOptions paymentOptions;
  sequence<PaymentShippingOption> shippingOptions;
};

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

PaymentRequest가 PaymentRequest.show()에 의해 전달되고, 이후 사용자가 결제 핸들러를 선택하면, 사용자 에이전트는 다음 단계를 MUST 수행합니다:

1. registration을 사용자가 선택한 결제 핸들러에 대응하는 ServiceWorkerRegistration으로 둡니다.
2. registration을 찾을 수 없으면, Promise를 "InvalidStateError" DOMException과 함께 거부하고, 이 단계를 종료합니다. 이 Promise는 PaymentRequest.show()에 의해 생성된 것입니다.

3. 다음 속성들과 함께 registration에서 기능 이벤트 발생 "paymentrequest"를 PaymentRequestEvent를 사용해 수행합니다:

   topOrigin

   최상위 수취인 웹 페이지의 origin의 직렬화.

   paymentRequestOrigin

   PaymentRequest가 초기화된 컨텍스트의 origin의 직렬화.

   methodData

   MethodData 채우기 알고리즘을 실행한 결과.

   modifiers

   Modifiers 채우기 알고리즘을 실행한 결과.

   total

   해당 PaymentDetailsInit의 total 필드의 복사본.

   paymentRequestId

   \[\[details\]\].id(해당 PaymentRequest에서).

   paymentOptions

   해당 PaymentRequest의 생성자에 전달된 paymentOptions 딕셔너리의 복사본.

   shippingOptions

   해당 PaymentDetailsInit의 shippingOptions 필드의 복사본(해당 PaymentRequest에서).

   그런 다음, dispatchedEvent에 대해 다음 단계를 병렬로 실행합니다:

   1. dispatchedEvent의 extend lifetime promises에 있는 모든 Promise가 해결될 때까지 기다립니다.
   2. 결제 핸들러가 PaymentHandlerResponse를 제공하지 않았다면, PaymentRequest.show()에 의해 생성된 Promise를 "OperationError" DOMException과 함께 거부합니다.

1. event를 이 PaymentRequestEvent로 둔다.
2. event의 isTrusted 속성이 false이면, "InvalidStateError" DOMException으로 거부된 Promise를 반환한다.
3. request를 이 PaymentRequestEvent를 트리거한 PaymentRequest로 둔다.
4. url을 url 인수를 파싱한 결과로 둔다.
5. URL 파싱이 예외를 던지면, 그 예외로 거부된 Promise를 반환한다.
6. url이 about:blank이면, TypeError로 거부된 Promise를 반환한다.
7. url의 origin이 결제 핸들러와 연결된 service worker의 origin과 같지 않다면, Promise를 null로 이행하여 반환한다.
8. promise를 새로운 Promise로 둔다.
9. promise를 반환하고, 남은 단계를 병렬로 수행한다.
10. event.[[windowClient]]가 null이 아니면:
    1. event.[[windowClient]].visibilityState 가 "unloaded"가 아니면, promise를 "InvalidStateError" DOMException으로 거부하고 이 단계를 중단한다.
11. newContext를 새로운 top-level browsing context로 둔다.
12. Navigate를 예외 허용 및 대체(replacement) 허용으로 설정하여 newContext를 url로 이동시킨다.
13. 내비게이션이 예외를 던지면, 그 예외로 promise를 거부하고 이 단계를 중단한다.
14. newContext의 origin이 결제 핸들러와 연결된 service worker client의 origin과 같지 않으면:
    1. promise를 null로 이행한다.
    2. 이 단계를 중단한다.
15. client를 newContext를 인수로 하여 create window client 알고리즘을 실행한 결과로 둔다.
16. event.[[windowClient]]를 client로 설정한다.
17. promise를 client로 이행한다.

WebIDLdictionary PaymentHandlerResponse {
DOMString methodName;
object details;
DOMString? payerName;
DOMString? payerEmail;
DOMString? payerPhone;
AddressInit shippingAddress;
DOMString? shippingOption;
};

이 알고리즘이 methodName 및 methodDetails 매개변수와 함께 호출되면, 사용자 에이전트는 다음 단계를 MUST 수행합니다:

1. payment method changed 알고리즘을, 주어진 methodName과 methodDetails 매개변수로 구성한 PaymentMethodChangeEvent event와 함께 실행한다.
2. event의 updateWith(detailsPromise)가 실행되지 않았다면, null을 반환한다.
3. event의 updateWith(detailsPromise)가 예외를 던지면, 그 오류를 재던진다.
4. 선택적으로, event의 updateWith(detailsPromise)가 타임아웃되면, "InvalidStateError" DOMException을 던진다.
5. event의 updateWith(detailsPromise)의 detailsPromise로부터 PaymentRequestDetailsUpdate를 구성하여 반환한다.

이 알고리즘이 shippingAddress 또는 shippingOption과 함께 호출되면, 사용자 에이전트는 다음 단계를 MUST 수행합니다:

1. 갱신된 상세(shippingAddress 또는 shippingOption)로 구성한 PaymentRequestUpdateEvent event와 함께 PaymentRequest updated 알고리즘을 실행한다.
2. event의 updateWith(detailsPromise)가 실행되지 않았다면, null을 반환한다.
3. event의 updateWith(detailsPromise)가 예외를 던지면, 그 오류를 재던진다.
4. 선택적으로, event의 updateWith(detailsPromise)가 타임아웃되면, "InvalidStateError" DOMException을 던진다.
5. event의 updateWith(detailsPromise)의 detailsPromise로부터 PaymentRequestDetailsUpdate를 구성하여 반환한다.

이 알고리즘이 event 및 handlerResponsePromise 매개변수와 함께 호출되면, 사용자 에이전트는 다음 단계를 MUST 수행합니다:

1. event의 isTrusted가 false이면, "InvalidStateError" DOMException을 던지고 이 단계를 중단한다.
2. event의 dispatch flag가 설정되어 있지 않다면, "InvalidStateError" DOMException을 던지고 이 단계를 중단한다.
3. event.[[respondWithCalled]]가 true이면, "InvalidStateError" DOMException을 던지고 이 단계를 중단한다.
4. event.[[respondWithCalled]]를 true로 설정한다.
5. event의 stop propagation flag와 event의 stop immediate propagation flag를 설정한다.
6. handlerResponsePromise를 event의 extend lifetime promises에 추가한다.
7. event의 pending promises count를 1 증가시킨다.
8. 거부될 때 handlerResponsePromise에 대해:
   1. 결제 앱 실패 알고리즘을 실행하고 이 단계를 종료한다.
9. 이행될 때 handlerResponsePromise에 대해:
   1. handlerResponse를 value를 IDL 값으로 변환하여 얻은 PaymentHandlerResponse로 둔다. 변환이 예외를 던지면, 결제 앱 실패 알고리즘을 실행하고 이 단계를 종료한다.
   2. handlerResponse의 모든 필수 멤버가 존재하며 올바르게 형식화되었는지 검증한다.
      1. handlerResponse의 methodName이 없거나 event의 methodData의 값들 중 하나로 설정되어 있지 않으면, 결제 앱 실패 알고리즘을 실행하고 이 단계를 종료한다.
      2. handlerResponse의 details가 없거나 JSON으로 직렬화 가능하지 않으면, 결제 앱 실패 알고리즘을 실행하고 이 단계를 종료한다.
      3. shippingRequired를 관련 PaymentRequest의 requestShipping 값으로 둔다. shippingRequired이고 handlerResponse의 shippingAddress가 없으면, 결제 앱 실패 알고리즘을 실행하고 이 단계를 종료한다.
      4. shippingRequired이고 handlerResponse의 shippingOption이 없거나 event의 shippingOptions의 배송 옵션 식별자들 중 하나로 설정되어 있지 않으면, 결제 앱 실패 알고리즘을 실행하고 이 단계를 종료한다.
      5. payerNameRequired를 관련 PaymentRequest의 requestPayerName 값으로 둔다. payerNameRequired이고 handlerResponse의 payerName이 없으면, 결제 앱 실패 알고리즘을 실행하고 이 단계를 종료한다.
      6. payerEmailRequired를 관련 PaymentRequest의 requestPayerEmail 값으로 둔다. payerEmailRequired이고 handlerResponse의 payerEmail이 없으면, 결제 앱 실패 알고리즘을 실행하고 이 단계를 종료한다.
      7. payerPhoneRequired를 관련 PaymentRequest의 requestPayerPhone 값으로 둔다. payerPhoneRequired이고 handlerResponse의 payerPhone이 없으면, 결제 앱 실패 알고리즘을 실행하고 이 단계를 종료한다.
   3. handlerResponse의 필수 멤버들을 직렬화한다( methodName 및 details는 항상 필수이며, shippingRequired가 true이면 shippingAddress 및 shippingOption이 필수이고, payerNameRequired, payerEmailRequired, payerPhoneRequired가 각각 true이면 payerName, payerEmail, payerPhone이 필수임):
      1. handlerResponse의 각 member에 대해, serializeMember를 StructuredSerialize를 handlerResponse.member에 적용한 결과로 둔다. 예외가 있으면 재던진다.
   4. 사용자 에이전트는 MUST [payment-request]에 정의된 사용자가 결제 요청을 수락하는 알고리즘을 실행하되, 단계 9-15를 다음 단계 또는 그에 상응하는 단계로 대체한다.
      1. 직렬화된 멤버들을 역직렬화한다:
         1. 각 serializeMember에 대해, member를 StructuredDeserialize를 serializeMember에 적용한 결과로 둔다. 예외가 있으면 재던진다.
      2. 위 단계에서 어떤 예외라도 발생하면, 결제 앱 실패 알고리즘을 실행하고 이 단계를 종료한다.
      3. methodName을 관련 PaymentRequest의 response의 methodName에 할당한다.
      4. details를 관련 PaymentRequest의 response의 details에 할당한다.
      5. shippingRequired이면, 관련 PaymentReqeust의 shippingAddress 속성을 shippingAddress로 설정하고, 그렇지 않으면 null로 설정한다.
      6. shippingRequired이면, 관련 PaymentReqeust의 shippingOption 속성을 shippingOption으로 설정하고, 그렇지 않으면 null로 설정한다.
      7. payerNameRequired이면, 관련 PaymentReqeust의 payerName 속성을 payerName으로 설정하고, 그렇지 않으면 null로 설정한다.
      8. payerEmailRequired이면, 관련 PaymentReqeust의 payerEmail 속성을 payerEmail로 설정하고, 그렇지 않으면 null로 설정한다.
      9. payerPhoneRequired이면, 관련 PaymentReqeust의 payerPhone 속성을 payerPhone으로 설정하고, 그렇지 않으면 null로 설정한다.
10. 이행 또는 거부 시, handlerResponsePromise에 대해 다음 단계를 수행하도록 마이크로태스크를 큐에 넣는다:
    1. event의 pending promises count를 1 감소시킨다.
    2. registration을 this의 관련 전역 객체와 연결된 service worker의 containing service worker registration으로 둔다.
    3. registration이 null이 아니면, Try Activate를 registration으로 호출한다.

다음 예시는 결제 요청에 응답하는 방법을 보여줍니다:

paymentRequestEvent.respondWith(new Promise(function(accept,reject) {
  /* ... processing may occur here ... */
  accept({
    methodName: "https://example.com/pay",
    details: {
      cardHolderName:   "John Smith",
      cardNumber:       "1232343451234",
      expiryMonth:      "12",
      expiryYear :      "2020",
      cardSecurityCode: "123"
     },
    shippingAddress: {
      addressLine: [
        "1875 Explorer St #1000",
      ],
      city: "Reston",
      country: "US",
      dependentLocality: "",
      organization: "",
      phone: "+15555555555",
      postalCode: "20190",
      recipient: "John Smith",
      region: "VA",
      sortingCode: ""
    },
    shippingOption: "express",
    payerEmail: "john.smith@gmail.com",
  });
}));

Web Payments 워킹 그룹은 개인정보 보호 이슈로 인해 Payment Request API의 원래 버전에서 배송지와 청구지 주소 지원을 제거했습니다. 자세한 내용은 issue 842를 참조하십시오. 여전히 이 기능을 지원하는 구현을 위한 문서를 제공하기 위해, 워킹 그룹은 개인정보 이슈에 대응할 것을 전제로 이 기능을 복구하고 있습니다. 이 과정에서 워킹 그룹은 다른 API(예: Content Picker API)의 발전을 바탕으로 Payment Request API에 변경을 가할 수도 있습니다.

• 이 API는 사용자가 등록한 결제 핸들러에 관한 정보를 공유하지 않습니다. 출처(origin)의 정보는 사용자의 동의가 있을 때에만 수취인(payee)과 공유됩니다.
• 사용자 에이전트는 사용자가 해당 결제 핸들러를 선택하기 전에는 어떠한 결제 핸들러와도 결제 요청 정보를 공유해서는 안 합니다.
• Payment Handler API를 지원하는 브라우저에서, 상인이 URL 기반 결제 수단 식별자로 PaymentRequest 객체를 생성하면, 등록된 결제 핸들러에서 유한한 출처 집합(결제 방법 매니페스트의 출처 및 그 supported origins)으로부터 CanMakePaymentEvent가 발생합니다. 이 이벤트는 사용자가 해당 결제 핸들러를 선택하기 전에 발생하지만, 트리거한 출처(즉, 상점 웹사이트)에 대한 정보를 포함하지 않으므로 사용자를 직접 추적하는 데 사용할 수 없습니다.
• CanMakePaymentEvent를 통한 타이밍 공격의 위험을 인지합니다:
  • 상점 웹사이트가 백엔드 채널(예: fetch API)을 통해 결제 핸들러 출처에 곧 PaymentRequest 객체를 구성할 것임을 알립니다.
  • 이후 상점 웹사이트가 PaymentRequest를 구성하고, 설치된 결제 핸들러에서 CanMakePaymentEvent를 트리거합니다.
  • 해당 결제 핸들러가 자신의 출처와 통신하고, 서버 측에서 두 요청을 결합하려 시도합니다.
• 사용자 에이전트는 사용자가 CanMakePaymentEvent 지원을 비활성화할 수 있도록 허용해야 합니다.
• Payment Handler API를 지원하는 브라우저에서는, 등록된 결제 핸들러 중에서 상인이 요청한 모든 정보(예: 배송 주소 및 지불자 연락처 정보)를 필요 시 제공할 수 있는 핸들러에 CanMakePaymentEvent가 발생합니다.

• 이 명세는 결제 핸들러가 처음 등록될 때 사용자 에이전트가 사용자 동의를 어떻게 확보하는지 정의하지 않습니다. 사용자 에이전트는 등록 과정에서 사용자에게 알려주거나/또는 프롬프트를 표시할 수 있습니다.
• 사용자 에이전트는 보안상의 이유(예: 유효하지 않은 SSL 인증서 등)로 결제 핸들러 등록을 거부할 MAY 있으며, 이러한 경우 사용자에게 알릴 SHOULD 있습니다.

• 이 명세의 목표 중 하나는 결제를 위해 필요한 사용자 상호작용을 최소화하는 것입니다. 그러나 동시에 사용자가 결제에 동의할 기회를 보장하기를 원합니다. 결제 핸들러는 사용자 상호작용을 위한 창을 열 필요가 없으므로, 사용자 에이전트는 사용자가 (1) 결제 요청이 호출될 때 이를 인지하고, (2) 상점이 해당 결제 핸들러로부터 응답을 받기 전에 결제 핸들러와 상호작용할 수 있는 기회를 갖도록 필요한 조치를 취해야 합니다.

• 설계상, 하나의 출처에서 동작하는 결제 핸들러는 다른 출처(예: 상점 사이트)와 데이터를 공유합니다.
• 피싱 공격을 완화하기 위해, 사용자 에이전트가 사용자에게 결제 핸들러의 출처를 명확히 보여 주는 것이 중요합니다.
• 사용자 에이전트는 사용자가 교차 출처로 정보를 공유하고 있음을 이해하도록 돕고, 이상적으로는 어떤 정보를 공유하는지도 알 수 있도록 해야 합니다.

• Service Worker 보안 고려사항 참조
• 결제 수단의 보안은 이 명세의 범위를 벗어나며, 해당 결제 수단을 지원하는 결제 핸들러에서 다룹니다.

• 결제 수단에 대한 책임 주체는 payment method manifest를 통해 결제 앱을 승인합니다. 자세한 내용은 CanMakePaymentEvent 처리 알고리즘을 참조하십시오.
• 사용자 에이전트는 보안 문제를 야기하는 결제 핸들러를 반드시 제공해야 하는 것은 아닙니다. 보안 문제의 예는 다음과 같습니다:
  • 만료, 폐기, 자체 서명 등의 인증서 이슈
  • 혼합 콘텐츠
  • HTTPs로 제공되는 페이지가 그렇지 않은 페이지로 리디렉션되는 경우
  • 결제 핸들러가 안전한 탐색 데이터베이스에서 악성으로 알려진 경우

  보안상의 이유로 결제 핸들러를 사용할 수 없는 경우, 사용자 에이전트는 결제 핸들러 개발자에게(예: 콘솔 메시지를 통해) 그 근거를 제공해야 하며, 혼란을 피할 수 있도록 사용자에게도 알릴 수 있습니다.

• Payment method manifests는 특정 결제 수단에 대한 결제 앱을 배포할 수 있도록 출처를 승인합니다. 사용자 에이전트가 결제 핸들러가 payment method manifest에 나열된 출처와 일치하는지 판단할 때, 결제 핸들러의 service worker registration의 scope URL을 사용합니다.

• 탈취된 수취인 사이트가 사기성 또는 잘못된 형식의 결제 수단 데이터(혹은 더 나아가 결제 요청 데이터)를 수취인 서버에 전송하는 시나리오를 완화하기 위해, 수취인 서버는 데이터 형식을 검증하고, 서버의 신뢰할 수 있는 정보(예: 허용된 결제 수단, 총액, 표시 항목, 배송 주소 등)와 데이터를 상호 연관해야 합니다.

• "사생활 보호 모드"에서 Payment Request API가 호출되는 경우, 사용자 에이전트는 결제 핸들러를 프라이빗 컨텍스트에서 실행해야 합니다. 이는 일반적으로 사이트가 이전에 저장된 정보에 접근하는 것을 방지합니다. 그 결과, 사용자가 해당 출처에 로그인하거나 결제 정보를 다시 입력해야 할 가능성이 큽니다.
• CanMakePaymentEvent 이벤트는 사생활 보호 모드에서 발생해서는 안 합니다. 사용자 에이전트는 respondWith()가 false로 호출된 것처럼 동작해야 합니다. 한 가지 수반되는 위험을 인지합니다: 동일한 엔티티가 Payment Request API 호출의 출처와 결제 핸들러의 출처를 모두 제어하는 경우, 사용자가 사생활 보호 모드에 있을 가능성을 추론할 수 있습니다.