search

WICG / paymentlink

Other
3 stars 3 forks source link

readme

Support for Payment link type in HTML

Last Update: August 24, 2023

Authors:

Terminology

Push payment - Payment is initiated by the payer (consumer).

Examples

Introduction

Online checkout flows can be broadly classified as push and pull payments*. A push payment is initiated by the consumer based on information provided by the merchant, whereas a pull payment is initiated by the merchant and collects information from the user.

Certain push payment flows can cause high friction for users (e.g. display of a QR code that the user needs to scan with an eWallet app). Browsers may have the ability to more easily facilitate these payment flows (e.g. if the user has a wallet installed on their device that supports the underlying payment method for the displayed QR, or has a browser extension for the supported eWallet). Currently there is no easy way for browsers to know passively if a particular payment method is being offered by the merchant. The Payment Request API exists, but it requires active integration (e.g., merchant must explicitly trigger the API, handle communication with it, etc).

We believe there is benefit for a 'passive' method to allow browsers to detect push payment flows, to allow users of integrated wallets the option of a better experience. A solution is proposed below to standardize payment links that can be embedded in checkout pages to give an 'alternate' representation of the payment method(s) that the merchant is presenting (in addition to e.g., showing the user a visual QR code, or a login button for an eWallet). This can be accomplished by extending the link data type in HTML. Links are used to define relationships between a document and other resources. This explainer proposes adding a new link type, "payment", to the HTML specification. The "payment" link type would be used to indicate a resource that can be used to make a payment.

* Pull payments are not in scope for this proposal, but are mentioned to provide clarity on the existing browser solutions for optimizing online checkout experience.

Goals

Non-goals

Use cases

Proposed solution - "payment" link relationship

The "payment" link is expected to follow the standard specifications of a Link type with the rel attribute set to "payment".

<link rel=”payment” href="https://github.com/WICG/paymentlink/blob/main/Any URL, where the URL scheme determines the payment method type">

The merchant or payment processor can embed this link in the relevant payment pages, hence allowing the browser to optimize the payment experience whenever possible. The browser is responsible for detecting the presence of a "payment" link in any page. It then notifies the payment clients that have registered the associated scheme for receiving "payment" links. Some basic validations of the URI might be supported but it is the merchant's responsibility to ensure that the URI conforms to the specification associated with the scheme.

Possible payment sequence using "payment" link

  1. User navigates through a checkout flow and selects the push payment method.
  2. The merchant displays the payment page. This page may show a QR code or a login screen depending on the merchant configuration. It's also possible for the payment page to be hosted by a payment processor or an eWallet. In this case, the merchant would have done a redirect.
  3. Browser detects the "payment" link on the page.
  4. Browser notifies the payment clients, passing down the "payment" link.
  5. The payment client prompts the user to initiate a payment. This can happen on the same device or a different device depending on the payment client capabilities.
  6. The user initiates a push payment on the payment client.
  7. The payment client initiates a payment through the underlying payment processor.
  8. The payment processor notifies the merchant and the merchant displays a payment confirmation.

Payment sequence

Example "payment" links

The examples listed below are only meant to illustrate the usage of payment links, with the help of some commonly known payment methods. The URI specification for various payment methods is out of scope of this proposal.

UPI - Instant payment system based in India

As seen above, the rel="payment" attribute indicates that this is a payment link. The scheme, upi, along with the host, pay, indicates that the payment method is UPI.

Bitcoin

eWallets

Privacy considerations

A malicious payment client could use the existence of 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 browser might consider policies around how a payment client can be integrated with that browser (for example, via apps store policies on platforms that have app stores).

Security considerations

There is a possibility of malicious actors injecting their own "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. For example, Safe Browsing feature on Chrome protects the user from known phishing and malware sites. Some additional options that payment clients can consider to mitigate risk are listed below.