Organizing Web Payments Use Cases
Copyright © 2015 W3C ® (MIT, ERCIM, Keio, Beihang)
Organizing Web Payments Use Cases
- 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.
- 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)
- An exchange of value (here, "Funds").
- Activities surrounding and including a Payment (e.g., discovery
of an offer, negotiation of terms, selection of Payment Instrument(s), delivery, etc.).
The source of funds in a Payment. In this deck, primarily a Consumer.
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.
- 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
- Selection Context (Payer-side, Payee-side)
P3: Initiation of Processing
- Payer-initiated processing
- Payee-initiated processing
P3: Verification of Available Funds
- Proof of Funds
- Proof of Hold
P3: Authorization of Transfer
- Proofs / Guarantees
- Of Payment
- Of Instrument (Hold/Possession)
- Of Funds in Escrow
- Of Funds Transfer by Payment Processor
- Immediate Access to Funds
P3: Completion of Transfer
- Delay Variation
- Nearly immediately (e.g., credit card since brand assumes risk, PayPal, Ripple, Bitcoin)
- After several days (e.g., 3-7 for ACH, SEPA)
P4: Delivery of Receipt
- Frequency variation
- One-time digital proof of purchase
- Recurring receipts after recurring payments
Steps Without Use Cases (in this deck)
Complementary Materials for Payment Professionals
- 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).
Next Steps if Supported
- Framework becomes introduction
- Use cases organized under steps
- Some may be combined, reworked
- Need to add annotation about priority
- Develop complementary materials
- One flow or multiple?
- Template for use cases, including role of conditions, and expressing different points of view.
- Input of Transfer Terms (amount, currency, Payee identity)
- Negotiation of Payment Instruments (bitcoin, mpesa, wechat)
- Funds Transfer
- Acknowledgment of Transfer (aka the receipt)
- Goal: Ensure data used according to various agreements among parties? E.g.:
- What person purchased may be sensitive and that information need not be part of processing
- Loyalty schemes are responsibility of merchant not payment instrument provider
- Customer may not wish to share customer's list of instruments with merchant
- In the architecture, decouple services (value added v. payments) protect data