웹 기반 결제 핸들러 API

이 문서에서는 다음과 같은 흐름을 상정한다:

출처는 사용자에게 지원되는 결제 수단 집합에 대한 결제 요청을 처리할 권한을 요청한다. 예를 들어, 소매점 또는 은행 사이트를 방문한 사용자는 해당 출처의 웹 기반 결제 핸들러를 등록하라는 요청을 받을 수 있다. 출처는 권한의 범위를 설정하지만 출처의 기능은 추가 사용자 동의 없이 발전할 수 있다.
웹 기반 결제 핸들러는 서비스 워커 코드에 정의된다.
가맹점(또는 다른 수취인)이 [payment-request] 메서드 canMakePayment() 또는 show()를 호출할 때 (예: 사용자 -- 즉 지불자 -- 가 결제 페이지에서 버튼을 누를 때), 사용자 에이전트는 후보 웹 기반 결제 핸들러 목록을 계산하며, 가맹점이 허용하는 결제 수단을 사용자 에이전트가 여러 메커니즘을 통해 알고 있는 결제 수단과 비교한다. 여기에는 다음이 포함되며 이에 한정되지 않는다:
- 이 API를 통해 이전에 등록된 것들.
- 거래 과정 중 이 API를 통해 등록될 수 있는 것들, 예를 들어 결제 수단 매니페스트를 통해 식별된 것들.
- 운영 체제 등 다른 메커니즘을 통해 등록된 것들.
사용자 에이전트는 사용자에게 후보 결제 핸들러라는 선택지 집합을 표시한다. 사용자 에이전트는 이러한 선택지를 등록 시 제공되었거나 그 밖에 웹 앱에서 사용할 수 있는 정보(레이블과 아이콘)를 사용하여 표시한다.
지불자 사용자가 웹 기반 결제 핸들러를 선택하면, 사용자 에이전트는 선택된 웹 기반 결제 핸들러의 서비스 워커에서 PaymentRequestEvent를 발생시킨다(cf. 사용자 상호작용 작업 소스). PaymentRequestEvent에는 PaymentRequest에서 온 일부 정보 ([payment-request]에 정의됨)와 추가 정보(예: 수취인의 출처)가 포함된다.
활성화되면 웹 기반 결제 핸들러는 결제 요청을 처리하는 데 필요한 단계를 수행하고, 적절한 결제 응답을 수취인에게 반환한다. 사용자와의 상호작용이 필요하다면, 웹 기반 결제 핸들러는 그 목적을 위해 창을 열 수 있다.
사용자 에이전트는 웹 기반 결제 핸들러가 요청 처리를 완료하면 비동기적으로 응답을 받는다. 이 응답은 [payment-request]의 PaymentResponse가 된다.

참고

하나의 출처는 둘 이상의 서비스 워커로 결제 앱을 구현할 수 있으며 따라서 하나의 출처마다 여러 개의 웹 기반 결제 핸들러가 등록될 수 있다. 호출되는 핸들러는 사용자가 내린 선택에 따라 결정된다.

이 절은 규범적이지 않다.

웹 기반 결제 핸들러는 웹 애플리케이션 기반 결제 핸들러이다. 즉, 사용자를 대신하여 결제 요청을 처리할 수 있는 웹 애플리케이션이다.

웹 기반 결제 핸들러의 로직은 그것이 지원하는 결제 수단에 의해 좌우된다. 일부 결제 수단은 웹 기반 결제 핸들러가 거의 또는 전혀 처리하지 않고 단순히 응답에서 결제 카드 세부 정보를 반환하기를 기대한다. 그러면 수취인 웹사이트가 반환된 데이터를 입력으로 사용하여 결제를 처리하는 것이 그 역할이 된다.

반대로, 암호화폐 결제 또는 은행 발신 신용 이체와 같은 일부 결제 수단은 웹 기반 결제 핸들러가 결제 처리를 개시할 것을 요구한다. 그러한 경우 웹 기반 결제 핸들러는 결제 참조, 엔드포인트 URL 또는 수취인 웹사이트가 결제의 결과를 판별하는 데 사용할 수 있는 기타 데이터를 반환한다 (결제 자체를 처리하는 것과는 반대로).

결제 요청 처리에는 수많은 상호작용이 포함될 수 있다: 사용자와는 새 창이나 다른 API(예: Web Cryptography API)를 통해, 또는 다른 서비스 및 출처와는 웹 요청 또는 다른 수단을 통해.

이 명세는 발생하는 이러한 활동들을 다루지 않는다. 즉 웹 기반 결제 핸들러가 PaymentRequestEvent를 수락한 후와 웹 기반 결제 핸들러가 응답을 반환하기 전 사이에 일어나는 활동들이다. 웹 기반 결제 핸들러를 구성하고 결제 요청을 처리하는 데 필요할 수 있는 이러한 모든 활동은 웹 기반 결제 핸들러의 구현에 맡겨지며, 여기에는 다음이 포함된다:

사용자가 결제 서비스를 제공하는 출처에 계정을 만드는 방법.
출처가 사용자를 인증하는 방법.
수취인 서버와 수취인 웹 애플리케이션 사이, 또는 결제 앱 출처와 다른 당사자들 사이에서 통신이 이루어지는 방법.

따라서 출처는 수명주기 관리, 보안, 사용자 인증, 사용자 상호작용 등을 위해 다른 곳에서 정의된 많은 다른 웹 기술에 의존하게 된다.

이 절은 규범적이지 않다.

이 명세는 제3자 모바일 결제 앱이(독점적 메커니즘을 통해) 사용자 에이전트와 어떻게 상호작용하는지, 또는 사용자 에이전트 자체가 어떻게 단순한 결제 앱 기능을 제공하는지는 다루지 않는다.

다양한 유형의 결제 앱. Web-based Payment Handler API는 웹 앱용이다. — 그림 1 Web-based Payment Handler API는 웹 앱이 결제를 처리할 수 있게 한다. 다른 유형의 결제 앱은 다른(독점적) 메커니즘을 사용할 수 있다.

웹 기반 결제 핸들러가 CanMakePaymentEvent를 지원하면, 사용자 에이전트는 이를 사용하여 사용 가능한 웹 기반 결제 핸들러의 필터링을 도울 수 있다.

구현은 개발자가 CanMakePaymentEvent에 응답할 수 있도록 시간 제한을 둘 수 있다. 시간 제한이 만료되면, 그러면 구현은 respondWith()가 false와 함께 호출된 것처럼 동작한다.

WebIDLpartial interface ServiceWorkerGlobalScope {
  attribute EventHandler oncanmakepayment;
};

oncanmakepayment 속성은 대응하는 이벤트 핸들러이며, 그에 대응하는 이벤트 핸들러 이벤트 유형은 "canmakepayment"이다.

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

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

이 메서드는 웹 기반 결제 핸들러가 결제 요청에 응답할 수 있는지 여부를 나타내는 신호로 사용된다.

PaymentRequest를 수신하면, 사용자 에이전트는 반드시 다음 단계를 실행해야 한다:

사용자 에이전트 설정이 CanMakePaymentEvent의 사용을 금지하면(예: 프라이빗 브라우징 모드에서), 이 단계들을 종료한다.
registration을 ServiceWorkerRegistration이라고 하자.
registration이 발견되지 않으면, 이 단계들을 종료한다.
기능 이벤트 발생 "canmakepayment"를 registration에서 CanMakePaymentEvent를 사용하여 수행한다.

이 절은 규범적이지 않다.

이 예시는 CanMakePaymentEvent를 수신하는 서비스 워커를 작성하는 방법을 보여준다. CanMakePaymentEvent를 수신하면, 서비스 워커는 항상 true를 반환한다.

예 1: CanMakePaymentEvent 처리

self.addEventListener("canmakepayment", function(e) {
  e.respondWith(new Promise(function(resolve, reject) {
    resolve(true);
  }));
});

PaymentMethodData와 결제 수단 식별자에 일치하는 웹 기반 결제 핸들러가 주어지면, 이 알고리즘은 이 웹 기반 결제 핸들러가 결제에 사용될 수 있으면 true를 반환한다:

methodName을 결제 수단 식별자 문자열로 둔다. 이는 PaymentMethodData에 지정된 것이다.
methodData를 PaymentMethodData의 결제 수단별 데이터로 둔다.
paymentHandlerOrigin을 웹 기반 결제 핸들러의 ServiceWorkerRegistration scope URL의 출처로 둔다.
paymentMethodManifest를 methodName에 대한 수집되고 그리고 구문 분석된 결제 수단 매니페스트로 둔다.
methodName이 URL 기반 결제 수단 식별자이고, paymentMethodManifest의 지원되는 출처에 "*" 문자열이 있으면, true를 반환한다.
그렇지 않고, URL 기반 결제 수단 식별자 methodName이 paymentHandlerOrigin과 동일한 출처를 가지면, 웹 기반 결제 핸들러에서 CanMakePaymentEvent를 발생시키고 그 결과를 반환한다.
그렇지 않고, paymentMethodManifest의 지원되는 출처가 paymentHandlerOrigin을 포함하는 출처의 순서 있는 집합이면, 웹 기반 결제 핸들러에서 CanMakePaymentEvent를 발생시키고 그 결과를 반환한다.
그렇지 않으면, false를 반환한다.

사용자가 웹 기반 결제 핸들러를 선택하면, 사용자 에이전트는 PaymentRequestEvent를 발생시키고 이어지는 PaymentHandlerResponse를 사용하여 [payment-request]를 위한 PaymentResponse를 생성한다.

Issue 117: Payment Handler에 위임되는 Abort() 지원

Payment Request API는 중단(abort)을 관리할 책임을 결제 앱에 위임하는 것을 지원한다. Web-based Payment Handler 인터페이스에 paymentRequestAborted 이벤트를 추가하자는 제안이 있다. 이 이벤트는 paymentRequest가 성공적으로 중단되었는지를 나타내는 불리언 매개변수를 받는 respondWith 메서드를 갖게 된다.

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

WebIDLpartial interface ServiceWorkerGlobalScope {
  attribute EventHandler onpaymentrequest;
};

onpaymentrequest 속성은 이벤트 핸들러이며, 그에 대응하는 이벤트 핸들러 이벤트 유형은 PaymentRequestEvent이다.

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

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

사용자가 선택한 웹 기반 결제 수단, 배송 주소 또는 배송 옵션을 사용할 수 없는 이유를 설명하는 사람이 읽을 수 있는 문자열.

변경된 결제 수단, 배송 주소 또는 배송 옵션에 따라 갱신된 총액. 예를 들어, 사용자가 선택한 결제 수단의 청구 주소에 따라 부가가치세(VAT)가 달라지거나, 또는 사용자가 선택/제공한 배송 옵션/주소에 따라 배송 비용이 달라질 수 있으므로 총액이 바뀔 수 있다.

변경된 결제 수단, 배송 주소 또는 배송 옵션에 따라 갱신된 modifier. 예를 들어, 청구 주소나 배송 주소에 따라 전체 총액이 €1.00 증가했다면, 각 modifier에 지정된 총액도 역시 €1.00 증가해야 한다.

변경된 배송 주소에 따라 갱신된 shippingOptions. 예를 들어, 사용자가 제공한 국가에서는 특급 배송이 더 비싸거나 제공되지 않을 수 있다.

결제 수단에 대한 검증 오류가 있다면 그 오류.

배송 주소에 대한 검증 오류가 있다면 그 오류.

PaymentRequestEvent는 사용자가 선택한 후 Payment Handler가 사용할 수 있는 데이터와 메서드를 나타낸다. 사용자 에이전트는 PaymentRequest에서 사용 가능한 데이터의 일부를 Payment Handler에 전달한다.

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);
};

최상위 수취인 웹 페이지의 출처를 나타내는 문자열을 반환한다. 이 속성은 Handling a PaymentRequestEvent에 의해 초기화된다.

PaymentRequest가 초기화된 출처를 나타내는 문자열을 반환한다. PaymentRequest가 topOrigin에서 초기화되면, 두 속성은 같은 값을 가진다. 그렇지 않으면 두 속성은 서로 다른 값을 가진다. 예를 들어, PaymentRequest가 topOrigin과 다른 출처의 iframe 내부에서 초기화되면, 이 속성의 값은 해당 iframe의 출처이다. 이 속성은 Handling a PaymentRequestEvent에 의해 초기화된다.

가져올 때, paymentRequestId 속성은 이 PaymentRequestEvent에 대응하는 PaymentRequest의 [[details]].id를 반환한다.

이 속성은 웹사이트가 허용하는 결제 수단의 결제 수단 식별자와, 관련된 결제 수단별 데이터를 포함하는 PaymentMethodData 사전들을 담고 있다. 이는 아래에 정의된 MethodData Population Algorithm을 사용하여 PaymentRequest로부터 채워진다.

이 속성은 결제를 위해 요청되는 총 금액을 나타낸다. 이는 [payment-request]에 정의된 바와 같은 PaymentCurrencyAmount 사전 타입이며, 대응하는 PaymentRequest 객체가 인스턴스화될 때 제공된 PaymentDetailsInit의 total 필드의 복사본으로 초기화된다.

이 PaymentDetailsModifier 사전들의 시퀀스는 특정 결제 수단 식별자에 대한 modifier를 포함한다(예: 결제 금액 또는 통화 유형이 결제 수단별로 달라지는 경우). 이는 아래에 정의된 Modifiers Population Algorithm을 사용하여 PaymentRequest로부터 채워진다.

PaymentOptions의 PaymentRequest 내 값. shippingAddress 및/또는 지불자 연락처 정보의 일부가 요청된 경우에만 사용할 수 있다.

대응하는 PaymentRequest의 PaymentDetailsInit 사전에 있는 ShippingOptions의 값. (PaymentDetailsInit는 PaymentDetailsBase로부터 ShippingOptions를 상속한다.) 배송 주소가 요청된 경우에만 사용할 수 있다.

이 메서드는 웹 기반 결제 핸들러가 사용자에게 창을 표시하는 데 사용된다. 호출되면 open window algorithm을 실행한다.

이 메서드는 웹 기반 결제 핸들러가 청구 주소와 같은 결제 수단 세부 정보를 바탕으로 갱신된 총액을 얻는 데 사용된다. 호출되면 change payment method algorithm을 실행한다.

이 메서드는 웹 기반 결제 핸들러가 shippingAddress를 바탕으로 갱신된 결제 세부 정보를 얻는 데 사용된다. 호출되면 change payment details algorithm을 실행한다.

이 메서드는 웹 기반 결제 핸들러가 shippingOption 식별자를 바탕으로 갱신된 결제 세부 정보를 얻는 데 사용된다. 호출되면 change payment details algorithm을 실행한다.

이 메서드는 웹 기반 결제 핸들러가 결제가 성공적으로 완료되었을 때 PaymentHandlerResponse를 제공하는 데 사용된다. 호출되면, event와 handlerResponsePromise를 인수로 하여 Respond to PaymentRequest Algorithm을 실행한다.

Issue 123: 사용자 데이터를 결제 앱과 공유할 것인가?

사용자로부터 명시적 동의를 받은 경우 결제 앱이 사용자 에이전트에 저장된 사용자 데이터를 받아야 하는가? 결제 앱은 설치 시점이나 결제 앱이 처음 호출될 때 권한을 요청할 수 있다.

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

topOrigin, paymentRequestOrigin, paymentRequestId, methodData, total, modifiers, paymentOptions, and shippingOptions 멤버는 PaymentRequestEvent에 대해 정의된 것들과 정의를 공유한다

methodData의 값을 초기화하기 위해, 사용자 에이전트는 반드시 다음 단계들 또는 이에 상응하는 절차를 수행해야 한다:

registeredMethods를 호출된 웹 기반 결제 핸들러의 등록된 결제 수단 식별자 집합으로 둔다.
새로운 비어 있는 Sequence를 생성한다.
dataList를 새로 생성된 Sequence로 설정한다.
해당 결제 요청의 PaymentRequest@[[methodData]] 내 각 항목에 대해 다음 단계를 수행한다:
1. inData를 현재 고려 중인 항목으로 설정한다.
2. commonMethods를 inData.supportedMethods 와 registeredMethods의 교집합으로 설정한다.
3. commonMethods가 비어 있으면, 남은 하위 단계를 건너뛰고 다음 항목(있는 경우)으로 이동한다.
4. 새로운 PaymentMethodData 객체를 생성한다.
5. outData를 새로 생성된 PaymentMethodData로 설정한다.
6. outData.supportedMethods를 commonMethods의 구성원을 포함하는 목록으로 설정한다.
7. outData.data를 inData.data의 복사본으로 설정한다.
8. outData를 dataList에 추가한다.
methodData를 dataList로 설정한다.

modifiers의 값을 초기화하기 위해, 사용자 에이전트는 반드시 다음 단계들 또는 이에 상응하는 절차를 수행해야 한다:

registeredMethods를 호출된 웹 기반 결제 핸들러의 등록된 결제 수단 식별자 집합으로 둔다.
새로운 비어 있는 Sequence를 생성한다.
modifierList를 새로 생성된 Sequence로 설정한다.
해당 결제 요청의 PaymentRequest@[[paymentDetails]].modifiers 내 각 항목에 대해 다음 단계를 수행한다:
1. inModifier를 현재 고려 중인 항목으로 설정한다.
2. commonMethods를 inModifier.supportedMethods 와 registeredMethods의 교집합으로 설정한다.
3. commonMethods가 비어 있으면, 남은 하위 단계를 건너뛰고 다음 항목(있는 경우)으로 이동한다.
4. 새로운 PaymentDetailsModifier 객체를 생성한다.
5. outModifier를 새로 생성된 PaymentDetailsModifier로 설정한다.
6. outModifier.supportedMethods를 commonMethods의 구성원을 포함하는 목록으로 설정한다.
7. outModifier.total을 inModifier.total의 복사본으로 설정한다.
8. outModifier를 modifierList에 추가한다.
modifiers를 modifierList로 설정한다.

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

내부 슬롯	기본값	설명 (비규범적)
[[windowClient]]	null	현재 활성화된 WindowClient. 이는 웹 기반 결제 핸들러가 현재 사용자에게 창을 표시하고 있는 경우 설정된다. 그렇지 않으면 null이다.
[[respondWithCalled]]	false	YAHO

PaymentRequest를 PaymentRequest.show()를 통해 수신하고, 이어서 사용자가 웹 기반 결제 핸들러를 선택하면, 사용자 에이전트는 반드시 다음 단계를 실행해야 한다:

registration을 사용자가 선택한 웹 기반 결제 핸들러에 대응하는 ServiceWorkerRegistration으로 둔다.
registration을 찾을 수 없으면, Promise that was created by PaymentRequest.show() with an "InvalidStateError" DOMException으로 거부하고 이 단계들을 종료한다.
기능 이벤트 발생 "paymentrequest"를 registration에서 PaymentRequestEvent를 사용하여, 다음 속성과 함께 수행한다:

topOrigin

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

paymentRequestOrigin

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

methodData

MethodData Population Algorithm을 실행한 결과.

modifiers

Modifiers Population Algorithm을 실행한 결과.

total

대응하는 PaymentRequest의 PaymentDetailsInit에 있는 total 필드의 복사본.

paymentRequestId

PaymentRequest의 \[\[details\]\].id.

paymentOptions

대응하는 PaymentRequest의 생성자에 전달된 paymentOptions 사전의 복사본.

shippingOptions

대응하는 PaymentRequest의 PaymentDetailsInit에 있는 shippingOptions 필드의 복사본.

그런 다음 dispatchedEvent와 함께 다음 단계를 병렬로 실행한다:
1. dispatchedEvent의 모든 extend lifetime promises가 해결될 때까지 기다린다.
2. 웹 기반 결제 핸들러가 PaymentHandlerResponse를 제공하지 않았다면, Promise that was created by PaymentRequest.show()를 "OperationError" DOMException으로 거부한다.

호출된 웹 기반 결제 핸들러는 자신에 대한 정보를 표시하거나 사용자 입력을 요청해야 할 수도 있고 그렇지 않을 수도 있다. 가능한 웹 기반 결제 핸들러 표시의 몇 가지 예는 다음과 같다:

웹 기반 결제 핸들러가 사용자가 인증 코드를 제공할 수 있도록 창을 연다.
웹 기반 결제 핸들러가 이전 사용자 설정을 통해 제공된 해당 사이트의 기본 정보를 사용하여 사용자가 결제를 쉽게 확인할 수 있는 창을 연다.
주어진 세션에서 처음 결제 수단으로 선택되면, 웹 기반 결제 핸들러가 창을 연다. 같은 세션에서 이후 결제의 경우, 웹 기반 결제 핸들러는 (구성을 통해) 창을 열거나 사용자 상호작용을 요구하지 않고 자신의 역할을 수행한다.

시각적 표시와 사용자 상호작용이 필요한 웹 기반 결제 핸들러는 사용자에게 페이지를 표시하기 위해 openWindow()를 호출할 수 있다.

참고

사용자 에이전트는 이 메서드가 PaymentRequestEvent와 연결되어 있음을 알고 있으므로, 흐름과 일관되고 사용자에게 혼란을 주지 않는 방식으로 창을 렌더링해야 한다. 결과적으로 생성된 윈도우 클라이언트는 PaymentRequest를 시작한 탭/창에 바인딩된다. 단일 웹 기반 결제 핸들러는 이 메서드를 사용해 둘 이상의 클라이언트 창을 열 수 없도록 해야 한다.

Issue 115: 창 열기 알고리즘

이 알고리즘은 Service Workers 명세의 창 열기 알고리즘과 유사하다.

Issue 115: 창 열기 알고리즘

해당 단계들을 복사하는 대신 Service Workers 명세를 참조해야 하는가?

event를 이 PaymentRequestEvent로 둔다.
event의 isTrusted 속성이 false이면, "InvalidStateError" DOMException으로 거부된 Promise를 반환한다.
request를 이 PaymentRequestEvent를 유발한 PaymentRequest로 둔다.
url을 url 인수를 파싱한 결과로 둔다.
url 파싱이 예외를 던지면, 해당 예외로 거부된 Promise를 반환한다.
url이 about:blank이면, TypeError로 거부된 Promise를 반환한다.
url의 출처가 웹 기반 결제 핸들러와 연결된 서비스 워커의 출처와 같지 않으면, null로 이행되는 Promise를 반환한다.
promise를 새로운 Promise로 둔다.
promise를 반환하고, 남은 단계들을 병렬로 수행한다:
event.[[windowClient]]가 null이 아니면, 다음을 수행한다:
1. event.[[windowClient]].visibilityState가 "unloaded"가 아니면, promise를 "InvalidStateError" DOMException으로 거부하고 이 단계들을 중단한다.
newContext를 새로운 최상위 브라우징 컨텍스트로 둔다.
예외 허용 및 교체 허용 상태로, 탐색을 통해 newContext를 url로 이동시킨다.
탐색이 예외를 던지면, promise를 해당 예외로 거부하고 이 단계들을 중단한다.
newContext의 출처가 웹 기반 결제 핸들러와 연결된 서비스 워커 클라이언트의 출처와 같지 않으면, 다음을 수행한다:
1. promise를 null로 이행한다.
2. 이 단계들을 중단한다.
client를 newContext를 인수로 하여 window client 생성 알고리즘을 실행한 결과로 둔다.
event.[[windowClient]]를 client로 설정한다.
promise를 client로 이행한다.

이 절은 규범적이지 않다.

이 예시는 PaymentRequestEvent를 수신하는 서비스 워커를 작성하는 방법을 보여준다. PaymentRequestEvent를 수신하면, 서비스 워커는 사용자와 상호작용하기 위해 창을 연다.

예시 2: PaymentRequestEvent 처리

async function getPaymentResponseFromWindow() {
  return new Promise((resolve, reject) => {
    self.addEventListener("message", listener = e => {
      self.removeEventListener("message", listener);
      if (!e.data || !e.data.methodName) {
        reject();
        return;
      }
      resolve(e.data);
    });
  });
}

self.addEventListener("paymentrequest", e => {
  e.respondWith((async() => {
    // 사용자에게 결제 UI를 제공하기 위해 새 창을 연다.
    const windowClient = await e.openWindow("payment_ui.html");

    // 열린 창으로 데이터를 보낸다.
    windowClient.postMessage({
      total: e.total,
      modifiers: e.modifiers
    });

    // 열린 창으로부터 결제 응답을 기다린다.
    return await getPaymentResponseFromWindow();
  })());
});

위에서 설명한 단순한 방식에 따르면, 웹 기반 결제 핸들러 창에 로드되는 간단한 HTML 페이지는 다음과 같을 수 있다:

예시 3: 단순한 결제 핸들러 창

<form id="form">
<table>
  <tr><th>카드 소지자 이름:</th><td><input name="cardholderName"></td></tr>
  <tr><th>카드 번호:</th><td><input name="cardNumber"></td></tr>
  <tr><th>만료 월:</th><td><input name="expiryMonth"></td></tr>
  <tr><th>만료 연도:</th><td><input name="expiryYear"></td></tr>
  <tr><th>보안 코드:</th><td><input name="cardSecurityCode"></td></tr>
  <tr><th></th><td><input type="submit" value="결제"></td></tr>
</table>
</form>

<script>
navigator.serviceWorker.addEventListener("message", e => {
  /* 참고: 결제 앱에서 보낸 메시지는 e.data에서 사용할 수 있다 */
});

document.getElementById("form").addEventListener("submit", e => {
  const details = {};
  ["cardholderName", "cardNumber", "expiryMonth", "expiryYear", "cardSecurityCode"]
  .forEach(field => {
    details[field] = form.elements[field].value;
  });

  const paymentAppResponse = {
    methodName: "https://example.com/pay",
    details
  };

  navigator.serviceWorker.controller.postMessage(paymentAppResponse);
  window.close();
});
</script>

사용자 에이전트는 해당 respondWith 함수에 제공된 Promise의 해결을 통해 웹 기반 결제 핸들러로부터 성공적인 응답을 받는다. PaymentRequestEvent 인터페이스의 애플리케이션은 결제 응답을 포함한 PaymentHandlerResponse 인스턴스로 Promise를 해결해야 한다. 사용자가 취소했거나 오류가 발생한 경우, 애플리케이션은 Promise를 거부함으로써 실패를 알릴 수 있다.

PaymentHandlerResponse는 다음 사전을 사용하여 전달된다:

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

사용자가 거래를 이행하기 위해 선택한 결제 수단 식별자이다. 해당 결제 수단에 대한 것이다.

거래를 처리하고 자금 이체 성공 여부를 판단하기 위해 가맹점이 사용하는, 결제 수단별 메시지를 제공하는 JSON 직렬화 가능한 객체.

사용자가 제공한 지불자 이름.

사용자가 제공한 지불자 이메일.

사용자가 제공한 지불자 전화번호.

사용자가 제공한 배송 주소.

사용자가 선택한 배송 옵션의 식별자.

이 알고리즘이 methodName과 methodDetails 매개변수로 호출되면, 사용자 에이전트는 반드시 다음 단계를 실행해야 한다:

주어진 methodName과 methodDetails 매개변수를 사용해 생성된 PaymentMethodChangeEvent event와 함께 결제 수단 변경 알고리즘을 실행한다.
event.updateWith(detailsPromise)가 실행되지 않으면, null을 반환한다.
event.updateWith(detailsPromise)가 예외를 던지면, 해당 오류를 다시 던진다.
event.updateWith(detailsPromise)가 시간 초과되면 (선택 사항), "InvalidStateError" DOMException을 던진다.
event.updateWith(detailsPromise)의 detailsPromise로부터 PaymentRequestDetailsUpdate를 구성하고 반환한다.

이 알고리즘이 shippingAddress 또는 shippingOption과 함께 호출되면 사용자 에이전트는 반드시 다음 단계를 실행해야 한다:

업데이트된 세부정보(shippingAddress 또는 shippingOption)를 사용해 생성된 PaymentRequestUpdateEvent event와 함께 PaymentRequest 업데이트 알고리즘을 실행한다.
event.updateWith(detailsPromise)가 실행되지 않으면, null을 반환한다.
event.updateWith(detailsPromise)가 예외를 던지면, 해당 오류를 다시 던진다.
event.updateWith(detailsPromise)가 시간 초과되면 (선택 사항), "InvalidStateError" DOMException을 던진다.
event.updateWith(detailsPromise)의 detailsPromise로부터 PaymentRequestDetailsUpdate를 구성하고 반환한다.

이 알고리즘이 event와 handlerResponsePromise 매개변수로 호출되면, 사용자 에이전트는 반드시 다음 단계를 실행해야 한다:

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

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

예시 4: 결제 응답 보내기

paymentRequestEvent.respondWith(new Promise(function(accept,reject) {
  /* ... 여기서 처리가 발생할 수 있다 ... */
  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",
  });
}));

참고

[payment-request]는 생태계의 당사자들(결제 앱 제공자와 수취인 포함)이 네트워크 또는 기타 실패 이후 정산을 위해 사용할 수 있는 ID를 정의한다.

이 알고리즘이 reason과 함께 호출되면, 사용자 에이전트는 반드시 다음 단계를 실행해야 한다:

reason이 "OperationError" DOMException이면, [payment-request]에 정의된 결제 핸들러가 내부 오류를 나타내는 알고리즘을 실행한다.
그렇지 않으면, [payment-request]에 정의된 사용자가 결제 요청을 중단하는 알고리즘을 실행한다.

참고

이 명세의 이전 버전들은 결제 앱 실패 알고리즘이 호출되었을 때 무엇이 일어나는지를 정의하지 않았다. 실제로 구현자들은 사용자가 결제 요청을 중단하는 알고리즘이 실행된 것처럼 동작했다. 가능한 한 많은 하위 호환성을 유지하면서도 웹 기반 결제 핸들러가 내부 오류를 나타낼 수 있는 방법을 도입하기 위해, 이 명세는 이제 "OperationError" DOMException이 아닌 모든 reason 값을 사용자 중단으로 매핑한다. 향후 이 명세의 버전에서는 추가로 처리되는 값이 추가될 수 있다.

웹 결제 워킹 그룹은 개인정보 보호 문제로 인해 Payment Request API의 원래 버전에서 배송 및 청구 주소 지원을 제거했다. 자세한 내용은 issue 842를 참조하라. 이 기능을 계속 지원하는 구현에 대한 문서를 제공하기 위해, 워킹 그룹은 이제 개인정보 보호 문제를 해결한다는 기대 아래 해당 기능을 복원하고 있다. 이 과정에서 워킹 그룹은 다른 API(예: Content Picker API)의 발전에 따라 Payment Request API도 변경할 수 있다.

이 API는 사용자가 등록한 웹 기반 결제 핸들러에 대한 정보를 공유하지 않는다. 출처의 정보는 사용자의 동의가 있을 때만 수취인과 공유된다.
사용자 에이전트는 사용자가 해당 결제 핸들러를 선택하기 전까지 어떤 웹 기반 결제 핸들러와도 결제 요청 정보를 공유해서는 안 된다.
Web-based Payment Handler API를 지원하는 브라우저에서, 가맹점이 URL 기반 결제 수단 식별자로 PaymentRequest 객체를 생성하면, 등록된 웹 기반 결제 핸들러에서 CanMakePaymentEvent가 유한한 출처 집합에 대해 발생한다. 그 출처들은 결제 수단 매니페스트의 출처와 그 지원되는 출처이다. 이 이벤트는 사용자가 해당 결제 핸들러를 선택하기 전에 발생하지만, 이를 유발한 출처(즉, 가맹점 웹사이트)에 대한 정보는 포함하지 않으므로 사용자를 직접 추적하는 데 사용할 수 없다.
우리는 CanMakePaymentEvent를 통한 타이밍 공격의 위험을 인정한다:
- 가맹점 웹사이트가 백엔드 채널(예: fetch API)을 통해 웹 기반 결제 핸들러 출처에 곧 PaymentRequest 객체를 생성할 것이라는 사실을 공유하며 알린다.
- 그 다음 가맹점 웹사이트가 PaymentRequest를 생성하고, 설치된 웹 기반 결제 핸들러에서 CanMakePaymentEvent가 발생하도록 한다.
- 해당 웹 기반 결제 핸들러는 자기 출처에 접속하고, 서버 측에서 두 요청을 연결하려고 시도한다.
사용자 에이전트는 사용자가 CanMakePaymentEvent 지원을 비활성화할 수 있도록 해야 한다.
Web-based Payment Handler API를 지원하는 브라우저에서, CanMakePaymentEvent는 배송 주소와 지불자 연락처 정보를 포함하여 가맹점이 요청한 모든 정보를 필요할 때 제공할 수 있는 등록된 웹 기반 결제 핸들러에서 발생한다.

Service Worker 보안 고려사항을 참조하라
결제 수단 보안은 이 명세의 범위 밖이며, 해당 결제 수단을 지원하는 웹 기반 결제 핸들러가 이를 다룬다.

특정 결제 수단을 담당하는 당사자는 결제 수단 매니페스트를 통해 결제 앱을 승인한다. 자세한 내용은 CanMakePaymentEvent 처리 알고리즘을 참조하라.
사용자 에이전트는 보안 문제를 일으키는 웹 기반 결제 핸들러를 제공할 필요가 없다. 보안 문제에는 다음이 포함될 수 있다:
- 만료되었거나, 취소되었거나, 자체 서명된 인증서 등.
- 혼합 콘텐츠
- HTTPs를 통해 제공되는 페이지가 그렇지 않은 페이지로 리디렉션되는 경우.
- 안전 브라우징 데이터베이스에서 결제 핸들러가 악성으로 알려진 경우
보안상의 이유로 웹 기반 결제 핸들러를 사용할 수 없는 경우, 사용자 에이전트는 웹 기반 결제 핸들러 개발자에게 근거를 제공해야 하며(예: 콘솔 메시지를 통해), 혼란을 피할 수 있도록 사용자에게도 알릴 수 있다.

결제 수단 매니페스트는 특정 결제 수단에 대한 결제 앱 배포를 출처에 허가한다. 사용자 에이전트가 웹 기반 결제 핸들러가 결제 수단 매니페스트에 나열된 출처와 일치하는지를 판단할 때, 사용자 에이전트는 웹 기반 결제 핸들러의 서비스 워커 등록의 scope URL을 사용한다.

탈취된 수취인 사이트가 사기성이 있거나 형식이 잘못된 결제 수단 데이터(또는 그와 관련해 결제 요청 데이터)를 수취인 서버에 제출하는 시나리오를 완화하기 위해, 수취인 서버는 데이터 형식을 검증하고, 해당 데이터를 수락된 결제 수단, 총액, 표시 항목, 배송 주소와 같은 서버의 권위 있는 정보와 연관 지어야 한다.

Payment Request API가 "비공개 브라우징 모드"에서 호출되면, 사용자 에이전트는 웹 기반 결제 핸들러를 비공개 컨텍스트에서 실행해야 한다. 이는 일반적으로 사이트가 이전에 저장된 정보에 접근하는 것을 막는다. 따라서 사용자가 출처에 로그인하거나 결제 세부정보를 다시 입력해야 할 가능성이 크다.
CanMakePaymentEvent 이벤트는 비공개 브라우징 모드에서 발생해서는 안 된다. 사용자 에이전트는 respondWith()가 false와 함께 호출된 것처럼 동작해야 한다. 우리는 그에 따른 위험을 인정한다: 어떤 개체가 Payment Request API 호출의 출처와 웹 기반 결제 핸들러의 출처를 모두 제어한다면, 그 개체는 사용자가 비공개 브라우징 모드에 있을 수 있음을 추론할 수 있다.

웹 기반 결제 처리기 API

요약

이 문서의 상태

1. 소개

2. 개요

2.1 결제 요청 처리

2.2 다른 유형의 결제 앱과의 관계

3. 등록

3.1 즉시 등록

4. 관리

4.1 ServiceWorkerRegistration 인터페이스에 대한 확장

4.2 PaymentManager 인터페이스

4.2.1 userHint 속성

4.2.2 enableDelegations() 메서드

4.3 PaymentDelegation 열거형

5. 결제 가능 여부

5.1 ServiceWorkerGlobalScope에 대한 확장

5.1.1 oncanmakepayment 속성

5.2 CanMakePaymentEvent

5.2.1 respondWith() 메서드

5.3 CanMakePaymentEvent 처리

5.4 CanMakePaymentEvent 처리 예

5.5 결제 핸들러의 필터링

6. 호출

6.1 ServiceWorkerGlobalScope에 대한 확장

6.1.1 onpaymentrequest 속성

6.2 PaymentRequestDetailsUpdate

6.2.1 error 멤버

6.2.2 total 멤버

6.2.3 modifiers 멤버

6.2.4 shippingOptions 멤버

6.2.5 paymentMethodErrors 멤버

6.2.6 shippingAddressErrors 멤버

6.3 PaymentRequestEvent

6.3.1 topOrigin 속성

6.3.2 paymentRequestOrigin 속성

6.3.3 paymentRequestId 속성

6.3.4 methodData 속성

6.3.5 total 속성

6.3.6 modifiers 속성

6.3.7 paymentOptions 속성

6.3.8 shippingOptions 속성

6.3.9 openWindow() 메서드

6.3.10 changePaymentMethod() 메서드

6.3.11 changeShippingAddress() 메서드

6.3.12 changeShippingOption() 메서드

6.3.13 respondWith() 메서드

6.3.14 PaymentRequestEventInit 사전

6.3.15 MethodData Population Algorithm

6.3.16 Modifiers Population Algorithm

6.4 내부 슬롯

6.5 PaymentRequestEvent 처리

7. 창

7.1 창 열기 알고리즘

7.2 PaymentRequestEvent 처리 예시

8. 응답

8.1 PaymentHandlerResponse 사전

8.1.1 methodName 속성

8.1.2 details 속성

8.1.3 payerName 속성

8.1.4 payerEmail 속성

8.1.5 payerPhone 속성

8.1.6 shippingAddress 속성

8.1.7 shippingOption 속성

8.2 결제 수단 변경 알고리즘

8.3 결제 세부정보 변경 알고리즘

8.4 PaymentRequest 응답 알고리즘

8.5 결제 앱 실패 알고리즘

9. 보안 및 개인정보 보호 고려사항

9.1 주소

9.2 사용자 환경에 대한 정보

9.3 결제 핸들러 설치에 대한 사용자 동의

9.4 결제 전 사용자 동의

9.5 교차 출처 데이터 공유에 대한 사용자 인식

9.6 보안 통신

9.7 승인된 결제 앱

9.8 지원되는 출처

9.9 데이터 검증

9.10 비공개 브라우징 모드

10. 결제 핸들러 표시 고려사항

4.1 `ServiceWorkerRegistration` 인터페이스에 대한 확장

4.2 `PaymentManager` 인터페이스

4.2.1 `userHint` 속성

4.2.2 `enableDelegations()` 메서드

4.3 `PaymentDelegation` 열거형

5.1 `ServiceWorkerGlobalScope`에 대한 확장

5.1.1 `oncanmakepayment` 속성

5.2 `CanMakePaymentEvent`

5.2.1 `respondWith()` 메서드

5.4 `CanMakePaymentEvent` 처리 예

6.1 `ServiceWorkerGlobalScope`에 대한 확장

6.1.1 `onpaymentrequest` 속성

6.2 `PaymentRequestDetailsUpdate`

6.2.1 `error` 멤버

6.2.2 `total` 멤버

6.2.3 `modifiers` 멤버

6.2.4 `shippingOptions` 멤버

6.2.5 `paymentMethodErrors` 멤버

6.2.6 `shippingAddressErrors` 멤버

6.3 `PaymentRequestEvent`

6.3.1 `topOrigin` 속성

6.3.2 `paymentRequestOrigin` 속성

6.3.3 `paymentRequestId` 속성

6.3.4 `methodData` 속성

6.3.5 `total` 속성

6.3.6 `modifiers` 속성

6.3.7 `paymentOptions` 속성

6.3.8 `shippingOptions` 속성

6.3.9 `openWindow()` 메서드

6.3.10 `changePaymentMethod()` 메서드

6.3.11 `changeShippingAddress()` 메서드

6.3.12 `changeShippingOption()` 메서드

6.3.13 `respondWith()` 메서드

6.3.14 `PaymentRequestEventInit` 사전

7.2 `PaymentRequestEvent` 처리 예시

8.1 `PaymentHandlerResponse` 사전

8.1.1 `methodName` 속성

8.1.2 `details` 속성

8.1.3 `payerName` 속성

8.1.4 `payerEmail` 속성

8.1.5 `payerPhone` 속성

8.1.6 `shippingAddress` 속성

8.1.7 `shippingOption` 속성