This a proposed framework for organizing the
material in the Web Payments Use Cases Draft, which will help establish the scope of work for the Web Payments Interest Group.
It is initially for discussion by the Use Cases Task Force.
Goals
Introduce a simple payment processing framework
so that all readers understand how (a subset of)
use cases relate to
one another and how, together, they represent a
logical sequence of payment activities.
Reveal where we may be missing
use cases; we may either fill gaps or explain them.
Associate closely related stories to highlight their differences, and ensure they do not overlap in scope.
Use the framework as a starting point and create complementary materials tailored to payment professionals.
Scope of This Model
This model focuses on the interactions between a person
(or organization) and a merchant.
This model does not intend to address the exchanges between
bank, card associations, or other back-end parties in a Payment.
We do not yet have enough feedback to determine whether we should have multiple specific models or a single very general model
Key Terminology (1)
Payment
An exchange of value (here, "Funds").
Purchase
Activities surrounding and including a Payment (e.g., discovery
of an offer, negotiation of terms, selection of Payment Instrument(s), delivery, etc.).
Payer
The source of funds in a Payment. In this deck, primarily a Consumer.
Payee
The recipient of funds in a Payment. In this deck, primarily a Merchant.
Key Terminology (2)
Payment Scheme (also just "Scheme")
A set of rules and technical standards for the execution of Payments that have to be followed by Payers, Payees, and the institutions that support them. Examples: Visa, Mastercard, Bitcoin, PayPal, ACH, SEPA.
Payment Instrument (also just "Instrument")
A mechanism that follows a particular Payment Scheme. Examples: corporate Visa card, personal Visa card, a bitcoin account, a PayPal account.
Payment Processor
The entity (or entities) that carry out the Payment according to the relevant Scheme. Examples: Stripe, Authorize.net, Atos, FedACH.
Four Phases
Negotiation of Purchase Terms
Negotiation of Payment Instruments
Payment Processing
Delivery of Product/Receipt
Note: The phases may be interrupted at various times (e.g., one party drops out, or exceptions occur like insufficient funds, refunds, or a regulatory block). We will describe exceptions separately.
Note: We used "Product" here since shorter than "Goods and Services"
Each Phase Has Multiple 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).
Some steps may happen in a slightly different order in some cases.
Example: Some, but not all, purchases
involve a proof of funds or proof of hold.
Example: ACH and SEPA Payment Schemes generally do not support
Verification of Available Funds.
Steps for Negotation of Purchase Terms
Discovery of Offer. Payer discovers Payee offer (e.g., by browsing a Web page or from a native application).
Agreement on Terms. What will be purchased, for how much, in what currency, authentication of Payer by Payee, etc. Payee may generate invoice.
Application of Marketing Elements. Payer discovers and applies to the Payment any loyalty programs, coupons, and other special offers.
Steps for Negotation of Payment Instruments
Discovery of Accepted Schemes. Payment Schemes accepted by the Payee. May vary by Payer (and Payer's Instruments).
Selection of Payment Instruments. Choice from among the intersection of Instruments available to Payer and accepted by Payee.
Authentication to Access Instruments.
Payment Instrument issuer authenticates Payer, who consents to pay.
Note: This authentication with Payment Processor is distinct from any authentication required by the Merchant (e.g., via user account).
Steps for Payment Processing
Initiation of Processing. Depending on Payment Instruments, the Payer (e.g., when using PayPal), the Payee (e.g., when using a credit card), or other party (e.g., bank) initiates processing.
Verification of Available Funds. Payee may need proof of funds or proof of hold before finalizing payment and delivery of the product.
Authorization of Transfer. Payee receives proof that the transfer of funds has been authorized.
Completion of Transfer. Payment Scheme(s) determine details of clearing and settlement, and transfer times (immediately to days).
Steps for Delivery of Product/Receipt
Delivery of Product. Payer receives goods or services immediately, at a later date, automatically on a recurring basis, etc. depending on the terms of the purchase.
Delivery of Receipt. Depending on the Payment Scheme(s) chosen, there are various ways and times that a receipt may be delivered from the Payee.
Phases and their Steps Summary
@@Diagram to be updated since now have more phases and steps@@
Each Step Has Multiple Use Cases
Each use case is about a single topic, described by different but related scenarios.
The following slides show ways to organize existing use cases.
For readability "P1:" stands for "Phase 1: Payer Initiates Payment" and so on.
Note: Both prioritized and non-prioritized use cases shown to illustrate model. We can show prioritization through annotations.
P1: Discovery of Offer
Different Contexts
From a Web site
Within a mobile application (Web, Native, or Hybrid) such as an in-app payment.
P1: Agreement on Terms
Degrees of Knowledge about Customer Identity
Payer must share real world identity
Payer must share some (possibly virtual) identity
Payer is pseudonymous (e.g., through token)
Frequency Variation
One-time payment
Subscription / recurring purchase (with fund limits)
Machine-readable negotiation.
P1: Application of Marketing Elements
Parametric for recommended instrument.
P2: Selection of Payment Instruments
Manual selection
Number of Payment Agents
Number of Payment Instruments
Coupon and Non-Coupon cases
P2: Selection of Payment Instruments (Continued)
Assisted Selection
Transaction fee optimization
Default / automatic selection of Payment Instrument
Preferential display of Payment Instrument options
Detailed descriptions of flows of different
payment schemes in terms of the framework to show
how it applies.
Where the industry is using similar models (e.g., ISO 20022) it will be useful to show how this framework relates. If the framework relates closely, we should consider using existing industry models.
Relation of architecture to regulatory requirements (e.g., solutions that do not prevent compliance).