Implementation Considerations and Future Plans

Implementation Considerations

and Future Plans

Dave Raggett

Web Payment IG

18 June 2015, New York

Web Payment WG

● Payment Request from Payee

– Amount, currency and brief description for account statements

● Machine interpretable transaction id to connect payment to commercial transaction

– Which payment schemes the merchant accepts

● Globally registered identifiers for payment schemes

– Additional fees associated with use of particular schemes

● Along with explanations (standard codes?)

– Terms & conditions could depend on payment scheme

– Information on how to pass proof of payment to payee

– Identity of payee in respect to each payment scheme

● Account details and credentials

– Public key for securing messages sent to payee

● Enabling payers to choose how to pay from their available

payment schemes that are accepted by the payee

– Payee does not get to see Payer's payment schemes ● Interaction with payment instrument to authenticate

the payer and for the payer to authorise the payment

– As appropriate to the value and context

● Delivery of proof of payment or description of error to the payee

– Need to address possible failure modes

● What technical constraints are needed to address regulatory concerns?

Selection Agent for choosing

the means of payment

●

Should only present choices to the payer which are applicable

to the current transaction

– Requires simple means to determine applicability

● Matching names of payment schemes, but not a guarantee of compatibility

– There may be additional fees for particular choices

● Higher settlement costs, deferred payments, etc.

– Human readable names and Images for branding of means of payment

●

The payer may want to set preferences to pay with a given

instrument / scheme in particular circumstances

– The merchant, amount, currency, time of day, location, etc.

● Will get even more complicated when we get around to loyalty schemes

– We don't need to standardise how this happens

● Nor how to deal with synchronisation across devices

●

Payers will prefer a seamless experience regardless of

which device or browser they are currently using

●

Implementation choices and their implications

– Hosted web app, locally installed web app, native app, browser extension, or integrated as part of the web browser

Implementation Logic

●

The payment request API should be independent of how

the selection agent is implemented

●

Selection agent could replace the merchant's web page

–

Smart phones, or for native or locally hosted web apps

●

A web app could be passed an IFRAME for integration

within the merchant's web page

–

HTML IFRAME provide security isolation

● IFRAME is passed with the payment initiation API

●

URIs could provide a way to pass info to agent apps

–

Special URI schemes for locally hosted web or native apps

–

A means to pass a message back to originating web page

● Directly via browser and event/callback/promise to originating web page ● Indirectly via a URI and back-end logic on merchant's side

●

Analogy to Android Intents with browser as broker and registrar

Payment Instrument

● Similar implementation choices as for selection agent

– Browser could play valuable role for invoking instruments

● Independent implementation choices for selection agents and payment

instruments (local web/native or cloud based)

– Browser keeps these choices hidden from each other

● Browser or selection agent as registrar for payment instruments?

– Latter better for seamless experience across browsers

● W3C Strong Authentication WG planned for late 2015

– Focus on assuring that this is the same device+user as when the user account with the website was originally set up

● Does not address binding of Web Identity to Real-World Identity

– Use cases and requirements for Payments

● Level of assurance required will depend on the payment instrument and the value of the transaction

– Low value may be sufficient to authenticate device

– Intermediate value with biometric, PIN or gesture

– High value requiring additional factors including specific

requirements on secure hardware

– Use cases and requirements for W3C Hardware-based Web Security WG

● Need for standards for conveying details to authentication API

– And vice versa to provide details on what was used

Value added Services

around Payments

●

For businesses and their customers, economic transactions

are more than just payments

●

Opportunities for addressing pain points and enabling value

added services

●

Examples

–

Making it easy for for business travellers to submit expense claims

–

Making it easier for people to manage their monthly expenditure

–

Making it easier to support tax audits

–

Avoiding the need for paper when returning faulty goods

–

Avoiding the need to fill out forms on small screens

●

Shipping and Billing addresses

Personal information

Receipts

●

Users want track all of their payments without complications

of having to go to each of their accounts

●

Customers need proper receipts, e.g. in case of disputes, for tax purposes,

for corporate expense claims, for value added services and so forth

– Credit card statements are inadequate for these purposes

– Emailing customer receipts is a really bad solution

●

Information relevant to disputes, e.g. for return of faulty goods

– Signed by merchant and customer?

– Machine interpretable plus flexibility for presentation

● Images and other ways to brand receipts, and present them

nicely on a wide range of devices

– Receipts for payments, for declined payments, and for refunds

●

Commercially sensitive so not shared with payment instruments

●

Is the agent that holds receipts the same as the selection agent?

– This would make sense to end users!

– Most people might think of it as their wallet!

– Valued added services that you grant access to your receipts

● Richer machine interpretable data would increase the value of these services

The Bigger Opportunity

●

Economic transactions focussing around the transfer of value

–

Purchasing tickets for a concert

●

Digital tickets

–

Paying for a taxi ride

●

Digital receipt I can present to my employer

–

_{Purchasing a gift card for a birthday present}

●

A paper card or a digital card I can send to my daughter

–

_{Sending a friend flowers}

–

_{Redeeming loyalty points on my Nectar card}

●

Loyalty cards supported by a group of participating businesses

–

Paying for my share of a business dinner

●

Painless fast way to pay for what I ordered and to get a receipt

–

Refunding a customer for one part of a purchase

Where Next?

●

W3C Web Payments Working Group will be focused narrowly

on moving quickly on minimal standards for web payments

●

What about the broader context for payments

– Push payments, subscriptions, reversals

– Offline payments, person to person payments

– Brick & mortar stores and contactless payments

– Pre-authentication of payer on entry to store, etc.

●

What about related standards work on a broader scope?

– Loyalty cards, prepaid vouchers, discount coupons, tickets, itemized receipts with terms & conditions

– Connecting Web identities to Real-World identities

●

Expanded role for Web Payments IG?

– What additional stakeholders need to be involved

beyond those already present in the Web Payments IG?

● Tax authorities

● Value added service providers

● Others?