Abstract

This document is a prioritized list of Web payments use cases. Guided by these use cases, the W3C Web Payments Interest Group plans to derive architecture and associated technology requirements to integrate payments into the Open Web Platform. That work will form the basis of conversations with W3C groups and the broader payments industry about what standards (from W3C or other organizations) will be necessary to fulfill the use cases and make payments over the Web easier and more secure.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document is a work in progress and is being released early and often using an agile process; it is incomplete.

The Web Payments IG has only had the opportunity to review a handful of the 40+ use cases, 120+ requirements, hundreds of pages of payments research submitted to the group via various other standards group output such as ISO20022, research documents from X9 and the US Federal Reserve, documents from the Web Payments Community Group, and input from the general public. Our desire is to align with the larger payments industry when it's possible to do so. Expect this document to be rapidly iterated upon with that desire in mind.

This document was published by the Web Payments Interest Group as a First Public Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to public-webpayments-comments@w3.org (subscribe, archives). All comments are welcome.

Publication as a First Public Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 1 August 2014 W3C Process Document.

Table of Contents

1. Introduction

ECommerce is thriving and continues to expand. However, fragmentation of payment systems is limiting the growth potential as are problems — both real and perceived — such as fraud and usability.

Because the Web is ubiquitous, strengthening support for Web payments has the potential to create new opportunities for businesses and customers. Mobile devices are already transforming the industry by supplanting physical payment cards in proximity payments, voucher distribution, and identification when people authenticate to a scanner, point of sale, or access gate. Although we are seeing innovation in mobile payment systems, the lack of standards makes it more difficult to adapt to new payment approaches or integrate new payment providers.

The W3C Web Payments Interest Group is developing a roadmap for standards to improve the interoperability of payments using Web technologies for both online and brick-and-mortar (offline) scenarios. This will help achieve greater interoperability among merchants and their customers, payment providers, software vendors, mobile operators, native mobile apps, and payment networks. The roadmap will include payment schemes in use today (such as electronic cheques, credit cards, direct debit, and cryptocurrencies) and those of the future. The roadmap will be derived from the use cases listed below.

1.1 Why This Work is Important

The Web Payments work is not just about making payments easier, faster, more secure, and more innovative. There are many people around the world that today's financial system does not reach. These people are called the world's unbanked (or underbanked). The unbanked often live pay cheque to pay cheque, do not have access to savings accounts or low-fee cheque cashing services, lines of credit, or a way of saving for their future. Being unable to plan for one's financial future often results in a focus on the short-term, which creates a vicious cycle of not being able to escape one's situation. Not being able to participate in the financial system creates unintended inequities that create waste and result in a net loss for society.

However, some of the shortcomings of today's financial system could be addressed via technological improvements. For example, there is a considerable overlap between the unbanked and underbanked population and access to advanced mobile phones and the Web. By providing financial services to people with mobile phones in a standardized way via the Web, we could see an improvement in the financial health of these individuals and their families.

Extending the current financial system to reach further helps an ever increasing number of people plan for their future, focus on the long-term, and thus contributes to a greater net gain for society.

1.2 How this Document is Organized

This document is organized as follows:

Each use case has:

Each use case may also have notes on:

Issue 1

The group seeks input from security, privacy, and accessibility experts. Examples of desired groups to perform these reviews are, but are not limited to: W3C Privacy Interest Group, W3C Security Interest Group, W3C Web Accessibility Initiative and Protocols and Formats Working Group, US Federal Reserve Security Panels, X9 Security subgroups, and ISO security subgroups.

The Interest Group (currently) regards some of the use cases as "essential" to addressing their goals and others as "non-essential."

Note

All character names appearing in this document are fictitious. Any resemblance to real persons, living or dead, is purely coincidental. Some organizations, products, and services appearing in this document are real and are included purely for pedagogic purposes and don't imply endorsement or approval of the Web Payments work in any way, shape, or form. For all other organizations, products, or services appearing in this document, any resemblance to real entities is purely coincidental.

2. Terminology

This document attempts to communicate the concepts outlined in the Web Payments space by using specific terms to discuss particular concepts. This terminology is included below and linked to throughout the document to aid the reader:

entity
A person, organization, or software agent that is capable of interacting with the world.
payee
An entity that receives funds as required by a transaction.
payer
An entity that provides a source of funds as required by a transaction.
payment instrument
A mechanism used to transfer value from a payer to a payee. Examples: Corporate Visa card, personal Visa card, a bitcoin account, a PayPal account, an Alipay account, etc.
payment processor
An entity that submits and processes payments using a particular payment instrument to a payment network. Examples: Stripe, PayPal, Authorize.net, Atos, FedACH.
payment scheme
Sets of rules and technical standards for the execution of payment transactions that have to be followed by adhering entities (payment processors, payers and payees). Examples: Visa, MasterCard, Bitcoin, Ripple, PayPal, Google Pay, Alipay, Yandex money, ACH, SEPA.
purchase
Activities surrounding and including a transaction (e.g., discovery of an offer, negotiation of terms, selection of payment instrument, delivery, etc.).
transaction
An exchange of value (e.g., buying or selling something)
Note

There are a number of financial industry standards (such as ISO20022, ISO12812, various X9 standards, PCI DSS, and others) that define payment terms. The Web Payments Interest Group has as a goal to make use of industry-defined terms in its deliverables. At the same time, the group has as a goal that these use cases may be understood by both payment industry professionals and the broader Web community. Thus, our definitions are simplified and few in number here, but the group is also developing a more complete glossary with detailed definitions and mappings to industry-defined terms.

3. An Overview of the Payment Phases

There are many types of transactions in the world of payments, including person-to-business, business-to-business, business-to-person, government-to-person, person-to-government, and person-to-person. In this document we focus on the interactions between a payer and a payee, either of which could be a person, business, government, or software agent), which we organize into four phases:

Issue 2

The group would like feedback related to the general structure of the payment phases from individuals that worked on ISO20022, ISO12812, the European Payment Commission, and various X9 documents to ensure that the phases reflect business processes outlined in financial standardization initiatives. Feedback from the general public is also requested to see if non-payment professionals can navigate and understand the document without prior payment industry knowledge.

  1. Negotiation of Payment Terms
  2. Negotiation of Payment Instruments
  3. Payment Processing
  4. Delivery of Product/Receipt and Refunds

The descriptions below only discuss the interactions between the payer and the payee. We do not expose the low-level exchanges between banks, card associations, or other back-end "payment clearing" parties in a transaction. Those details will be discussed in the Interest Group's work on architecture and requirements.

Each phase below consists of a series of steps. The details of each step vary by payment scheme. Some steps may not be relevant at certain times (e.g., depending on payment scheme or transaction specifics). For example, some purchases do not involve a proof of funds or proof of hold. ACH and SEPA payment schemes generally do not support the verification of available funds, thus in these payment schemes the particular proof of funds step is skipped. In some cases, steps may happen in a slightly different order than described below.

It is also important to note that these phases and steps may be interrupted at various times (e.g., one party drops out, or exceptions occur like insufficient funds or a regulatory block). While these phases are an approximation of the general flow of all payments, they are helpful in structuring the use cases such that it is easy to figure out to which part of the payment process a particular use case belongs.

While these four phases may apply more or less well to a variety of other payment scenarios such as person-to-person payments, those topics are not the current focus of the group. We plan to address them directly in future work.

3.1 Negotiation of Payment Terms

In the first phase of the payment process, the payer and the payee negotiate the terms of the payment.

3.2 Negotiation of Payment Instruments

In the second phase of the payment process, payer and payee determine which payment instruments the payer will use to transfer funds to the payee.

3.3 Payment Processing

The third phase of the payment process is used to initiate the transfer of funds. Depending on the payment instrument, the transfer of funds may be verified immediately or only after several days.

3.4 Delivery of Product/Receipt and Refunds

In the fourth phase of the payment process, the transaction is completed by providing the payer with a receipt and/or the product that was purchased.

4. A Simple Example of the Payment Phases

The following scenario is provided to aid the reader in understanding how the phases of the payment process apply to a real world situation. In this scenario, we follow Jill, who seeks a new outfit for a party. She selects items from PayToParty, which is a brick-and-mortar store with an online presence. She chooses how to pay and the items are delivered to her home on the following day.

See the appendix for additional examples of the payment phases.

Issue 3

General feedback is requested as to whether or not this section is helpful in grounding the payment phases and steps in a real world use case is helpful this early in the document. An alternative would be removing this section entirely if the preceding section suffices, or moving this narrative to section 7 with other examples.

4.1 Negotiation of Purchase Terms

4.2 Negotiation of Payment Instruments

4.3 Payment Processing

4.4 Delivery of Product/Receipt and Refunds

5. Assumptions

The use cases below rely on a number of assumptions that are not detailed in the use cases but that will be explored in more detail in the architecture and requirements documents.

6. Use Cases

This section examines the phases of payment, and the steps involved in each phase, through a variety of use cases. The purpose of this section is to elaborate on the variety of scenarios present in each step of the payment process.

Issue 4

General feedback is requested related to the general structure of the use case snippets below. Are they focused enough to convey each topic listed? Is there information that should be added to each use case in general? Would more elaborate use cases be helpful? Would an attempt to minimize each existing use further be helpful in scanning the document more quickly?

6.1 Negotiation of Payment Terms

6.1.1 Discovery of Offer

Website
Penny uses the HobbyCo website to select a $15 model train for purchase.
Goals
rapid, widespread adoption.
Motivation
This is the most common type of offer on the Web circa 2015 and is included for the sake of completeness.
Point of Sale Kiosk
Cory shops for groceries at his local ChowMart, scans all of the items he wants to purchase at the automated kiosk, and is presented with a total amount.
Goals
Improved user experience, and rapid, widespread adoption.
Motivation
Unifying POS interaction w/ the Web Payments architecture is vital for the success of this work.
Privacy
Cory should exercise control over how much he wants the merchant to be able to track his activities. Programs like loyalty cards will likely involve agreement to more data with the merchant.
Mobile
Daniel takes a taxi from the airport to his hotel. The taxi driver displays the total with his mobile device and offers a tap-to-pay option.
Goals
Improved user experience, Greater security, Innovation, Automatability, and rapid, widespread adoption.
Motivation
Unifying the way tap-to-pay offers work with the Web Payments architecture would help ensure ubiquity.
Exceptions
No mobile phone connectivity (visiting a different country, trip occurs outside the range of a mobile network, etc.)
Freemium
Ricki plays his favorite native app game and wants to upgrade his avatar with a few extra "power-ups." Clicking on a power-up displays the price.
Goals
Improved user experience, Innovation, and Transparency.
Motivation
Many of the very successful games these days run on the freemium model, but are tied to specific app stores. Providing an app-store agnostic mechanism to pay for items in freemium games would give players and developers more choices.
6.1.1.1 Non-Essential Use Cases
E-mail
A GroupBuyCo customer receives an offer by email to purchase the deal of the day.
Goals
Improved user experience, and Automatability.
Motivation
Unifying how people initiate payments from email, at a Point of Sale, and via a Web site will help ensure the ubiquity of the Web payment technology platform.
Privacy / Security
It is important to recognize that initiating a payment from within an email application could lead to a wholly new category of phishing/fraud.
Hold Funds
Renne checks into a hotel and is asked for a deposit for any damages to the room.
Goals
Improved user experience, Increased user choice, and rapid, widespread adoption.
Motivation
By design, some transactions do not reach completion. Some are merely there to protect the payee (e.g., in the event of questionable judgment by the payer).
Exceptions
Software acting on the payer's behalf may keep track of exactly how much money the payer has and not allow them to process the offer.
Pre-authorization
George pulls up to a pump at a petrol station. His in-vehicle application recognizes the station location and the pump. The pump communicates which fuels it has and their price in an offer. George's car asks if he wants to approve a fill up for up to €35.
Goals
Improved user experience, Greater security, Innovation, Transparency, Automatability, and rapid, widespread adoption.
Motivation
Some offers are not aware of the final price but would rather set limits on the amount of the purchase before a particular metered good or service is delivered.
Privacy
Due to the sensitivity of location data, individuals should be able to make small fuel purchases in a way that respects their privacy.
Security
Automated purchases (e.g,. by a vehicle) should involve increased security (e.g., a second factor of authentication).
Machine Readability
BigBoxCo expresses their entire product catalog online as machine-readable information so that SearchCo may index their content more easily and direct more customer traffic to BigBoxCo's website.
Goals
Increased user choice, Improved user experience, Innovation, Lower Costs, Transparency, Automatability, Portability, Monetization, and rapid, widespread adoption.
Motivation
Machine-readable offers will have a direct positive impact on store sales if they are indexed by search engines.
Live Market Prices
EnergyCo lists barrels of refined oil for sale on their website based on an algorithm that uses the cost of coal and crude oil as inputs. EnergyCo guarantees their prices for up to 24 hours from the posting date.
Goals
Increased user choice, Improved user experience, Innovation, Transparency, and Automatability
Motivation
The ability to express a non-repudiable offer as the basis of a legally enforceable contract will reduce transaction friction.
Trial-ware
Amantha downloads the latest version of her favorite game and beats the first level. The game asks her if she'd like to buy the full game to play further levels.
Goals
Improved user experience, Monetization, and rapid, widespread adoption.
Motivation
There is a fairly large trial-ware industry that could benefit from a simple way of executing a payment without requiring redirection to another site to enter account and payment details.
In-vehicle
Jeff listens to a lot of music on the way to work. The music station serves a digital offer along with the music stream. This enables Jeff to easily buy music that he really likes.
Goals
Improved user experience, Innovation, Monetization, and rapid, widespread adoption.
Motivation
Car manufacturers and the entertainment industry may be interested in extending their sales channels into vehicles.
Accessibility
For safety reasons, the interface used to interact with the digital offer must not distract the driver of the vehicle. Voice controls and other techniques can be used to reduce driver distraction.

6.1.2 Agreement on Terms

Credentials
At times it is necessary to transmit personally identifiable information (e.g., about a qualification, achievement, personal quality, aspect of an entity's background, or verifiable statement by an entity about another entity) in order to be cleared to make a purchase:
  • PharmCo will only sell regulated drugs to someone with proof of an active pharmacist's license.
  • WineCo will only sell wine to someone with proof of being over the age of 21.
  • BoomCo will only ship industrial explosives to a business that can provide evidence of construction permits, a contractor's license, and an explosives handling license.
  • HomeLoanCo will not finalize a quote for a home mortgage without a credit score report and an audited finances report.
Goals
Improved user experience, Greater security, Regulatory acceptance, Innovation, Transparency, Automatability, and Portability.
Motivation
There are certain types of purchases that cannot be initiated without a proper set of credentials. While this isn't fundamental to the payment process, it is an integral part of some transaction processes.
Privacy / Security
It is important that people retain control over when and how their credentials are shared.
Exceptions
A transaction may fail if a required credential is not available.
Privacy Protection
Tibor orders assorted chocolates from CandyCo. CandyCo only needs Tibor's verified shipping address to send him the chocolates. With Tibor's authorization, his payment software transmits only his shipping address to CandyCo. Tibor's privacy is protected from the candy store, which did not require Tibor's name, email address, or any other personally identifying information to complete the transaction.
Goals
Improved user experience, and Greater security.
Motivation
Certain low-value transactions shouldn't require the payer to divulge personal information that is not necessary to complete the transaction.
Privacy
Non-essential, personally identifiable data should be anonymized and protected throughout the process.
Need to Know
PayCo is required to keep a certain amount of information on their customers for anti-money laundering / know your customer regulatory purposes. When a payer performs a transaction with a payee, PayCo would like to reduce the amount of information that's transmitted to the payee while ensuring that PayCo complies with regulations.
Goals
Greater security, and Regulatory acceptance.
Motivation
There are types of information, such as personally identifiable information, that payees do not need to know for some transactions. Limiting sensitive information to be transmitted to entities involved in a payment on a purely need-to-know basis increases security while ensuring regulatory compliance.
One-time Payment
Jamie wishes to pay for a single article from a market analyst.
Goals
Improved user experience
Motivation
It should be clear to a payer whether a purchase is one-time or recurring, prior to initiation of the payment.
Invoices
Will goes to SuperVoices to download a voiceover that he commissioned for his new pet sitting service. SuperVoices generates a detailed invoice for the service and provides it to Will.
Goals
Improved user experience, Greater security, Transparency, Automatability, Portability, and Monetization.
Motivation
For certain payment schemes, the payer will have to provide the payment service with a detailed digital invoice from the payee in order to initiate payment to the payee.
6.1.2.1 Non-essential Use Cases
Subscription
Jeff subscribes to a site that provides a monthly analysis of the world of finance.
Goals
Improved user experience, Transparency, and Automatability.
Motivation
Payers should be able to understand if a particular purchase is a recurring payment prior to initiating the payment.
Registration-less
Some payees would rather not require a payer to register at their site before initiating a purchase:
  • Sven wants to view a pay to read article and does so without needing to pre-register with the website.
  • Reiko finds a blowtorch for sale at a local digital resale website and places money into escrow without needing to register with the website.
  • Benny is listening to music in a local coffee shop and likes a song he hears. He initiates a purchase of the song from the local "music beacon" without needing to register with the coffee shop or the music service.
Goals
Improved user experience, Greater security, Innovation, and Automatability
Motivation
There are a large number of "paywall" websites on the Web that require a customer to register before they may use the website. In many cases, if the site isn't regularly visited by the customer, they abandon the transaction when they see the paywall requirement. Providing a mechanism to sell an inexpensive item to a customer without requiring registration would be of great benefit to not only the merchants selling goods and services, but customers that would like to avoid lengthy registration processes.
Full Disclosure
Marge wishes to renew her passport online which requires transmission of a fee and a great deal of information about her real-world identity.
Goals
Improved user experience.
Motivation
Some transactions will require very sensitive personally identifiable information to be transmitted by the payer.
Privacy / Security
We must ensure adequate security for these highly sensitive transactions to reduce the likelihood of phishing attacks.

6.1.3 Application of Marketing Elements

Coupons
JustPopcorn sends Marco a special discount offer given Marco's past purchases. The offer takes the form of a coupon that may be applied during payment.
Goals
Automatability and Portability.
Motivation
Providing a mechanism to apply digital coupons before a payment is initiated helps price-conscious customers as well as merchants attempting to research price sensitivity.
Loyalty Cards
Terry uses his FoodCo loyalty card when purchasing his weekly groceries, which gives him a discount on gas purchases performed at the FoodCo gas station.
Goals
Improved user experience and Portability.
Motivation
Loyalty cards may be used at multiple locations to effect the price of a particular good.
Store Credit
When Rick arrives as the self-checkout kiosk, he scans five dress shirts and two new pairs of slacks. The kiosk mentions that Rick could save 15% off of his purchase if he makes the purchase using store credit. He accepts the offer and a new store credit card is placed in his payment application on his mobile phone.
Goals
Increased user choice, Improved user experience, Automatability, Portability, Monetization, and rapid, widespread adoption.
Motivation
Merchants often provide discounts to customers if they sign up for a store-specific line of credit.

6.2 Negotiation of Payment Instruments

6.2.1 Discovery of Accepted Schemes

Ubiquitous Schemes
A game store Web site accepts payment via credit card, e-cheque, and operator billing.
Goals
Increased user choice, Improved user experience, Minimal standardization, Lower Costs, Automatability, and rapid, widespread adoption.
Motivation
We have a goal for the Web payment architecture to support existing ubiquitous payment schemes without changes to how they operate.
Emerging Schemes
CrowdFundCo supports Bitcoin, Ripple, Google Wallet, and PayPal.
Goals
Increased user choice, Improved user experience, Minimal standardization, Lower Costs, Automatability, and rapid, widespread adoption.
Motivation
The same mechanism used to support existing payment schemes should also support emerging payment schemes.

6.2.2 Selection of Payment Instruments

Discovery
Yanos has a multiple digital wallets: one on his mobile phone, two in the cloud (but on different websites), and one on his smart watch. Each one has a credit card that he may want to use for a credit card-based purchase.
Goals
Increased user choice, Improved user experience, Automatability, Portability, and rapid, widespread adoption.
Motivation
A payer will most likely use multiple digital wallets over time. It is important to ensure that the wallets that they use are presented to them in a consistent manner across devices.
Privacy / Security
Discovery of digital wallets must be done in such a way as to ensure privacy protection.
Manual Selection
In many cases, the payer will select a payment instrument manually:
  • Marie has credit cards from three different institutions: one for work (from BankA), one personal card (from BankB), and one retail card (from PayCo). She wants to choose the right one depending on the context of her purchase.
  • Claire has one debit card and multiple credit cards from the same bank.
  • Veronique wants to use a cryptocurrency in some cases (e.g., peer-to-peer payments).
  • Seth participates in a loyalty program with his local grocery store and can apply a variety of digital coupons when he visits the store. Is a loyalty card a payment instrument, or a credential?
  • David wants to be able to manually arrange available payment instruments when they are presented to him. Why does this need to be standardized? Isn't this just a part of the wallet UI?
Goals
Increased user choice, Improved user experience, Innovation, Transparency, Portability, and rapid, widespread adoption.
Motivation
There are scenarios, such as the first interaction/use of a payment instrument, where selection of the payment instrument won't be able to be performed automatically.
Automatic Selection
When a payer's personal preferences are known, it becomes possible to make selections for them automatically.
  • Jonny's payment software on his smart watch chooses the payment instrument that will provide him with the biggest cost savings for each purchase he makes throughout the week.
  • PayCo wants Elizabeth to know that if she pays with the debit card preferred by PayCo (because of a lower transaction fee for PayCo), she will benefit from a discount.
  • Whenever Mary shops at BigFreshGrocery she uses the same credit card. She wants payment to happen automatically with that card when she puts her phone near the checkout terminal as well as when purchasing groceries online from BigFreshGrocery.
  • Lalana does not like to scroll. She wants the instruments she uses most often to appear at top of the displayed list of available payment instruments.
Goals
Increased user choice, Improved user experience, Innovation, Lower Costs, Transparency, Automatability, and rapid, widespread adoption.
Motivation
Payment solutions providers can make payments easier and faster through automation.
Payer Privacy
We anticipate a range of privacy scenarios:
  • Lucio sends information about instruments he is willing to use to TrustedMerchant, who provides a discount for access to his information.
  • Carla does not want to share information about the payment instruments she uses with any merchants, so that information is not shared with any online merchants.
Goals
Increased user choice, Improved user experience, Innovation, and Monetization.
Motivation
Sharing or protecting data on the sorts of payment instruments available to a payer should be a decision made by the payer.
Privacy / Security
The types of payment instruments available to a payer could be used to digitally fingerprint a payer even if they were using an pseudo-anonymous payment mechanism. Merchants and payees may be legally obligated to protect this kind of payer payment information.

6.2.3 Authentication to Access Instruments

Multi-Factor
We anticipate a range of authentication scenarios, leveraging a wide variety of approaches and device capabilities:
  • When Ian selects his debit card, he is prompted for a PIN.
  • Wes has configured his debit card to require a fingerprint scan from his mobile device and a Universal Two Factor (U2F) device to be used when performing a purchase over $1,000.
  • Frederic taps his phone at the grocery store to pay, and BankA sends him a one-time password (OTP) on his mobile phone that he enters using a keypad at the checkout counter.
  • Nadia's bank asks her to use her two-factor authentication device and at least one of their in-branch retinal scanners or palm-vein readers before she is allowed to withdraw $25,000.
Goals
Increased user choice, Improved user experience, Greater security, Minimal standardization, Regulatory acceptance, Innovation, and rapid, widespread adoption.
Motivation
The payments architecture should support the authentication devices available today for multi-factor authentication, as well as those of the future.
Accessibility
Not everyone can provide fingerprints or detailed iris scans. Therefore, it is important to offer multiple forms of biometric verification to improve accessibility.
Regulatory Blocks
PayCo must ensure that their customers do not appear on any regulatory blacklists when performing transactions above a certain monetary amount.
Goals
Regulatory acceptance, and Automatability.
Motivation
Easing compliance with Know Your Customer (KYC) and Anti-Money Laundering (AML) regulations will ensure safer and faster payment schemes.
Exceptions
If a payee detects that a payer is on an applicable blacklist, the transaction must not proceed.
6.2.3.1 Non-essential Use Cases
Biometric
In current online and offline payment transactions, biometric authentication can be used instead of password-based authentication:
  • John registers his fingerprint with his payment provider so that he can just use a fingerprint to pay for low-value items.
  • Sarah registers her voiceprint and face with her payment provider for use in transactions greater than $1,000.
  • Rico buys a $5,000 car for his daughter through an online dealership. His payment processor requires a password plus two forms of biometric identification. Rico doesn't have hands, so he uses a face and iris scan to perform the authentication.
Goals
Increased user choice, Improved user experience, Greater security, Minimal standardization, Regulatory acceptance, Innovation, and rapid, widespread adoption.
Motivation
Biometrics can be utilized on Point of Sale terminals, mobile, and wearable devices. Web payment systems based on biometrics could achieve more reliable information security and convenience. Some forms of biometric authentication, like facial recognition, can also be used to augment password-based authentication mechanisms.
Security / Privacy
  • An individual's privacy should be protected when performing any sort of biometric authentication.
  • Important data, such as the fingerprint template and private key, and sensitive code should be stored and executed in a Trusted Execution Environment (TEE).
  • The fingerprint authentication protocol, which is capable of transmitting a proof of fingerprint authentication credential, should not contain any personal fingerprint data.
Accessibility
Not everyone can provide fingerprints or detailed iris scans. Therefore, it is important to offer multiple forms biometric verification to improev accessibility.

6.3 Payment Processing

6.3.1 Initiation of Processing

Note

Before subjecting a person or organization to any financial transaction commitment (such as a web payment), they should be presented with the option of reversing, checking, or confirming their choice or submission. It should also be noted that this does not preclude certain transaction operations from being automated once they have been authorized by an entity. For more details, see the section on Error Prevention (Legal, Financial, Data) in [WCAG20].

Payee-initiated
Some payments are initiated by the payee:
  • Richard choses to pay using a credit card at FlowerFriends. FlowerFriends initiates payment processing using their payment processor to contact the acquiring bank that handles credit card payments for FlowerFriends.
  • Pitir has authorized RentSeekers to pull money out of his bank account on a monthly basis in order to pay his rent. RentSeekers initiates a payment using the ACH network to pull money from Pitir's bank account.
Goals
Automatability, and rapid, widespread adoption.
Motivation
Payee-initiated payments, also known as "pull payments" or "four corner model payments", are widely deployed and utilized today.
Privacy / Security
One of the biggest security flaws of payee-initiated payments is that all the information necessary to initiate a transaction from the payer's financial account is typically transmitted to the payee. For example, credit card information along with expiration date, name, and CVV2 code are transmitted and could be intercepted by rogue software running on the payer's servers. Special attention should be paid to ensuring that this risky security model isn't supported by a Web Payments solution. For example, at a minimum, credit card tokenization such as EMVCo's solution should be supported alongside other tokenization solutions.
Payer-initiated
Some payments are initiated by the payer:
  • Once Sally has signed into PayPal to pay, PayPal initiates payment processing.
  • Joakim uses his Bitcoin wallet to send money to his friend.
  • Carson (in New York City) sends money to Vladamir (in Moscow) using his Ripple client, which converts the currency from US Dollars to Rubels in transit.
Goals
Improved user experience, Greater security, Innovation, and Automatability.
Motivation
Payer-initiated payments, also known as "push payments", "three-corner model payments", or "peer-to-peer payments", are fundamentally more secure as no information is given to the payee that would allow them or an attacker to replay the transaction for a different amount or to a different payee at a later date.

6.3.2 Verification of Available Funds

Hold Verification
Renne checks into a hotel and is asked for a deposit for any damages to the room. She uses her phone to provide a proof-of-hold until she checks out of the hotel, at which time the hold on her funds will be released.
Goals
Improved user experience, and Transparency.
Motivation
Delivering services or products that are difficult to "undo," such as performing an oil change, dispensing fuel, or renting a car or hotel room are examples of situations which may require a two-part transaction.
6.3.2.1 Non-essential Use Cases
Funds Verification
When Mario wishes to purchase a race car through the manufacturer, the company that makes the car requires a proof of funds from Mario's bank in order for the customization of the car to proceed.
Goals
Greater security and Transparency.
Motivation
A payee may want to limit access to certain services to only those who they know can afford the good or service because the act of engaging the payer may be costly.

6.3.3 Authorization of Transfer

Proofs
Goods and services may be released at different times depending on the type of transaction being performed:
  • Zhang Wei orders 10 large boxes of envelopes from an online shop in Tianjin. He uses an escrow service to provide a proof of escrow to the online shop in order to get them to initiate the shipment.
  • To protect Tibor's privacy when he purchases candy online, the store asks only for Tibor's verified shipping address and a proof of payment to send him the chocolates.
  • RockinRadio, SmoothSounds, and classicallyClassic are independent, specialized music streaming services. They accept proof of purchase from each other to provide a track that is in their online streaming catalogue even if it was originally bought from another provider.
Goals
Increased user choice, Improved user experience, Greater security, Regulatory acceptance, Innovation, Transparency, Automatability, and rapid, widespread adoption.
Motivation
At times, it is safe to release a good when the payment network acknowledges that the funds are on their way. At other times, it's not safe to release a good or service until it has been proven that the funds are sitting in the payee's financial account.
Exceptions
If a particular expected proof is not provided, the transaction will most likely fail or transition into an alternate path.

6.3.4 Completion of Transfer

Variation of Delay
When a transaction occurs, the time it takes to transmit and receive funds often vary according to the payment scheme:
  • Sophie uses a credit card to buy some gifts for her parents. The shop has access to the funds in three days.
  • Frank uses an electronic cheque to pay his rent. The rental agency has access to the funds in 7 days.
  • Felicity has chosen Bitcoin to pay for glasses online. The store that sells the glasses has almost guaranteed access to the funds within 15 minutes.
  • Vanessa uses Ripple to purchase a new work outfit in US Dollars. Funds in Euros are available to OnlineWorkClothes within a few minutes.
Goals
Increased user choice, Improved user experience, Transparency, Automatability, and rapid, widespread adoption.
Exceptions
If the funds are sent but never received, then the payee will select a recourse mechanism that is included in the last transaction message.
6.3.4.1 Non-essential Use Cases
Notifications
Gavin sends an electronic cheque to WaveMart. WaveMart receives a notification that payment has been initiated almost immediately. Four days later, WaveMart receives a notification from their bank that payment has been received.
Goals
Innovation, Automatability, and rapid, widespread adoption.
Motivation
It is difficult for an organization to know when a payment has been received without depending on proprietary software.
Exceptions
It may also be important to be notified when a payment that was initiated has not been received, or when a payment has been reversed after it had been received.

6.4 Delivery of Product/Receipt and Refunds

6.4.1 Delivery of Product

Physical Goods
Giralt orders a bicycle for his daughter through BikeSmart online. The bicycle is delivered a few days later with a QRCode attached to the package that only Giralt can access.
Goals
rapid, widespread adoption.
Motivation
The purchase and delivery of physical goods via an online marketplace is one of the cornerstones of online commerce.
Virtual Goods
When Lilith buys music from a band at MusicBox and then goes to their Web site to download additional content, no registration is required, just a proof of purchase that is sent to the band's website, after which MusicBox provides Lilith a link to download the additional content.
Goals
Improved user experience, Greater security, Minimal standardization, Innovation, Automatability, Portability, and Monetization.
Motivation
Delivery of product can happen on any site that accepts a proof of purchase that contains a recognized product identifier.

6.4.2 Delivery of Receipt

Electronic Receipts
George pulls up to a pump at a petrol station. He pays electronically using a credit card (via his phone). An electronic receipt for the purchase from the gas station is displayed on his phone.
Goals
Improved user experience, Greater security, Innovation, Automatability, and Portability.
Motivation
Electronic receipts will make it easier to track expenses, prove that certain purchases were made, file tax returns, and simplify management of unnecessary paper.
Privacy / Security
Many merchants want to ensure that receipts are not readable by any party between them and their customer.
Physical Receipts
Bongani reserves a bus ticket online using his mobile phone. At the bus terminal he taps his phone to a kiosk and receives a printed physical receipt that he can use on the bus.
Goals
Improved user experience, Innovation, Portability, and rapid, widespread adoption.
Motivation
There will be a transition period from the use of physical receipts and tickets to digital receipts. In some cases, physical receipts may never be replaced, so it is important to ensure that digital receipts have a mechanism to be transformed to physical receipts.
Privacy / Security
Physical receipts should ensure that private information is not exposed on the receipt.
Accessibility
Implementations should ensure that people who have visual disabilities have options such as Braille output for physical receipts alongside high-contrast / large print lettering.

6.4.3 Refunds

Common Refunds
At times, it becomes necessary to refund a payer's payment:
  • Pele buys a slice of pizza with a credit card at a local restaurant and is accidentally charged for five slices of pizza. He notices the mistake after he pays and requests a refund, which the restaurant manager approves. The overcharged funds are returned to his account.
  • Teo claims that a blender they purchased online was faulty and returns the product to the merchant. The merchant provides the customer with a refund in the form of store credit based on the return policy.
  • Should we include a scenario where the refund is to a different payment scheme, e.g., cash?
  • A financial crimes regulator identifies a criminal syndicate that is operating via a number of fake identities. The fake identities are flagged and an electronic message is sent to all payment processors to reverse all payments sent to the fake identities.
Goals
Improved user experience, Greater security, Regulatory acceptance, Innovation, Automatability, Portability, and rapid, widespread adoption.
Motivation
Some transactions are the result of human error or fault. In these cases, it is helpful to be able to reverse the transaction and provide a refund to the customer.

7. Additional Examples of the Payment Phases

Early in the document we provide an example of the payment phases. In this appendix we provide further examples to illustrate the phase steps.

Issue 5

Input is requested from experts at each organization providing services mentioned below as well as engineers and designers of technologies used below. Specifically, if the payment flows outlined below contain errors or omissions the group would like to be to ensure that the oversight is corrected as soon as possible.

7.1 Credit Card Payment (Visa, MasterCard)

This scenario outlines a typical card purchase using the 4 corner model. Janet is buying an handbag online from a resale shop.

Negotiation of Purchase Terms

  • Discovery of Offer: Janet searches her favorite resale shop online to discover a gently used purse that she has always wanted.
  • Agreement on Terms: Janet selects the purse and puts it into the shopping cart before others have a chance to buy it. She agrees with the shipping terms and adds an extended warranty for the product.
  • Application of Marketing Elements: At the time of reviewing the shopping cart, she is asked if she would like the scarf which goes with the purse.

Negotiation of Payment Instruments

  • Discovery of Accepted Schemes: The site takes Discover, MasterCard, Visa, and debit cards along with secured money order, Bitcoin, Google Wallet, and ApplePay.
  • Selection of Payment Instruments: Janet selects her Discover points card that highlighted by default because she had used it for a previous purchase with the merchant.
  • Authentication to Access Instruments: The merchant asks Janet for her zip code and the verification code on the back of the card.

Payment Processing

  • Initiation of Processing: The merchant initiates an payment authorization request to their payment processor.
  • Verification of Available Funds: The payment authorization request is successful and the payment processor sends a response to the merchant acknowledging that the funds are now held until the merchant finalizes the payment.
  • Authorization of Transfer: After the merchant has packed the bag for shipping, the merchant sends a message back to the payment processor to finalize the payment.
  • Completion of Transfer: The funds are immediately deducted from Janet's line of credit. The funds take 3 days to be transferred to the merchant's bank account.

Delivery of Product/Receipt and Refunds

  • Delivery of Receipt: The seller sends her a digital receipt, which she receives by email and directly to her digital wallet. Her digital wallet forwards the receipt to her budgeting software. The digital wallet forwards the tracking number embedded in the digital receipt to her MyUPS Shipping Tracker mobile application.
  • Delivery of Product: The merchant's shipping department packs and delivers the bag to the shipper, which then sends it to Janet.

7.2 Tokenized Payments (ApplePay / Venmo / CyberSource)

The following scenario outlines payment using a mobile device and tokenization. The merchant has provided a mobile application that customers can download in the example below. This example may apply to various tokenization payment systems now in use, such as ApplePay, CyberSource, Venmo, Square, etc.

Negotiation of Purchase Terms

  • Discovery of Offer: Tom uses the Terrific-Tools mobile app to select a new ax to purchase and finds a hickory handled model like the one his father had.
  • Agreement on Terms: Tom selects the ax, which is in the price range he wanted.
  • Application of Marketing Elements: Not applicable to this particular use case.

Negotiation of Payment Instruments

  • Discovery of Accepted Schemes: The mobile app uses tokenized payment instruments and the Terrific-Tools Application displays the options available.
  • Selection of Payment Instruments: Tom chooses to pay with his tokenization-enabled MasterCard.
  • Authentication to Access Instruments: Tom uses the fingerprint recognition feature of his device to authenticate his payment.

Payment Processing

  • Initiation of Processing: The mobile app creates an encrypted transaction and sends it to the payment processor. The payment processor decrypts the information and processes the transaction.
  • Verification of Available Funds: Not applicable to this particular use case.
  • Authorization of Transfer: The payment processor responds back to the mobile app with an approval.
  • Completion of Transfer: The payment processor sends a transaction receipt to Terrific-Tools.

Delivery of Product/Receipt and Refunds

  • Delivery of Receipt: Terrific-Tools sends a transaction receipt to the mobile app.
  • Delivery of Product: Terrific-Tools, Inc. ships the ax to Tom.

7.3 Three Corner Model Payments (PayPal / Alipay / Google Wallet)

The following scenario outlines an ideal payment experience using a payer-initiated payment, also known as a "push-payment" or "three corner model payment". In this scenario, Anna is buying an airline ticket from a booking website and during the payment process she uses her fingerprint instead of a password to authorize the payment.

Negotiation of Purchase Terms

  • Discovery of Offer: Anna searches for a flight on the booking website. She finds a flight for the ideal price and time.
  • Agreement on Terms: Anna selects the flight and agrees to the terms and service associated with the ticket.
  • Application of Marketing Elements: Not applicable to this particular use case.

Negotiation of Payment Instruments

  • Discovery of Accepted Schemes: The booking website takes Alipay, Visa, MasterCard, and China UnionPay for payment.
  • Selection of Payment Instruments: Anna chooses Alipay for payment.
  • Authentication to Access Instruments: Anna logs in the Alipay with her account name and password. Anna is told that she will pay for the airline ticket with 600RMB and she confirms it. Anna uses her fingerprint to approve the payment.

Payment Processing

  • Initiation of Processing: Anna's Alipay wallet initiates the transaction.
  • Verification of Available Funds: Not applicable to this particular use case.
  • Authorization of Transfer: Alipay initiates the payment to the booking website based on Anna's prior fingerprint-based authorization.
  • Completion of Transfer: The booking website gets a message from Alipay that the transfer is complete.

Delivery of Product/Receipt and Refunds

  • Delivery of Receipt: The booking website sees that Anna's airline ticket order has been paid and sends a receipt message to her digital wallet.
  • Delivery of Product: The booking website sends an email to Anna with the flight information including the airline, flight number, departure time, and gate number.

7.4 Cryptocurrency Payment (Bitcoin, Ripple)

The following scenario outlines an ideal payment experience using Bitcoin, or a Bitcoin-like cryptocurrency. In this scenario, Lenne is buying a pair of alpaca socks from an online retailer using a "buy one, get one free" coupon. The socks are shipped to her home address.

Negotiation of Purchase Terms

  • Discovery of Offer: Lenne searches for "warm socks, locally sourced" in her favorite search engine. A pair of Alpaca socks come up as the first hit as the Alpaca's are nearby where she lives and the online store (AlpacaToesCo) provides local delivery. She has a coupon in her digital wallet for the store, but forgot long ago that it is there.
  • Agreement on Terms: Lenne goes to AlpacaToesCo and puts the socks in her online shopping cart and is shown the price. Lenne provides her shipping address to AlpacaToes.
  • Application of Marketing Elements: When Lenne puts the socks in her online shopping cart, she's reminded of the "buy one, get one free" coupon she has in her wallet. She adds another pair of socks and continues with the checkout process.

Negotiation of Payment Instruments

  • Discovery of Accepted Schemes: The website takes Visa, Ripple, and Bitcoin for payment.
  • Selection of Payment Instruments: Lenne has a Visa card as well as a local Ripple wallet and a cloud-based Bitcoin wallet. Lenne selects her cloud-based Bitcoin wallet.
  • Authentication to Access Instruments: Since the value of the payment is less than $50, Lenne isn't asked for her two-factor authentication device to approve the purchase.

Payment Processing

  • Initiation of Processing: Lenne's cloud-based Bitcoin wallet provider initiates the transaction.
  • Verification of Available Funds: Not applicable to this particular use case.
  • Authorization of Transfer: AlpacaToesCo is sent a message from the Bitcoin cloud wallet notifying them that the transfer has been initiated. Lenne is told that she will receive a notification when the item is shipped.
  • Completion of Transfer: AlpacaToesCo gets a message from the Bitcoin cloud wallet that the transfer is complete. A Bitcoin transaction ID is included in the message so that AlpacaToesCo can release the product when the appropriate number of verifications are made on the transaction.

Delivery of Product/Receipt and Refunds

  • Delivery of Receipt: AlpacaToesCo sees 6 verifications on the transaction in the Bitcoin blockchain and sends a receipt of sale to Lenne's cloud wallet. The store notifies Lenne that they have shipped her package.
  • Delivery of Product: AlpacaToesCo ships the package of socks to Lenne and she receives them the next day.

7.5 Electronic Cheque Payment

To be completed.

7.6 Credit Transfer / Direct Debit

To be completed.

A. Future Work

B. Acknowledgements

The editors wish to thank the participants of the Web Payments Interest Group for discussions about and contributions to this document, as well as the Web Payments Community Group for earlier work that informed this document.

C. References

C.1 Informative references

[WCAG20]
Ben Caldwell; Michael Cooper; Loretta Guarino Reid; Gregg Vanderheiden et al. Web Content Accessibility Guidelines (WCAG) 2.0. 11 December 2008. W3C Recommendation. URL: http://www.w3.org/TR/WCAG20/