diff --git a/webpayments/index.html b/webpayments/index.html index 3d93596..9719f18 100644 --- a/webpayments/index.html +++ b/webpayments/index.html @@ -14,7 +14,7 @@ (RFCs We Love, May 2020)

-
+

whoami

-
+

webpayments

@@ -30,8 +30,9 @@
-
+

W3C

+
  • ActivityPub
  • CGI
    • @@ -47,12 +48,12 @@
-
+

demo

Before we start, let's do a quick demo of how it all comes together.

-
+

why?

    @@ -63,8 +64,9 @@
-
+

specifications*

+ @@ -85,7 +87,7 @@

* working drafts

-
+

specifications*

-
+

Agenda

+

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.

-
+

Definitions

+

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.

-
+

Examples

payment method: Paytm Wallet Account, UPI, Card, Gift Card, Voucher Code, Bitcoin.

Payment Method Identifier: https://paytm.com, https://npci.org.in/upi, basic-card

payment method provider: Razorpay, Stripe, PayPal, NPCI/UPI, your-bank-goes-here

-
+

ecosytem overview

-
+

-
+

Flow

-
+

-
+

Payment Method Identifier

+
  • URL-based payment method identifier (say, https://bitcoincore.org/ or https://pay.wechat.com).
  • or a standardized payment method identifier (currently only basic-card is on the registry).
    • @@ -139,15 +144,16 @@

    humanized: how to identify and categorize various payment methods?

-
+

Payment Method Manifest

+

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.

-
+

How to get to the manifest?

GET / HTTP/2
 Host: alicepay.com
@@ -158,7 +164,7 @@
 
You can alternatively just redirect from your PMI URL, or serve the JSON directly on the PMI URL

 
 
-

+

 
What's inside a Manifest?

 
A payment method manifest tells the user-agent "how to process payments for a particular method".

 
URL: https://alicepay.com/pay/payment-manifest.json

@@ -172,13 +178,23 @@
 
 
 

-

+

+
Google Pay's Payment Method Manifest

+
curl -A "AppleWebKit/1 Chromium/1 Chrome/1" https://pay.google.com/gp/p/payment_method_manifest.json

+
{
+  "default_applications": ["https://pay.google.com/gp/p/web_manifest.json"],
+  "supported_origins": ["https://pay.google.com"]
+}
+

+
+

+

 
what happens?

 
user-agent can go next to https://alicepay.com/pay/app/webappmanifest.json to install the AlicePay application.

 
supported_origins defines which origins can be trusted to install an application for this payment method.

 
 

-

+

 
What's inside a Manifest (1)

 
{
   //...
@@ -191,7 +207,7 @@
 
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)

 
{
   //...
@@ -201,7 +217,27 @@
 
any third party is allowed to support the payment method.

 
 
-

+

+
Google Pay's Web Manifest

+
Not part of the webpayments spec

+
URL: https://pay.google.com/gp/p/web_manifest.json

+

+
{
+  "short_name": "Google Pay",
+  "name": "Google Pay",
+  "icons": [{
+    "src": "https://www.gstatic.com/instantbuy/icons/gpay_24.png",
+    "sizes": "24x24"
+  },{
+    "src": "https://www.gstatic.com/instantbuy/icons/gpay_32.png",
+    "sizes": "32x32"
+  }],
+  "serviceworker": {
+    "src": "/gp/p/service_worker.js",
+    "use_cache": true
+  }
+}
+

 
recap

 
So far, the user-agent has done the following:

 
    
@@ -214,7 +250,7 @@
 
    The application installation is based on W3C's Web App Manifest specification.
    
 
 

-

+

 
What's inside the Payment Handler?

 
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 {
@@ -231,7 +267,7 @@
 

 
 

-

+

 
Payment Instrument

 
Defines what all different instruments a user might have registered against this method (Multiple wallets, bank accounts, cards etc).

 
PaymentInstrument {
@@ -247,7 +283,7 @@
 

 
 

-

+

 
PaymentHandler API

 
A payment handler listens on the PaymentRequestEvent, and returns a PaymentHandlerResponse once done.

 
PaymentHandlerResponse {
@@ -262,9 +298,9 @@
 

 
 

-

+

 

-

+

 
Payment Handler

 
Each payment handler defines:

 
    
@@ -282,7 +318,7 @@
 
 
 

-

+

 
Payment Request API

 
PaymentRequest interface

 
id
@@ -300,7 +336,7 @@ onpaymentmethodchange
 

 
 

-

+

 
Native Applications?

 
You can declare support for native applications via a few non-standardized changes to the payment method manifest:

 
{
@@ -318,14 +354,15 @@ onpaymentmethodchange
 

 
 

-

+

 
Native applications (2)

 
Instead of using service-workers now, your payment application can rely on platform-specific APIs for the same purpose. Android uses Intents, for eg.

 

 
 

-

+

 
In the Wild

+
 
    
 
  • 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.
    • 
@@ -336,7 +373,7 @@ onpaymentmethodchange
 
    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.
    • 
@@ -344,15 +381,16 @@ onpaymentmethodchange
 

 
 

-

+

 
Future Scope

 
    
 
  • Installing a payment app is clunky, maybe we can just install the service-worker directly.
    • 
 
  • Lots of work happening towards standardization of non-card payments (such as SEPA, Tokenized Cards, credit-transfer).
    • 
+
  • Getting the drafts published as a W3C recommendation
    • 
 

 
 

-

+

 
Questions?

 
    
 
  • Tweet to me @captn3m0
    • 
@@ -360,17 +398,18 @@ onpaymentmethodchange
 

 
 

-

+

 
References

 
 
 

 
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)
Bitcoin exists, and Amazon has been around for more than 2 decades, why do we need web payments?
: 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 the validation and (where applicable) registration of identifiers used for matching purposes by other W3C payments specifications.
: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.
- [Payment Request API](https://w3c.github.io/payment-request/)
: 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.
- [Payment Method Identifiers](https://w3c.github.io/payment-method-id/)
: defines the validation and (where applicable) registration of identifiers used for matching purposes by other W3C payments specifications.
- [Payment Handler API](https://w3c.github.io/payment-handler/)
: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.
- [Payment Method Manifest](https://w3c.github.io/payment-method-manifest/)
: 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.
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)
W3C is the internet-standards-body for the World Wide Web. You've likely used lots of their standards
Bitcoin exists, and Amazon has been around for more than 2 decades, why do we need web payments?
There are 4 published standards (all in draft stage) and a few more auxiliary publications from W3C's Web Payments Working Group
: 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 the validation and (where applicable) registration of identifiers used for matching purposes by other W3C payments specifications.
: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.
- [Payment Request API](https://w3c.github.io/payment-request/)
: 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.
- [Payment Method Identifiers](https://w3c.github.io/payment-method-id/)
: defines the validation and (where applicable) registration of identifiers used for matching purposes by other W3C payments specifications.
- [Payment Handler API](https://w3c.github.io/payment-handler/)
: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.
- [Payment Method Manifest](https://w3c.github.io/payment-method-manifest/)
: 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.
While removing propreitary stuff isn't a goal for the specs, it is a byproduct.
We'll be going bottomsup, and looking at the smallest building blocks first.
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
Is this available?