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.
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:
-
Section 2 defines basic payment terms.
-
Section 3 describes a common payment flow at a high
level. The group expects to work on additional
payment flows in future work.
-
Section 4 is a specific narrative, labeled according
to the steps of section 3. Section 7 describes
additional familiar narratives to give a more complete picture
of how the payment phases apply.
-
Section 6 lists the use cases - short scenarios that cover
diverse aspects of each payment step.
Each use case has:
-
A title and short description.
-
Goals. How the use case advances one or more of the
goals
for an interoperable Web payments framework.
-
Motivation. This is commentary to help explain why the use
case has been included, including how it relates to similar use cases.
Each use case may also have notes on:
-
Security/Privacy. Security or privacy issues that may arise through this use
case.
-
Exceptions. Considerations in the case of specific exceptions (e.g., if a
user pays with a voucher and the transaction fails, the user's voucher
should be restored).
-
Accessibility. Accessibility considerations (e.g., in multi-factor
authentication, management of biometrics in the case of users with some
disabilities).
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.
-
Negotiation of Payment Terms
-
Negotiation of Payment Instruments
-
Payment Processing
-
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.
-
Discovery of Offer. The payer discovers the
payee's offer (e.g., by browsing a Web page or
from a native application).
-
Agreement on Terms. The payer and the
payee agree to what will be purchased, for how much,
in what currency, which payment schemes
or loyalty programs are acceptable, etc. The payee may require the
payer to authenticate themselves. The payee may generate an
invoice for the payer.
-
Application of Marketing Elements. The payer
discovers and applies any loyalty programs, coupons, and other special offers
to the payment terms.
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.
-
Discovery of Accepted Schemes. The payer
discovers the payment instruments that
are accepted by the payee.
-
Selection of Payment Instruments. The payee
selects one or more payment instruments
that are available to the payer and are accepted by the
payee.
-
Authentication to Access Instruments. The
payer's access to the payment instrument
is authenticated. The payer consents to pay. Note: This authentication
with the payment processor is distinct from any authentication required
by the payee (such as when a merchant requires a customer to
have an account and log in to the merchant's Web site).
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.
-
Initiation of Processing. Depending on the
payment instrument, the payer (e.g., when using
PayPal or Yandex Money), the payee (e.g., when using a credit card), or other
party (e.g., bank) initiates processing.
-
Verification of Available Funds. The payee may
need to provide a proof of funds or a proof of hold to the payer
before finalizing payment and delivery of the product.
-
Authorization of Transfer. The payee receives
proof that the transfer of funds has been authorized.
-
Completion of Transfer. The payment scheme
determines the details of payment clearing and settlement. Transfer times
may vary from near-realtime to multiple days. The payee,
the payer, and/or third parties (such as regulatory bodies) may be
notified as each stage of the clearing and settlement process is completed.
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.
-
Delivery of Product. The payer receives goods or
services immediately, at a later date, automatically on a recurring basis,
etc. depending on the terms of the purchase. A digital proof of
payment may be required to access the product.
-
Delivery of Receipt. Depending on the
payment scheme(s) chosen, there are
various ways and times that a receipt may be delivered (e.g., credit card
receipt, digital proof of purchase, encrypted line-item receipt, etc.).
-
Refunds. At time exceptions may occur (e.g., defective
product, application of store return policy, etc.). In this case, the
payee initiates payment to the payer. The refund may
take different forms, including a refund to the payer's
payment instrument, a refund using a different payment scheme, or store credit.
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
-
Discovery of Offer: Jill begins her purchase at
home on her laptop, where she browses the items on the PayToParty Web
site. On the way to work the next morning, she explores the catalog
further from a native app on her smart phone. Jill can't decide
whether the dress displayed online is blue with black stripes or white
with gold stripes, so during her lunch break, she drops into the
PayToParty store near her office. She spots a few more items that
she thinks she'd like to purchase, but decides to wait until later to
make the purchase.
-
Agreement on Terms: That same evening at home,
Jill logs into her account on the PayToParty Web site, adding her
preferred items to her shopping cart. The total price appears on the
page.
-
Application of Marketing Elements: As Jill prepares to
check out, PayToParty offers her a discount of 10% if she uses the store's
loyalty card to pay.
4.2 Negotiation of Payment Instruments
-
Discovery of Accepted Schemes: Given where Jill lives,
PayToParty offers her payment by credit card, debit card, the PayToParty
loyalty card, and PayPal, but not Jill's favorite cryptocurrency (which she
uses on other sites).
-
Selection of Payment Instruments: Jill pushes the "Pay Now to Party!" button and is presented with a number of options to pay, including her
credit card, her PayToParty loyalty card (which is highlighted to remind her
of the discount), and a PayPal account. There is also a gift card from
PayToParty that she received for her birthday, but she chooses not to
use it for this purchase.
-
Authentication to Access Instruments: Jill selects
the PayToParty loyalty card, which she enabled with theft-protection,
and is asked to input a code that is sent to her phone before the
purchase can be completed.
4.3 Payment Processing
-
Initiation of Processing. PayToParty receives a
message from Jill's device authorizing the payment. PayToParty
submits the message to their payment processor, requesting a
proof of hold for the funds.
-
Verification of Available Funds. PayToParty
receives a proof of hold on Jill's funds for the purchase price of
the goods. The PayToParty night-shift employees begin packing her purchased
items for delivery the next day.
-
Authorization of Transfer. Once Jill's package is ready to
go, PayToParty exchanges the proof of hold for a proof of payment by
re-submitting the request to the payment network. They receive a proof of
payment from the payment processor.
-
Completion of Transfer. Since Jill's PayToParty loyalty card
operates as a credit card, PayToParty will receive the funds in their normal
end of week settlement.
4.4 Delivery of Product/Receipt and Refunds
-
Delivery of Receipt. Jill's cloud-based wallet
receives a detailed line-item digital receipt for the purchase.
-
Delivery of Product. Jill's package goes out by courier the
next morning and is on her doorstep before she leaves for work.
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.
-
Connectivity. Connectivity requirements vary according to
use case. The types of connections a device may utilize include Internet
connectivity, proxied connections through short-range radio transmissions,
and proximity connections over a technology such as Near-Field Communication
(NFC) or Bluetooth Low Energy (BTLE). Some use cases assume no
connectivity (e.g., user is temporarily unable to connect to a mobile phone
network or a WiFi hotspot).
-
Registered Payment Instruments. In order for the
payer to select and utilize
payment instruments, they must be
registered in some way and discoverable by a browser, native application,
or other software.
-
Security. Keys, encryption, and other security technology
must be used to secure sensitive information. It is important that sensitive
information is not transmitted to parties that do not absolutely need to
know the information in order to complete the transaction.
-
Identity. There will be a consistent, interoperable
identifier used to identify the participants and accounts in a Web Payments
transaction.
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
- Automatic Tax Payment
- Person to Person Cash Payment
- Government Entitlement Disbursement