Payment Request

Full Title

This wiki page is devoted to the PaymentRequest API from the W3C.

Context

• W3C Web Payments Working Group
• Google explaining what Web Payment are.

Commentary

from Andres Rundgren dated 2020-11-15.

The Payment WG is in the process making the PaymentRequest API a TR.

That's fine. What's maybe somewhat less obvious is that PaymentRequest in itself has no value since it is just an interface that depends on concrete implementations, aka "payment handlers".

For the latter the WG started with browser-based (built in) "basic-cards". This has subsequently been deprecated and is not a part of any standard.

After that the ServiceWorker-based PaymentHandler project was launched with the goal making it possible to write payment handlers using "pure" Web technology. Although this mission has been running for several years, there have been no reports on any major (or even minor) uptake of this technology.

In fact, it appears that the to date only "substantial" use of PaymentRequest is through the proprietary OS/App-level interfaces to iOS and Android provided by Apple/Safari and Google/Chrome respectively.

Recently a new effort called Secure Payment Confirmation (SPC) using FIDO2/WebAuthn was launched. Unlike PaymentHandler, it is based on browser-based (built-in) support for parts of a payment authorization including the UI. However, this is also pretty much the antithesis of the open Web.

The only reasonable conclusion from all of this is that supporting advanced payment systems through "pure" Web technology is not going anywhere. To put things in a slightly simpler wording: it appears to be infeasible building something along the lines of Apple Pay using PaymentHandler. Apple have more or less set the standard for mobile payment systems in the western hemisphere.

• Payment Transaction description from Stripe (2023-08-21)

Status

W3C published Recommendations for Payment Request 1.0 and Payment Method Identifiers: (2022-09-09) https://www.w3.org/blog/news/archives/9672

For more on the history of W3C Member reviews of Payment Request, Formal Objections, and the Director’s decision, please see: https://www.w3.org/2021/12/prapi-objs.html

Contactless

Contactless (by radio) payment requests typically involve interactions between a:

• Central (such as a smartphone or point-of-sale system) and a
• Peripheral** (such as a payment terminal or beacon).

Details:

1. BLE Payment Flow
   1. Central (Smartphone): The holder's smartphone acts as the **Central** device. It communicates with BLE-enabled peripherals.
   2. Peripheral (Beacon or Payment Terminal)**: The beacon or payment terminal serves as the **Peripheral** device. It broadcasts advertisements or waits for connection requests.
2. BLE Payment Process
   1. Advertisement Phase**:
      1. Nonconnectable Scannable Undirected Advertisements In this type of advertisement, a device (e.g., a beacon) broadcasts data to be discovered by multiple other BLE devices. It does not accept connections. The advertisement packet includes information like the device's Bluetooth address, type, and other relevant data.
      2. Connectable Scannable Undirected Advertisements These advertisements are used by devices that want to accept connections from other BLE devices. When a customer's smartphone detects these advertisements, it can initiate a connection with the peripheral.
   2. Connection Request Phase
      1. The **Central** sends a **Connection Request packet** to the advertising **Peripheral** to initiate a connection. This packet contains essential information for establishing the connection.
   3. Post-Connection Operations
      1. After successful connection, further operations occur, including version exchange messages, feature exchange messages, and attribute discovery (such as GATT services, characteristics, and descriptors).
3. Pros and Cons
   1. BLE
      1. Pros
         1. Near-Frictionless Experience**: Consumers can complete the payment process without manual actions (except for verbal confirmation or identity verification).
         2. Security BLE engages the Secure Element of a smartphone or NFC-enabled payment device, benefiting from mobile wallet application security features.
      2. Cons**:
         1. Infrastructure Overhaul**: Retailers need to update their point-of-sale systems to connect to the beacon network and track customer accounts online.
   2. NFC (Near-Field Communication)**:
      1. Pros**:
         1. Existing Infrastructure**: NFC payments use EMV terminals, requiring minimal changes to existing payment systems.
         2. Short Communication Distance**: NFC transactions avoid signal interception due to their short range.
      2. Cons**:
         1. Customer Action Required**: Customers must actively perform a payment action (e.g., tapping their phone against the terminal).
         2. Not as Rapid as BLE**: NFC isn't as rapid or frictionless as BLE, except perhaps with wearable payment devices⁴.

BLE and NFC offer distinct approaches to contactless payments. While BLE provides a seamless experience for consumers, NFC leverages existing infrastructure and emphasizes security. Retailers can choose the technology that best aligns with their needs and customer expectations⁴.

Source: Conversation with Bing, 3/15/2024

(2) BLE vs. NFC: Mobile Payments | Host Merchant Services. https://www.hostmerchantservices.com/articles/ble-vs-nfc-mobile-payments/
(3) BLE scan request - Nordic Q&A - Nordic DevZone - Nordic DevZone. https://devzone.nordicsemi.com/f/nordic-q-a/77500/ble-scan-request
(4) Bluetooth Low Energy (BLE): A Complete Guide - Novel Bits. https://novelbits.io/bluetooth-low-energy-ble-complete-guide/
(5) How Can Bluetooth Beacons Revamp Contactless Payment. https://www.mokoblue.com/bluetooth-contactless-payment/
(6) Request Benefit Payments - Texas Workforce Commission. https://www.twc.texas.gov/programs/unemployment-benefits/request-benefit-payments sequence diagram

References

Other Material

• See wiki page Secure Payment Confirmation
• See wiki page Payment on Apple