웹 기반 결제 핸들러 API

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

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

사용자 에이전트는 상인이 요청한 URL 기반 결제 방식 식별자를 통해 찾은 결제 방식 매니페스트에서 웹 기반 결제 핸들러 정보를 도출함으로써 즉시 설치(Just-in-time installation)를 수행할 수 있습니다.

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에 대해 로드 및 파싱된 결제 방식 매니페스트로 설정한다.
5. 만약 methodName이 URL 기반 결제 방식 식별자이고, paymentMethodManifest의 "*" 문자열이 허용 origin에 포함된다면, true를 반환한다.
6. 그렇지 않고, URL 기반 결제 방식 식별자 methodName의 origin이 paymentHandlerOrigin과 같으면, 웹 기반 결제 핸들러에서 CanMakePaymentEvent를 발생시키고 그 결과를 반환한다.
7. 그 밖에, paymentMethodManifest의 허용 origin이 순서가 있는 origin 집합이고, 그 집합에 paymentHandlerOrigin이 포함되어 있다면, 웹 기반 결제 핸들러에서 CanMakePaymentEvent를 발생시키고 그 결과를 반환한다.
8. 그 외의 경우는 false를 반환한다.

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

WebIDLpartial interface ServiceWorkerGlobalScope {
  attribute EventHandler onpaymentrequest;
};

PaymentRequestDetailsUpdate는 웹 기반 결제 핸들러 내에서 결제 수단, 배송지 주소 또는 배송 옵션을 사용자가 선택함으로써 발생한 수정된 전체 금액(선택적으로 수정자 및 배송 옵션 포함)과 가능한 오류를 포함합니다.

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()를 통해 수신하고, 이어서 사용자가 웹 기반 결제 핸들러를 선택한 경우, 사용자 에이전트는 반드시 다음 절차를 진행해야 합니다:

1. registration을 사용자가 선택한 웹 기반 결제 핸들러에 해당하는 ServiceWorkerRegistration 으로 설정한다.
2. registration이 존재하지 않을 경우, Promise 를 PaymentRequest.show()에서 생성되었던 "InvalidStateError" DOMException로 거부하고 이 과정을 종료한다.

3. 기능성 이벤트 실행(Fire Functional Event) "paymentrequest"를 registration에서 PaymentRequestEvent를 사용하여 다음 속성이 포함되도록 실행한다:

   topOrigin

   최상위 결제(지불) 웹 페이지의 origin의 직렬화 값.

   paymentRequestOrigin

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

   methodData

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

   modifiers

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

   total

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

   paymentRequestId

   PaymentRequest에서 \[\[details\]\].id 값.

   paymentOptions

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

   shippingOptions

   해당 PaymentRequest의 PaymentDetailsInit의 shippingOptions 필드 복사본.

   그런 다음 dispatchedEvent와 함께 다음 단계를 병렬로 수행한다:

   1. dispatchedEvent의 extend lifetime promise의 모든 Promise가 resolve될 때까지 대기한다.
   2. 웹 기반 결제 핸들러가 PaymentHandlerResponse를 제공하지 않았다면, Promise를 PaymentRequest.show()에서 생성되었던 "OperationError" DOMException로 거부한다.

1. event를 이 PaymentRequestEvent로 설정한다.
2. event의 isTrusted 속성이 false라면, "InvalidStateError" DOMException으로 reject된 Promise를 반환한다.
3. request를 이 PaymentRequest를 트리거한 PaymentRequestEvent로 설정한다.
4. url을 url 인자를 파싱한 결과로 설정한다.
5. url 파싱 시 예외가 발생하면, 그 예외로 reject된 Promise를 반환한다.
6. url이 about:blank 이라면, Promise를 TypeError로 reject해서 반환한다.
7. url의 origin이 웹 기반 결제 핸들러와 연결된 service worker의 origin과 동일하지 않다면, null로 resolve된 Promise를 반환한다.
8. promise를 새 Promise로 설정한다.
9. promise를 반환하고, 남은 단계는 병렬로 수행한다:
10. event.[[windowClient]]가 null이 아니라면:
    1. event.[[windowClient]].visibilityState 가 "unloaded"가 아니면, promise를 "InvalidStateError" DOMException으로 reject하고, 이 단계를 중단한다.
11. newContext를 새 최상위 브라우징 컨텍스트로 설정한다.
12. 예외 및 replacement 사용을 활성화한 상태로 Navigate를 newContext와 url에 실행한다.
13. navigation 도중 예외가 던져지면 promise를 그 예외로 reject하고, 이 단계를 중단한다.
14. newContext의 origin이 웹 기반 결제 핸들러와 연관된 service worker client origin과 같지 않다면:
    1. promise를 null로 resolve한다.
    2. 이 단계를 중단한다.
15. client를 newContext를 인자로 하여 create window client 알고리즘을 실행한 결과로 설정한다.
16. event.[[windowClient]]에 client를 할당한다.
17. promise를 client로 resolve한다.

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에서의 정보는 반드시 사용자 동의 하에만 결제 요청자(상점)에게 공유됩니다.
• 사용자 에이전트는 사용자가 해당 결제 핸들러를 직접 선택하기 전까지, 어떠한 결제 요청 정보도 웹 기반 결제 핸들러에 공유하면 안 됩니다.
• Web-based Payment Handler API를 지원하는 브라우저에 서, 상점이 URL 기반 결제 방식 식별자로 PaymentRequest 객체를 생성하면, 등록된 웹 기반 결제 핸들러에서 제한된 origin 집 합(결제 방식 매니페스트의 origin과 그 허 용 origin)에서 CanMakePaymentEvent 가 발생합니다. 이 이벤트는 사용자가 결제 핸들러를 선택하기 전에 발동되지만, 트리거한 origin(즉, 상점 웹사이트)에 관한 정보를 담고 있지 않으므로 사용자를 직접적으로 추적 하는 데 사용할 수 없습니다.
• CanMakePaymentEvent 를 통한 타이밍 공격의 위험성을 인식하고 있습니다:
  • 상점 웹사이트가 백엔드 채널(예: fetch API) 을 통해 웹 기반 결제 핸들러 origin에 곧 PaymentRequest 객체를 만들 것임을 알립니다.
  • 상점 웹사이트가 PaymentRequest를 생성하면 CanMakePaymentEvent 가 설치된 웹 기반 결제 핸들러에 발동됩니다.
  • 해당 결제 핸들러가 자신의 origin과 통신 하며, 서버 측에서 두 요청을 연결 시도할 수 있습니다.
• 사용자 에이전트는 사용자가 CanMakePaymentEvent 지원을 비활성화할 수 있도록 허용해야 합니다.
• Web-based Payment Handler API를 지원하는 브라우저에 서, CanMakePaymentEvent는 가맹점이 요청한 배송지, 결제자 연락처 등 모든 정보를 제공할 수 있는 등록된 웹 기반 결제 핸들러에서 필요 시 발생합니다.

• 이 명세는 웹 기반 결제 핸들러가 처음 등록될 때 사용자 에이전트가 사용자 동의를 어떻게 얻는지는 정의하지 않습니다. 사용자 에이전트는 등록 과정에서 사용자를 알리거나/혹은 프롬프트를 띄울 수 있습니다.
• 사용자 에이전트는 보안상의 이유로 (예: 잘못된 SSL 인증서 등) 웹 기반 결제 핸들러 등록을 거부할 수 있으며(MAY), 이 때 사용자를 알리는 것이 권장됩니다(SHOULD).

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

• 설계상, 한 origin의 웹 기반 결제 핸들러는 다른 origin(예: 상점 사이트)과 데이터를 공유할 수 있습니다.
• 피싱 공격을 방지하기 위해, 사용자 에이전트는 웹 기반 결제 핸들러의 origin을 사용자에게 명확히 전달하는 것이 중요합니다.
• 사용자 에이전트는 사용자가 교차 origin 정보 공유 상황을 이해하도록 돕고, 이상적으로는 어떤 정보가 공유되는지도 알려주어야 합니다.

• Service Worker 보안 고려사항을 참조하십시오
• 결제 방식의 보안은 본 명세의 범위에 포함되지 않으며, 해당 결제 방식을 지원하는 웹 기반 결제 핸들러에서 다룹니다.

• 결제 방식에 대한 책임 기관은 결제 방식 매니페스트를 통해 결제 앱을 승인합니다. 자세한 내용은 CanMakePaymentEvent 처리 알고리즘을 참조하세요.
• 사용자 에이전트는 보안 문제가 있는 웹 기반 결제 핸들러를 반드시 제공할 필요는 없습니다. 보안 문제에는 다음이 포함될 수 있습니다:
  • 만료되었거나, 폐기되었거나, 자기서명된 인증서 등
  • 혼합 콘텐츠
  • HTTPS를 통해 접근된 페이지가 HTTPS가 아닌 곳으로 리디렉션되는 경우
  • 결제 핸들러가 안전 브라우징 데이터베이스에서 악성으로 분류된 경우

  보안상의 이유로 웹 기반 결제 핸들러를 사용할 수 없는 경우, 사용자 에이전트는 웹 기반 결제 핸들러 개발자에게 (예: 콘솔 메시지 등으로) 사유를 제공해야 하며, 사용자가 혼란을 겪지 않도록 사용자에게도 안내할 수 있습니다.

• 결제 방식 매니페스트는 주어진 결제 방식에 대해 origin이 결제 앱을 배포할 수 있도록 승인합니다. 사용자 에이전트가 웹 기반 결제 핸들러가 결제 방식 매니페스트에 나열된 origin과 일치하는지를 판별할 때, 웹 기반 결제 핸들러의 service worker 등록의 scope URL을 사용합니다.

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

• Payment Request API가 "프라이빗 브라우징 모드"에서 호출될 때, 사용자 에이전트는 웹 기반 결제 핸들러를 프라이빗 컨텍스트로 실행해야 합니다. 이렇게 하면 사이트가 이전에 저장된 정보에 접근하는 것을 일반적으로 방지할 수 있습니다. 그 결과 사용자가 origin에 다시 로그인하거나 결제 정보를 재입력해야 할 수 있습니다.
• CanMakePaymentEvent 이벤트는 프라이빗 브라우징 모드에서 발생하지 않아야 합니다. 사용자 에이전트는 respondWith() 이 false로 호출된 것처럼 동작해야 합니다. 그에 따르는 위험도 있습니다: Payment Request API 호출의 origin과 웹 기반 결제 핸들러의 origin 둘 다를 하나의 엔터티가 소유할 경우, 해당 엔터티는 사용자가 프라이빗 브라우징 모드를 사용 중임을 추정할 수 있습니다.