Facilitated Payment Link Type in HTML

1. Introduction

Online checkout flows often involve push payments, where the customer initiates the payment based on information provided by the merchant. These push payments can sometimes lead to friction in the user experience, especially when they involve actions like scanning QR codes or navigating to external payment applications.

User agents, such as web browsers, have the potential to streamline these push payment flows by integrating with payment wallets and providing a more seamless payment experience. However, currently, there is no standardized way for web pages to passively indicate the availability of push payment methods to the user agent.

This specification defines a mechanism for web pages to signal the availability of push-based payment methods by using the <link rel="facilitated-payment"> element. This allows user agents to detect supported payment methods and offer users a smoother payment experience by integrating with compatible payment wallets.

For background information, use cases, and examples, refer to the explainer document.

2. Definitions

This specification uses the following terms:

• Payment client: An integrated wallet or a browser wallet extension that is responsible for facilitating payments.

• Payment method: A specific way of making a payment, such as UPI, Bitcoin, or a particular eWallet. It is identified by the URL scheme in the href attribute of a facilitated-payment link.

3. Link type "facilitated-payment"

The facilitated-payment keyword may be used with link elements. The keywords creates an external resource link. The keyword is body-ok.

The facilitated-payment keyword indicates the availability of a push payment method on a web page. It creates a relationship between the document and a payment method resource.

There is no default type for resources given by the facilitated-payment keyword.

A user agent must not delay the load event for this link type.

The URL scheme of the href attribute indicates supported payment methods. The URL may contain additional information specific to the payment method.

The appropriate times to fetch and process the linked resource for such a link are:

• When the external resource link is created on a link element that is already browsing-context connected.

• When the external resource link’s link element becomes browsing-context connected.

• When the href attribute of the link element of an external resource link that is already browsing-context connected is changed.

The fetch and process the linked resource algorithm for facilitated-payment links, given a link element el, is as follows:

1. If el’s relevant settings object is not a secure context, then return.

2. If el’s node navigable is not a top-level traversable, then return.

3. If el’s node document is not allowed to use the payment feature, then return.

4. If el’s href attribute’s value is the empty string, then return.

5. Let url be the result of encoding-parsing a URL given el’s href attribute’s value, relative to el’s node document.

6. If url is failure, then return.

7. If url’s scheme is not supported for facilitated payments by the user agent, then return.

8. Find all payment wallets integrated with the user agent which are compatible with url’s scheme. Let compatibleWallets be a set containing all such wallets.

9. If compatibleWallets’s size is 0, then return.

10. Prompt the user with a wallet selector containing compatibleWallets for users to choose the payment method they want to use.

11. If the wallet selector is dismissed, then return.

12. Hand off url to the selected wallet software. This wallet software must not immediately perform any payments, but instead should help the user perform the specified payment, using details specified in url such as the payment amount, payee, and currency. The details of how such wallet software is integrated with the user agent, and how the handoff is performed, are implementation-defined.

4. Security Considerations

There is a possibility of malicious actors injecting their own facilitated-payment links into web pages and tricking the users into paying them. Standard safety checks done by browsers will offer some level of protection against such attacks.

Per the algorithm given above, the facilitated-payment link needs to be on on a page with the following properties:**

• Cryptographic scheme (e.g., HTTPS. One exception being localhost).

• Valid SSL (no expired cert).

• No mixed content (i.e., all sub-resources must come from HTTPS).

• Only on top-level context (not inside of an iframe).

• The tab is active.

• No Permissions-Policy restrictions on the payment feature. (i.e., pages can disable facilitated-payment links via Permissions-Policy: payment=() HTTP header.)

Also, as mentioned in the previous section, the detected facilitated-payment link needs to be validated before further processing.

5. Privacy Considerations

A malicious payment client could use the existence of facilitated-payment links to track the user. This is an existing concern with e.g., extension based apps (which often ask for permission to view all webpages the user visits), but should be considered for this proposal too.

Browsers should manage payment clients with care; users should be made aware of the risks and be given control over the payment clients in their browser. Certain privacy savvy users may prefer not to let the payment clients get access to their payment info even if they may not contain any sensitive data. Where appropriate, a user agent might consider policies around how a payment client can be integrated with (for example, via apps store policies on platforms that have app stores).

The user agent should prompt the user before initiating payment. User consent is required every time.