<!-- Talk about all the innovations that have happened over the last 2 decades because of the internet and how none of them relate to money transfer (except for bitcoin)-->
>The goal is to create a safe, decentralized system and a set of open, patent and royalty-free specifications that allow people on the Web to send each other money as easily as they exchange instant messages and e-mail today.
<!-- : standardizes an API to allow merchants (i.e., Web sites selling physical or digital goods) to utilize one or more payment methods with minimal integration. User agents (e.g., browsers) facilitate the payment flow between merchant and user, mediating the user experience and providing consistency between different merchants and providers. -->
<!-- :defines capabilities that enable Web applications to handle payment requests. The specification defines how Web-based payment handlers register their capabilities with the user agent, how the user agent communicates with them, and what information is exchanged. Note: Based on experience with the Payment Handler API, the Working Group is discussing creation of a new UI component where payments, authentication, and other activities can occur. This functionality would generalize some of the current payment-specific functionality of Payment Handler API. -->
<!-- : allows the curators of a defined payment method or owners of a proprietary payment method to authorize (via a manifest file) which payment handlers may be used to fulfill the payment method. The scope of this work extends to all types of payment handlers, including native mobile apps and Web apps. -->
See [github.com/w3c/webpayments/wiki](https://github.com/w3c/webpayments/wiki) for a complete list
\* working drafts
---
# specifications*
- [Payment Request API](https://w3c.github.io/payment-request/): _how to initiate a payment_
- [Payment Method Identifiers](https://w3c.github.io/payment-method-id/): _what is a payment method?_
- [Payment Method Manifest](https://w3c.github.io/payment-method-manifest/): _definition of a payment method_
- [Payment Handler API](https://w3c.github.io/payment-handler/): _how a payment method is processed?_
<!-- : standardizes an API to allow merchants (i.e., Web sites selling physical or digital goods) to utilize one or more payment methods with minimal integration. User agents (e.g., browsers) facilitate the payment flow between merchant and user, mediating the user experience and providing consistency between different merchants and providers. -->
<!-- :defines capabilities that enable Web applications to handle payment requests. The specification defines how Web-based payment handlers register their capabilities with the user agent, how the user agent communicates with them, and what information is exchanged. Note: Based on experience with the Payment Handler API, the Working Group is discussing creation of a new UI component where payments, authentication, and other activities can occur. This functionality would generalize some of the current payment-specific functionality of Payment Handler API. -->
<!-- : allows the curators of a defined payment method or owners of a proprietary payment method to authorize (via a manifest file) which payment handlers may be used to fulfill the payment method. The scope of this work extends to all types of payment handlers, including native mobile apps and Web apps. -->
Try to understand how we can complete a payment entirely from within your browser _without relying on any proprietary APIs_ (as a processor/merchant), and yet _being compatible with any payment instrument_.
The **payment method**: the means that the payer uses to pay the payee (e.g., a basic card payment). They are uniquely identified via a **Payment Method Identifier** (PMI)
The **payment method provider** establishes the ecosystem to support that payment method.
The details of how to fulfill a payment request for a given payment method is an implementation detail of a **payment handler**, which is a Web application that can handle a request for payment on behalf of the user.
<!-- You want a way to ensure that multiple payment processors work against the same initial payment request. Hence a need to standardize these identifiers. -->
<!-- A payment method should be "discoverable", and that implies a manifest of some sort where a user-agent can find more details about the payment method -->
>allows the curators of a defined payment method or owners of a proprietary payment method to authorize (via a manifest file) which payment handlers may be used to fulfill the payment method.
humanized: defines the "how-to-process" action of a specific payment method. The one for `basic-card` is standardized in a [specification already](https://w3c.github.io/webpayments-methods-card/).
`supported_origins` defines which origins can be trusted to install an application for this payment method.
---
# What's inside a Manifest (1)
```json
{
//...
"supported_origins": [
"https://beta.alicepay.com",
"https://bobpay.com"
]
}
```
A payment application hosted at either `alicepay.com`, `beta.alicepay.com`, or `bobpay.com` is now authorized for the payment method `https://alicepay.com`.
---
# What's inside a Manifest (2)
```json
{
//...
"supported_origins": "*"
}
```
any third party is allowed to support the payment method.
A PaymentManager is an additional attribute to the `ServiceWorker` specification, which allows a piece of code to run/listen in background in your browser, even after the tab is closed.
```
PaymentManager {
instruments = PaymentInstruments {
delete(instrumentKey)
get(instrumentKey)
keys()
has(instrumentKey);
set(instrumentKey, PaymentInstrument details);
clear();
}
userHint
}
```
---
# Payment Instrument
Defines what all different instruments a user might have registered against this method (Multiple wallets, bank accounts, cards etc).
```
PaymentInstrument {
// Visa Card ending in **1214
name;
// Visa icon
icons;
// PMI
method;
// Can be used to restrict card usage by network for eg.
capabilities;
}
```
---
# PaymentHandler API
A payment handler listens on the `PaymentRequestEvent`, and returns a `PaymentHandlerResponse` once done.
- Google Pay is already using Payments API to support cross-platform Payments, by declaring a new "https://google.com/pay" payment method.
- Apple Pay runs in browsers [using the Payment Request API](https://webkit.org/blog/8182/introducing-the-payment-request-api-for-apple-pay/).
- So does [Samsung Pay](https://medium.com/samsung-internet-dev/how-to-take-payments-on-the-web-with-the-payment-request-api-a523f6fc7c1f)
- Payment processors are adding support for it: [Stripe](https://stripe.com/docs/payment-request-api), [BrainTree](https://developers.braintreepayments.com/guides/payment-request/overview), [Worldline](https://blog.worldline.tech/2018/07/25/new-web-standards.html)
- Facebook implements it within their in-app browser for the Mobile SDK.
The "Payment Handler" for most of the above implementations is a close browser<>payment app coupling, with an application such as Samsung/Apple/Google Pay.
---
# Current Status
- All major browser implement Payment Request API to various degrees, primarily for the `basic-card` usecase.
- Payment Handler registration is only supported in Chrome.