|
586 | 586 | readonly attribute DOMString? shippingOption;
|
587 | 587 | readonly attribute PaymentShippingType? shippingType;
|
588 | 588 |
|
| 589 | + attribute EventHandler onmerchantvalidation; |
589 | 590 | attribute EventHandler onshippingaddresschange;
|
590 | 591 | attribute EventHandler onshippingoptionchange;
|
591 | 592 | attribute EventHandler onpaymentmethodchange;
|
|
1290 | 1291 | "PaymentOptions.shippingType">shippingTypea> member).
|
1291 | 1292 | p>
|
1292 | 1293 | section>
|
| 1294 | + <section data-dfn-for="PaymentRequest" data-link-for="PaymentRequest"> |
| 1295 | + <h2> |
| 1296 | + <dfn>onmerchantvalidationdfn> attribute |
| 1297 | + h2> |
| 1298 | + <p data-tests= |
| 1299 | + "payment-request/onmerchantvalidation-attribute.https.html"> |
| 1300 | + A <a>PaymentRequesta>'s <a>onmerchantvalidationa> attribute is an |
| 1301 | + <a>EventHandlera> for a <a>MerchantValidationEventa> named |
| 1302 | + "<a>merchantvalidationa>". |
| 1303 | + p> |
| 1304 | + section> |
1293 | 1305 | <section data-dfn-for="PaymentRequest" data-link-for="PaymentRequest">
|
1294 | 1306 | <h2>
|
1295 | 1307 | <dfn>onshippingaddresschangedfn> attribute
|
|
3722 | 3734 | Target
|
3723 | 3735 | th>
|
3724 | 3736 | tr>
|
| 3737 | + <tr> |
| 3738 | + <td> |
| 3739 | + <code><dfn>merchantvalidationdfn>code> |
| 3740 | + td> |
| 3741 | + <td> |
| 3742 | + <a>MerchantValidationEventa> |
| 3743 | + td> |
| 3744 | + <td> |
| 3745 | + The user agent requires the merchant to perform merchant |
| 3746 | + validation. |
| 3747 | + td> |
| 3748 | + <td> |
| 3749 | + <a>PaymentRequesta> |
| 3750 | + td> |
| 3751 | + tr> |
3725 | 3752 | <tr>
|
3726 | 3753 | <td>
|
3727 | 3754 | <code><dfn>shippingaddresschangedfn>code>
|
|
3782 | 3809 | tr>
|
3783 | 3810 | table>
|
3784 | 3811 | section>
|
| 3812 | + <section data-dfn-for="MerchantValidationEvent" data-link-for= |
| 3813 | + "MerchantValidationEvent"> |
| 3814 | + <h2> |
| 3815 | + <dfn>MerchantValidationEventdfn> interface |
| 3816 | + h2> |
| 3817 | + <pre class="idl"> |
| 3818 | + [Constructor(DOMString type, optional MerchantValidationEventInit eventInitDict), |
| 3819 | + SecureContext, Exposed=Window] |
| 3820 | + interface MerchantValidationEvent : Event { |
| 3821 | + readonly attribute USVString validationURL; |
| 3822 | + void complete(Promise<any> merchantSessionPromise); |
| 3823 | + }; |
| 3824 | + pre> |
| 3825 | + <section> |
| 3826 | + <h3> |
| 3827 | + <dfn data-lt= |
| 3828 | + "MerchantValidationEvent.MerchantValidationEvent()"><code>MerchantValidationEventcode> |
| 3829 | + constructordfn> |
| 3830 | + h3> |
| 3831 | + <p data-tests= |
| 3832 | + "MerchantValidationEvent/constructor.https.html, MerchantValidationEvent/constructor.http.html"> |
| 3833 | + The <a data-cite="dom#concept-event-constructor-ext">event |
| 3834 | + constructing stepsa>, which take a <a>MerchantValidationEventa> |
| 3835 | + <var>eventvar>, are as follows: |
| 3836 | + p> |
| 3837 | + <ol class="algorithm"> |
| 3838 | + <li>Let <var>basevar> be the <a data-cite= |
| 3839 | + "dom#context-object">eventa>’s <a data-cite= |
| 3840 | + "!html/multipage/webappapis.html#relevant-settings-object">relevant |
| 3841 | + settings objecta>’s <a data-cite= |
| 3842 | + "!html/multipage/webappapis.html#api-base-url">API base URLa>. |
| 3843 | + li> |
| 3844 | + <li>Let <var>inputvar> be the empty string. |
| 3845 | + li> |
| 3846 | + <li>If <var>eventInitDictvar> was passed, set <var>inputvar> to |
| 3847 | + the value of <var>eventInitDictvar>["<a>validationURLa>"]. |
| 3848 | + li> |
| 3849 | + <li data-link-for="MerchantValidationEventInit">Let |
| 3850 | + <var>validationURLvar> be the result of <a data-cite= |
| 3851 | + "!url#concept-url-parser">URL parsinga> <var>inputvar> and |
| 3852 | + <var>basevar>. |
| 3853 | + li> |
| 3854 | + <li>If <var>validationURLvar> is failure, throw a |
| 3855 | + <a>TypeErrora>. |
| 3856 | + li> |
| 3857 | + <li>Initialize <var>eventvar>.<a>validationURLa> attribute to |
| 3858 | + <var>validationURLvar>. |
| 3859 | + li> |
| 3860 | + <li>Initialize <var>eventvar>.<a data-lt= |
| 3861 | + "mechvalidation.waitForUpdate">[[\waitForUpdate]]a> to false. |
| 3862 | + li> |
| 3863 | + ol> |
| 3864 | + section> |
| 3865 | + <section> |
| 3866 | + <h3> |
| 3867 | + <dfn>validationURLdfn> attribute |
| 3868 | + h3> |
| 3869 | + <p> |
| 3870 | + A <a data-cite="url#concept-url">URLa> from which a developer can |
| 3871 | + fetch <a>payment handlera>-specific verification data. By then |
| 3872 | + passing that data (or a promise that resolves with that data) to |
| 3873 | + <a>complete()a>, the user agent can verify that the payment |
| 3874 | + request is from a authorized merchant. |
| 3875 | + p> |
| 3876 | + <p> |
| 3877 | + When getting, returns the value it was <a data-cite= |
| 3878 | + "dom#inner-event-creation-steps">initializeda> with. |
| 3879 | + p> |
| 3880 | + section> |
| 3881 | + <section> |
| 3882 | + <h3> |
| 3883 | + <dfn>complete()dfn> method |
| 3884 | + h3> |
| 3885 | + <p data-test= |
| 3886 | + "payment-request/MerchantValidationEvent/complete-method-manual.https.html"> |
| 3887 | + The <a>MerchantValidationEventa>'s |
| 3888 | + <code>complete(<var>merchantSessionPromisevar>)code> method |
| 3889 | + MUST act as follows: |
| 3890 | + p> |
| 3891 | + <ol class="algorithm"> |
| 3892 | + <li>Let <var>eventvar> be the <a>context objecta>. |
| 3893 | + li> |
| 3894 | + <li>If <var>eventvar>'s <a>isTrusteda> attribute is false, then |
| 3895 | + <a>throwa> an "<a>InvalidStateErrora>" <a>DOMExceptiona>. |
| 3896 | + li> |
| 3897 | + <li>If <var>eventvar>.<a data-lt= |
| 3898 | + "mechvalidation.waitForUpdate">[[\waitForUpdate]]a> is true, then |
| 3899 | + <a>throwa> an "<a>InvalidStateErrora>" <a>DOMExceptiona>. |
| 3900 | + li> |
| 3901 | + <li>Let <var>requestvar> be <var>eventvar>'s <a data-cite= |
| 3902 | + "dom#event-target">targeta>. |
| 3903 | + li> |
| 3904 | + <li>If <var>requestvar>.<a>[[\state]]a> is not |
| 3905 | + "<a>interactivea>", then <a>throwa> an |
| 3906 | + "<a>InvalidStateErrora>" <a>DOMExceptiona>. |
| 3907 | + li> |
| 3908 | + <li>If <var>requestvar>.<a>[[\updating]]a> is true, then |
| 3909 | + <a>throwa> an "<a>InvalidStateErrora>" <a>DOMExceptiona>. |
| 3910 | + li> |
| 3911 | + <li>Set <var>eventvar>'s <a>stop propagation flaga> and <a>stop |
| 3912 | + immediate propagation flaga>. |
| 3913 | + li> |
| 3914 | + <li>Set <var>eventvar>.<a data-lt= |
| 3915 | + "mechvalidation.waitForUpdate">[[\waitForUpdate]]a> to true. |
| 3916 | + li> |
| 3917 | + <li>Run the <a>validate merchant's details algorithma> with <var> |
| 3918 | + merchantSessionPromisevar> and <var>requestvar>. |
| 3919 | + li> |
| 3920 | + ol> |
| 3921 | + section> |
| 3922 | + <section> |
| 3923 | + <h2> |
| 3924 | + Internal Slots |
| 3925 | + h2> |
| 3926 | + <p> |
| 3927 | + Instances of <a>MerchantValidationEventa> are created with the |
| 3928 | + internal slots in the following table: |
| 3929 | + p> |
| 3930 | + <table> |
| 3931 | + <tr> |
| 3932 | + <th> |
| 3933 | + Internal Slot |
| 3934 | + th> |
| 3935 | + <th> |
| 3936 | + Description (<em>non-normativeem>) |
| 3937 | + th> |
| 3938 | + tr> |
| 3939 | + <tr> |
| 3940 | + <td> |
| 3941 | + <dfn data-lt-nodefault="" data-lt= |
| 3942 | + "mechvalidation.waitForUpdate">[[\waitForUpdate]]dfn> |
| 3943 | + td> |
| 3944 | + <td> |
| 3945 | + A boolean indicating whether an <a>complete()a>-initiated |
| 3946 | + update is currently in progress. |
| 3947 | + td> |
| 3948 | + tr> |
| 3949 | + table> |
| 3950 | + section> |
| 3951 | + <section data-dfn-for="MerchantValidationEventInit" data-link-for= |
| 3952 | + "MerchantValidationEventInit"> |
| 3953 | + <h3> |
| 3954 | + <dfn>MerchantValidationEventInitdfn> dictionary |
| 3955 | + h3> |
| 3956 | + <pre class="idl"> |
| 3957 | + dictionary MerchantValidationEventInit : EventInit { |
| 3958 | + USVString validationURL = ""; |
| 3959 | + }; |
| 3960 | + pre> |
| 3961 | + <section> |
| 3962 | + <h4> |
| 3963 | + <dfn>validationURLdfn> member |
| 3964 | + h4> |
| 3965 | + <p> |
| 3966 | + A URL from which a developer would fetch <a>payment |
| 3967 | + handlera>-specific verification data. |
| 3968 | + p> |
| 3969 | + section> |
| 3970 | + section> |
| 3971 | + section> |
3785 | 3972 | <section data-dfn-for="PaymentMethodChangeEvent" data-link-for=
|
3786 | 3973 | "PaymentMethodChangeEvent">
|
3787 | 3974 | <h2>
|
|
4032 | 4219 | object is set to "<a>interactivea>", the <a>user agenta> will
|
4033 | 4220 | trigger the following algorithms based on user interaction.
|
4034 | 4221 | p>
|
| 4222 | + <section> |
| 4223 | + <h2> |
| 4224 | + Merchant validation |
| 4225 | + h2> |
| 4226 | + <p> |
| 4227 | + <dfn data-lt="Validate the merchant">Merchant validationdfn> is the |
| 4228 | + process by which a <a>payment handlera> validates the identity of a |
| 4229 | + merchant against some <var>valuevar> (usually some cryptographic |
| 4230 | + challenge response). Validated merchants are allowed to interface |
| 4231 | + with a <a>payment handlera>. Details of how actual validation is |
| 4232 | + performed is outside the scope of this specification. |
| 4233 | + p> |
| 4234 | + <p> |
| 4235 | + It is OPTIONAL for a <a>payment handlera> to support <a>merchant |
| 4236 | + validationa>. |
| 4237 | + p> |
| 4238 | + <p> |
| 4239 | + For <a>payment methodsa> that support <a>merchant validationa>, |
| 4240 | + the user agent runs the <dfn>request merchant validation |
| 4241 | + algorithmdfn>. The algorithm takes a <a data-cite= |
| 4242 | + "webidl#idl-USVString"><code>USVStringcode>a> |
| 4243 | + <var>merchantSpecificURLvar>, provided by the <a>payment |
| 4244 | + handlera>: |
| 4245 | + p> |
| 4246 | + <ol class="algorithm"> |
| 4247 | + <li>Let <var>requestvar> be the <a>PaymentRequesta> object that |
| 4248 | + the user is interacting with. |
| 4249 | + li> |
| 4250 | + <li>Let <var>validationURLvar> be a <a data-cite= |
| 4251 | + "url#absolute-url-string">absolute URL stringa> from which a |
| 4252 | + developer can fetch <a>payment handlera>-specific verification |
| 4253 | + data. |
| 4254 | + li> |
| 4255 | + <li> |
| 4256 | + <a>Queue a taska> on the <a>user interaction task sourcea> to |
| 4257 | + run the following steps: |
| 4258 | + <ol> |
| 4259 | + <li>Assert: <var>requestvar>.<a>[[\updating]]a> is false. |
| 4260 | + li> |
| 4261 | + <li>Assert: <var>requestvar>.<a>[[\state]]a> is |
| 4262 | + "<a>interactivea>". |
| 4263 | + li> |
| 4264 | + <li>Let <var>eventInitDictvar> be an new |
| 4265 | + <a>MerchantValidationEventInita> dictionary. |
| 4266 | + li> |
| 4267 | + <li data-link-for="MerchantValidationEventInit">Set |
| 4268 | + <var>eventInitDictvar>["<a>validationURLa>"] to |
| 4269 | + <var>validationURLvar>. |
| 4270 | + li> |
| 4271 | + <li>Let <var>eventvar> be the result of <a data-cite= |
| 4272 | + "dom#concept-event-constructor">constructinga> a |
| 4273 | + <a>MerchantValidationEventa> with "<a>merchantvalidationa>" |
| 4274 | + and <var>eventInitDictvar>. |
| 4275 | + li> |
| 4276 | + <li>Initialize <var>eventvar>’s <a data-cite= |
| 4277 | + "dom#dom-event-istrusted"><code>isTrustedcode>a> attribute to |
| 4278 | + true. |
| 4279 | + li> |
| 4280 | + <li> |
| 4281 | + <a data-cite="dom#concept-event-dispatch">Dispatcha> |
| 4282 | + <var>eventvar> to <var>requestvar>. |
| 4283 | + li> |
| 4284 | + ol> |
| 4285 | + li> |
| 4286 | + ol> |
| 4287 | + section> |
4035 | 4288 | <section>
|
4036 | 4289 | <h2>
|
4037 | 4290 | Shipping address changed algorithm
|
|
4821 | 5074 | p>
|
4822 | 5075 | div>
|
4823 | 5076 | section>
|
| 5077 | + <section> |
| 5078 | + <h2> |
| 5079 | + Validate merchant's details algorithm |
| 5080 | + h2> |
| 5081 | + <p> |
| 5082 | + The <dfn>validate merchant's details algorithmdfn> takes a |
| 5083 | + <a>Promisea> <var>opaqueDataPromisevar> and a |
| 5084 | + <a>PaymentRequesta> <var>requestvar>. The steps are conditional |
| 5085 | + on the <var>opaqueDataPromisevar> settling. If |
| 5086 | + <var>opaqueDataPromisevar> never settles then the payment request |
| 5087 | + is blocked. The user agent SHOULD provide the user with a means to |
| 5088 | + abort a payment request. Implementations MAY choose to implement a |
| 5089 | + timeout for pending updates if <var>opaqueDataPromisevar> doesn't |
| 5090 | + settle in a reasonable amount of time. If an implementation chooses |
| 5091 | + to implement a timeout, they MUST execute the steps listed below in |
| 5092 | + the "upon rejection" path. Such a timeout is a fatal error for the |
| 5093 | + payment request. |
| 5094 | + p> |
| 5095 | + <ol class="algorithm"> |
| 5096 | + <li>Set <var>requestvar>.<a>[[\updating]]a> to true. |
| 5097 | + li> |
| 5098 | + <li> |
| 5099 | + <a>In parallela>, disable the user interface that allows the user |
| 5100 | + to accept the payment request. This is to ensure that the payment |
| 5101 | + is not accepted until the user interface is updated with any new |
| 5102 | + details. |
| 5103 | + li> |
| 5104 | + <li> |
| 5105 | + <a>Upon rejectiona> of <var>opaqueDataPromisevar>: |
| 5106 | + <ol> |
| 5107 | + <li> |
| 5108 | + <a>Abort the updatea> with <var>requestvar> and an |
| 5109 | + "<a>AbortErrora>" <a>DOMExceptiona>. |
| 5110 | + li> |
| 5111 | + ol> |
| 5112 | + li> |
| 5113 | + <li> |
| 5114 | + <a>Upon fulfillmenta> of <var>opaqueDataPromisevar> with value |
| 5115 | + <var>opaqueDatavar>: |
| 5116 | + <ol> |
| 5117 | + <li> |
| 5118 | + <a>Validate the merchanta> using <var>opaqueDatavar>. |
| 5119 | + li> |
| 5120 | + <li>If <var>opaqueDatavar> is invalid, as per the validation |
| 5121 | + rules of the <a>payment handlera>, <a>abort the updatea> with |
| 5122 | + <var>requestvar> and an appropriate <a data-cite= |
| 5123 | + "!webidl#dfn-exception">exceptiona> and return. |
| 5124 | + li> |
| 5125 | + <li>Otherwise, set <var>requestvar>.<a>[[\updating]]a> to |
| 5126 | + false. |
| 5127 | + li> |
| 5128 | + <li>Enable the user interface, allowing the request for payment |
| 5129 | + to proceed. |
| 5130 | + li> |
| 5131 | + ol> |
| 5132 | + li> |
| 5133 | + ol> |
| 5134 | + section> |
4824 | 5135 | section>
|
4825 | 5136 | <section class="informative">
|
4826 | 5137 | <h2>
|
|
0 commit comments