This allows the user agent to not require user activation, for example to support redirect flows where a user activation may not - be present upon redirect. See - for security - considerations. + be present upon redirect. See for security considerations.
If the user agent does not require user activation as part of the - {{PaymentRequest/show()}} method, some additional security mitigations - should be considered. Not requiring user activation increases the risk - of spam and click-jacking attacks, by allowing a Payment Request UI - to be initiated without the user interacting with the page immediately - beforehand. + {{PaymentRequest/show()}} method, some additional security + mitigations should be considered. Not requiring user activation + increases the risk of spam and click-jacking attacks, by allowing a + Payment Request UI to be initiated without the user interacting with + the page immediately beforehand.
- In order to mitigate spam, the user agent may decide to enforce a user - activation requirement after some threshold, for example after the - user has already been shown a Payment Request UI without a user + In order to mitigate spam, the user agent may decide to enforce a + user activation requirement after some threshold, for example after + the user has already been shown a Payment Request UI without a user activation on the current page. In order to mitigate click-jacking - attacks, the user agent may implement a time threshold in which clicks - are ignored immediately after a dialog is shown. + attacks, the user agent may implement a time threshold in which + clicks are ignored immediately after a dialog is shown.
Another relevant mitigation exists in step 6 of - {{PaymentRequest/show()}}, where the document must be visible in order - to initiate the user interaction. + {{PaymentRequest/show()}}, where the document must be visible in + order to initiate the user interaction.