Business Processes

ISO20022 has catalogued business processes that are useful in developing and categorizing use cases. (TBD)

It might be best to categorize the use cases per business area.

Business Area	BA Code	Description
CARD PAYMENTS
Acceptor to Acquirer Card Transactions	caaa	Use Cases that support any card payment related transactions and services between a card acceptor and a card transaction acquirer. It includes the authorisation, cancellation and capture of card transactions
Acquirer to Issuer Card Transactions	cain	Use Cases that support any card payment related transactions and services between a card transaction acquirer and a card issuer. It includes the authorisation, reversal and financial presentment of card transactions.
Sale to POI Card Transactions	casp	Use Cases that support any card related transactions and services between a sale system and a Point of Interaction (POI) system.
ATM Card Transactions	catp	Use Cases that support any card related Automated Teller Machine (ATM) transactions and services between an ATM equipment and an ATM acquirer. These services include cash withdrawals, kiosk functions and card account management transactions
Card Administration	caad	Use Cases that support any card related administrative services between financial institutions and their agents.
POI Management	catm	Use Cases that support card related terminal management services between a Terminal Management System (TMS) and a Point of Interaction (POI).
ATM Management	caam	Use Cases that support card related terminal management services between an Automated Teller Machine (ATM) and an Acquirer.
Card Clearing and Settlement	cacs	Use Cases that support the clearing and settlement processes for card payment transactions between financial institutions
Fee collection	cafc	Use Cases that support the reporting and advising of card payment transactions, including the collection of fees and processing of charge-backs.
PAYMENTS & CASH MANAGEMENT
Payments Initiation	pain	Use Cases that support the initiation of a payment from the ordering customer to a financial institution that services a cash account and reporting its status.
Payments Clearing and Settlement	pacs	Use Cases that support the clearing and settlement processes for payment transactions between financial institutions.
Cash Management	camt	Use Cases that support the reporting and advising of the cash side of any financial transactions, including cash movements, transactions and balances, plus any exceptions and investigations related to cash transactions.
Payments Remittance Advice	remt	Use Cases that support communication between creditors and debtors regarding remittance details associated with payments.
MISCELLANEOUS/GENERIC
Account Management	acmt	Use Cases that support the management/maintenance of account related activities
Administration	admi	Use Cases - Generic like messages, i.e., system event notifications, generic rejections, service offline, etc…
Authorities	auth	Use Cases that support the provision of miscellaneous financial information to authorities, such as Regulators, Police, Customs, Tax authorities, Enforcement authorities, Ministries, etc.
Reference Data	reda	Use Cases that support the communication of reference data related to financial instruments, parties, accounts, prices and other business information required to support financial activities.

High Level Categories

To aid in discussion, the following categorizations may be useful. Each use case may apply to one or more of these categories:

• Endpoints – Consumer (payer), Merchant (Payee), Government
• Basic Payment vs. “Semi-Integrated”
• Online vs. Offline
• Card present vs. Card not present
• Pull-payment vs. Push-payment

Roles

In creating the use cases, a standard set of actors, or Roles must be used. These terms should be standardized as far as is possible.

Status

Use Cases that we should try and approve at the face-to-face (at a high level, understanding that there will be clarifications that need to be made):

• Digital Receipts / Proof of Payment (high)
• Refunds and Reversals (high)
• Registration-less Purchases (medium/high)
• Non-interactive Purchases (high/low)

Use Cases fully reviewed and ready to be considered for FPWD inclusion:

• Pseudo-anonymity (high)
• Offer of Sale (medium)
• Parametric Offers (low)
• Coupons and Loyalty Cards (low)

Use Cases that have not been fully reviewed yet (needs discussion):

• Payment Links
• Transaction Fee Optimization
• Choosing the Attributes of Price
• App-Store Purchases
• In-App Purchases
• Payment Tokenization
• Subscriptions
• Offline Purchases
• Digital Wallet Portability
• Real-time Regulatory Reporting
• Escrow
• Pre-paid

Use Cases already moved to FPWD document:

• Purchase Request (high)
• Push-based Payments (high)
• Choice of Payment Instrument (high)
• Pre-authorization with Completion (medium)

Use Cases

Please see the Web Payments CG Use Cases 1.0 document.

Status: Reviewed at the f2f 2014-10-28. Some brief comments are recorded below.

Purchase Request

A buyer selects a product or service to purchase on a website. The website generates a payment request that is sent to the buyer's payment processor for processing. [Purchase? or Payment Request?... Is there any payment information in the request? either about the Pmt Instrument to use? either about payee's data?]

Examples

• Customer POV: Penny logs into the HobbyCo website, providing her payment processor credential in the process. Penny selects a model train for purchase. The store generates a payment request which is then forwarded to her preferred payment processor.
• Merchant POV: A FarmCo customer selects a 10 kg bag of grass seed for purchase. FarmCo performs a few database lookups to determine the current market price of grass seed and generates an invoice for the purchase of the selected product. The invoice is transmitted to the customer's Payment Agent, which then transmits the invoice to the customer's payment processor for processing.
• Payment Processor POV: A PayCo customer receives a payment request to send funds to RetailCo. Upon approval by the customer, the transmission of funds are initiated from the customer's financial account to RetailCo's financial account.

Details

All payments start somewhere and they typically follow the same basic flow: 1) a payer requests a product or service, 2) the payee advertises the final price for the product or service, and 3) the payer initiates payment to the payee. This use case explores the initiation of a payment from the customer, merchant, and payment processor perspectives.

A payment request contains all of the details necessary to perform a purchase including: 1) the requested products or services (this is optional), 2) the exchange value (price) for the products/services, 3) the acceptable payment instruments, and 4) a cryptographically verifiable signature on the important data in the request. The payment request is an extensible, cryptographically verifiable, self-contained document that can be used interchangeably with any payment processor.

Requirements

• A messaging format that can encapsulate a list of goods and services being sold and the current value required to acquire the goods and services.
• The messaging format should be extensible (e.g. Linked Data, JSON-LD).
• The messaging format should be cryptographically verifiable (e.g. via digital signatures, PKI).
• The messaging format should enable the receiver of funds to specify acceptable payment instruments.
• A protocol that is capable of transmitting the payment request from the origination point of the payment request to the payer's payment processor.
• A protocol that is capable of discovering the payer's payment processor(s).
• A protocol that is capable of discovering the payer's payment instrument(s).

Priority

Enter a priority (low, medium, high, critical) and your name beside it below:

• high - This is the mechanism that initiates a payment. It is the entry point into the payment ecosystem we're developing. -- manu

Reviewers

Nitin, Manu

Feedback

• This use case mentions "forms of tender." We need to investigate.
  • The use case mentions "payment instruments", which can be an assortment of credit card, debit card, ACH, wire transfer, stored value, two-phase payment, cryptocurrency, etc. -- manu
    • Does this mean that the payee will/wants/may restrict the scope of Payment Instruments the payer can use? On the one hand, is it really possible and desirable? On the other hand, it could require to determine and make clear for payer what will be the conditions : card payment generally doesn't add a fee for the payer but other payment instruments could; the payer must be aware of this. -- jean-yves
• Regarding the "Payment Processor POV" - there's really no such thing when it comes to payment instruments like Bitcoin/Ripple? -- manu
  • I have a similar question bout the statement: 'The payment request can be used interchangeably with any payment processor'. I'm uncertain about how it could work: to be sufficient the P Request must include payment data concerning the payee ; if encrypted data is readable by any potential buyer, it will be difficult to include sensitive data ; if access to these sensitive data are restricted to PSP's, keys must be shared with them and "there's really no such thing when it comes to payment instruments like Bitcoin/Ripple" and most of the P2P payment solutions.
• [ADDRESSED] Perhaps we need to break this into two use cases - an offer (of sale, to transact, etc.) and a request for payment (request of funds, invoice, etc.) -- manu
• [ADDRESSED] We need to make sure the payment request format is extensible (extensible in market verticals as well as extensible wrt. future versions of the payment request standard) -- manu
• [ADDRESSED] This is a data format, not a protocol, we should be clear about the distinction between data formats and protocols. We will need both, but the format and the protocol should be able to be decoupled as much as possible. -- manu
• [ADDRESSED] This requires a payment processor discovery mechanism (if we're going to create an interoperable ecosystem). How are the preferences transmitted from the payment agent to the merchant/payee? -- manu
• Under "details" above (highlighted), it says: "A payment request contains all of the details necessary to perform a purchase including: 1) the requested products or services..." While itemization of the purchase may be agreed between a merchant and payment processor, it is not at all universally accepted.
  • the itemization may also be something that the merchant doesn't want the payment processor to see. For example, Walmart mentioned during the first face-to-face that they didn't want an organization like Google mining their product transactions w/ their customers. The bill of sale might be something that needs to be out of band or encrypted specifically to the user. -- manu
  • While the itemization is a piece of pass-through data. The payment processor doesn't need to handle the information (they just need to preserve it). The target of the information is the customer (and the merchant). Each will use the information for their own tracking/proof purposes. -- manu
• I tend to restrict the definition for payment to what comes towards the end of the purchase activity - when the payee states a price and conditions. If the payment actually is one connected with a purchase, I'd always consider the receipt being given (perhaps including an itemized list if applicable) as the final element of that process. I wouldn't include the actual 'shopping experience'. What is the view of the authors on the scope? -- joerg

Offer of Sale

A merchant creates an offer of sale and posts it on their website in a machine-readable format. A software agent scans the merchant's website and detects the offer of sale. The offer of sale is either a) immediately acted upon by way of a payment request, or b) cataloged by the software agent so that other buyers may discover the offer through means other than the merchants website (such as a search engine).

Examples

• Customer POV: Carl performs a search for affordable mattresses via QuicSearch, which scours the Web for deals across a variety of product categories. QuicSearch is able to provide excellent results for Carl from a variety of small, local vendors because of the machine-readability of the offers of sale from those vendors.
• Merchant POV: ArtisanBeds is a company that specializes in hand-looming mattresses using only the finest cashmere. They mark up their locally made mattresses in a machine-readable offer of sale format and place the markup on their website, enabling purchases of their bedding to be advertised and initiated off-site. This helps them compete on the same playing field as the large mattress companies.

Details

While the payment request is the first part of the payment transaction process, how does the buyer discover the merchant in the first place? Discovery of goods and services on the Web is something that is still largely driven by broad keyword searches. Marketplace matchmaking services would benefit greatly by having a standardized, machine-readable format for the description of goods and services that are for sale.

Requirements

• A Web-native data format that can express a goods and services being sold and the current value required to acquire the good or service.
• The data format should be extensible (e.g. Linked Data, JSON-LD).
• The data format should be cryptographically verifiable so that products and prices could be trusted by a buyer even if the product was displayed off-site (e.g. via digital signatures, PKI).
• The data format should be capable of expressing the payee's accepted payment instrument(s).

Priority

Enter a priority (low, medium, high, critical) and your name beside it below:

• medium - This would be very interesting to software systems like Payment Agents and/or search companies that would scour the Web looking for deals on behalf of their users. The SEO folks would have a field day w/ this feature. -- manu

Reviewers

Manu, Katie, Chaals

Feedback

• [ADDRESSED] This use case was split out of the Payment Request use case since it would come first in the process.
• chaals: This is essentially a generalisation of what e.g. automated share-trading systems do.
• chaals: The requirement for an extensible format needs to be a must, and that in addition it should be machine-processable.
• jean-yves : The data format should be capable of expressing the payee's accepted payment instrument(s). Will this include sensitive payment data about the payee ? Who will be able to read it: PSP's? any off them? only the one the merchant is linked with? Or any potential payer?

Payment Links

A developer can create a link with a specific payment URI scheme or rel-type such that when a buyer clicks on it, the buyer's payment processor starts the payment process.

Examples

• Gus is a web developer and creates a donation link on his website. He inserts a <a href="payto:bitcoin:3782436823487?message=Donation">Donate</a>

link in the web page markup such that when someone clicks the "Donate" link, a payment will be initiated using the payer's payment processor.

Details

A new payment protocol would enable a new type of hyperlink on the Web that would be specialized for payments.

Requirements

Many questions :

• is the "PL" just an invoice ? or does-it includes pieces of informations about payment sensitive datas ?
• Who will be the PSP ? the payee's one ? the payer's one ? Any of them ?

Priority

Enter a priority (low, medium, high, critical) and your name beside it below:

• High (Jean-Yves)

Reviewers

Jean-Yves, Erik

Feedback

• For security reason the payment intend should always be triggered (or at least signed to be verified) by a merchant. The software developer is a only a technical mediator. -- pascal
• Wouldn't rate this one higher than 'medium'. -- joerg
• The link needs to include a 'statement of acceptence' (in IdM we'd call it 'relying party requirements'), in my eyes this would mitigate the question for the PSP. - joerg
• Does following the link "start payment" or could it trigger another (user-configurable) component to complete the payment? --Wendy
• (Ian) There are Web architecture issues here (see URIs, Addressability, and the use of HTTP GET and POST.
  • We almost certainly not propose a new URI scheme.
  • Do not publish URIs that lead to state changes when dereferenced with HTTP GET
  • On the Web this can be done with buttons in forms (using HTTP POST).

Choice of Payment Instrument

When a payee intends to make a payment, they are given a choice to pick among the intersection of the payment instruments they have available to them and the payment instruments that are accepted by the merchant/payee.

Examples

• Daniel wants to pay the taxi fare with his credit card. The cab company promotes the payment via its web site which offers, on Daniel's smartphone, to chose between several instruments offering different payment means: 1) the basic credit card (Visa, MasterCard, etc.) channel; 2) or an indirect aggregators (PayPal, Google checkout); 3) or the personal wallet detected as available on Daniel's phone.
• Amantha downloads the latest version of her favorite game. It's only a couple of euros that she'd like to pay on top of her telecom operator's bill. The game store web site accepts payment via credit card and operator billing. Amantha selects the "operator billing" payment option.

Details

• Each payment instrument is registered with a set of attributes in order to filter, sort, and display them.
• Each payment processor is registered and 'subscribes' to a the payment instrument it is able to provide.
• Each merchant provides a list of acceptable payment instruments.
• Over time, each buyer iteratively builds a list of preferred payment instruments for their commonly used merchants.

Requirements

• The browser and the host are able to negotiate a payment instrument with respect to their preferences and support capabilities.

Priority

Enter a priority (low, medium, high, critical) and your name beside it below:

• high - This is one of the key pieces that is needed to enable a competitive landscape wrt. payment instruments. -- manu

Reviewers

• Laurent, Nitin, Pascal, Manu

Feedback

• [ADDRESSED] Begs the question "what, exactly, is a payment processor." - Payment processor is a technical tier that handles the payment process as mandated by the merchant or the acquirer bank(s) -- pascal.
• [ADDRESSED] The user should be able to pick his/her favorite payment instrument from those appropriate for the transaction (as posted by the payee). I think this one is agreed. What seems to be new here is, that the payee can make a statement about discounts or other goodies offered when using a specific instrument. Right? -- joerg
  • [ADDRESSED] I think this use case was written before we settled on payment instrument negotiation as the thing that's negotiated (and not payment processor). When we said "payment processor" here, I think what we were really talking about was "credit card" vs. "paypal" vs. "Google Wallet". The first is an instrument, the latter were considered "payment processors", but we could also categorize them as "payment instruments", and that's probably the better way to go at the problem. The "discounts/goodies" use case is handled in the coupons/loyalty cards use case, so I think we should keep that separate for now. I'm going to go back through and re-word this to be about "choice of payment instrument". -- manu

Parametric Offers

A merchant advertises different details, such as price, for an offer of sale based on potential payment processor or payment instrument choice.

Examples

• Customer POV: Harry is prompted for payment at a local supermarket. If he chooses to pay with the supermarket branded card, he can receive “buy one get one” pricing on several items in his transaction. His payment application displays the valid payment instruments available to him, and the total price for the transaction using each one. He chooses the supermarket branded card, and the discount appears on his electronic receipt as a discount.
• Customer POV: Sue buys bedsheets at a well-known website online. If she pays with a gift card from the targeted merchant, she will receive 20% off the listed price.
• Brick/Mortar Merchant POV: A customer presents items for purchase and selects a payment instrument. The merchant's system determines that discounts apply to a combination of items in the sale when using this payment instrument. The discount is applied.
• Web Merchant POV: (same as Brick/Mortar Merchant, since the "ECR" is the website.)
• Payment Processor POV: a payment processor receives a request for payment along with a list of the items in the sale. The payment processor determines that one product is due a discount. The payment is approved for the discounted amount along with advice on why the amount was reduced. (N.B. the request may have come from either a merchant or a customer.)

Details

There are at least two ways this use case can be implemented:

1. If computing of discounts is to happen through an ECR like device, each (payment processor/payment instrument) tuple requires a unique and universal codification so that it can be identified and handled in the ECR. This might be way too complicated.
2. If computing of discounts happens through the payment processor (i.e. the connection is through the merchant) then there must be agreement that sharing transaction details with the processor is OK. This agreement is not a "given."

Pricing databases (either merchant or payment processor) must be able to identify which items qualify for discounts and for how much. Also, patterns of items (like for BO-GO above) must be codified, which may not be possible for the payment processor.

Requirements

• Access to a database with discount information.
• A way to identify each possible payment method, like assigning a URI to each one so that it can be recognized.

Priority

Enter a priority (low, medium, high, critical) and your name beside it below:

• Low - David E.

Reviewers

• David, Mountie

Feedback

• The description of this use case implies an ECR like functionality that is able to pair purchases with methods of payment. Several IG members questioned how such information could be shared.
• “one item one discount” can be easy to apply, but merchants tend to want to apply marketing principles to these transactions, and the patterns of use (any two of these kinds of items, etc.) can become quite complex – David E.
• If the group decides to implement this use case, it might be useful to split the “web site” vs. “ECR” scenarios.

Coupons and Loyalty Cards

A payee can associate a membership card, coupon, or similar token with a transaction to receive a discount or other benefits.

Examples

• Customer POV: Cory shops for groceries at his local ChowMart. When he starts the checkout process via the automated kiosk, the machine asks him to tap his phone to transmit his ChowSavingsCard info to get discounts on items he's purchasing. He taps his phone, selects his card and taps his phone again to transmit the card information to the kiosk, which shows him how much of a discount he is receiving because of the card.
• Merchant POV: ChickenHut requests loyalty cards from frequent customers in order to provide discounts. When customers tap their phone, a cryptographically verifiable token that was issued by ChickenHut is transmitted from the phone to the point of sale device and verified for authenticity.

Details

Coupons and loyalty cards are two discount mechanisms that may be used by a customer before performing a final payment. While coupons and loyalty cards vary wildly in their associated benefits, a merchant or manufacturer must ensure that each one is authentic. In order to ensure the authenticity of a coupon, loyalty card, or information stored therein, it is important that all information is cryptographically verifiable. It is also important for the point-of-sale devices to be able to add information to the locally-stored loyalty cards for use in off-line scenarios.

Requirements

• A data format for expressing a coupon.
• A data format for expressing a loyalty card.
• The data format should be extensible (e.g. Linked Data, JSON-LD).
• The data format should be cryptographically verifiable (e.g. via digital signatures, PKI).
• A protocol for transmitting the coupon or loyalty card from the payer to the payee.
• A protocol for adding cryptographically verifiable information to a loyalty card.

Priority

Enter a priority (low, medium, high, critical) and your name beside it below:

• medium/low (this is probably a part of the payment instrument negotation? We have some work in the credentials group that can be applied here) -- manu

Reviewers

• Nitin, Manu

Feedback

• Rather than make this a part of the payment agent, we should make it a part of the credentials exchange process. A loyalty card/coupon seems to be more like a credential than a payment instrument. -- manu
• [ADDRESSED] The payment processor POV doesn't need to be included in the examples because discounts/coupons are a negotiation between the customer/merchant? -- manu
• [ADDRESSED] What about offline use cases? -- manu
• User tests showed that users expect the use of loyalty and coupons will be integrated into the payment process and won't require additional actions. As the issuers and merchants, however, want to be recognized, we allowed the user to 'prime' the wallet with applicable cards and coupons. This can be perfectly done with virtualized cards (even the payment card) and even be automated on the client side (e.g. if we know where the user is located now or has logged into a certain place). The discrete use of individual cards and coupons should not be touched by this.

Proposal: have a new scenario for compound payment at POS. (BTW: this should be possible for online purchases too) -- joerg

Pseudo-anonymity

Leveraging variable degrees of pseudo-anonymity per requirements of the payment transaction.

Examples

• Customer POV: Tibor orders 3 pounds of assorted chocolates from an online candy store. The store only needs Tibor's verified shipping address and a proof of payment to send him the chocolates. The verified shipping address and the proof of payment are made in a single request to Tibor's Payment Agent and both are delivered to the online candy store. 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.
• Merchant POV: An online candy store gets an order for 3 pounds of chocolate. The store requests a verified shipping address and a proof of payment from the customer in order to send the goods. After receiving both, the store ships the goods to the customer, not exposing themselves to any risk of accidentally leaking their customer's personal information of payment data.
• Payment Processor POV: PayCo is required to keep a certain amount of information on their customers for anti-money laundering / know your customer regulatory purposes. When a customer performs a transaction with a merchant, they would like to reduce the amount of information that's transmitted to the merchant while ensuring that they stay compliant with regulations. This enables the customer to stay pseudo-anonymous when dealing with merchants, but ensure that law enforcement have recourse in the event of illegal activity.

Details

Protecting an individual's privacy when performing transactions on the Web is an important concern. This use case attempts to ensure that transaction privacy is a fundamental part of any Web-based payment mechanism.

Requirements

• A payment protocol that is capable of transmitting a proof of purchase that does not contain any personally identifiable information.
• A credential protocol that is capable of transmitting the minimum aspects of an entity's identity, such as a shipping address, or e-mail address, to complete a transaction.

Priority

Enter a priority (low, medium, high, critical) and your name beside it below:

• high - privacy should be a founding principle for the Web Payments work. -- manu
  • +1 -- jean-yves

Reviewers

Katie, Manu

Feedback

• [ADDRESSED] Could you clarify pseudo-anonymity ? -- pascal
  • [ADDRESSED] pseudo-anonymity means that a certain aspects of a person/entity's details are hidden from the merchant/payee in the transaction. We don't say "full anonymity" because that's currently impossible to claim on the Web/Internet. With respect to law enforcement/regulation, it's also very difficult to do and stay compliant. So, the payment processor or law enforcement can always discover who is paying, but the merchant/payee doesn't necessarily have to know much about the buyer/payer. -- manu
• why not call this use case 'payment untrackable to payee'? 'Pseudo' could be in so many ways 'a bit of anonymity'... -- joerg
• in many countries some payment instruments can be used anonymously (in the EU with §34 PSD "low-value payment instruments and electronic money", for individual payment transactions that do not exceed EUR 30) -- jean-yves
• "pseudo-anonymity" terminology is confusing. "partially blinded" or "private" payment would be more descriptive and clearer. --Wendy

Transaction Fee Optimization

A buyer discovers an offer for sale by a merchant under terms that the merchant is comfortable with. The offer includes a list of payment processors that the merchant is capable of receiving payment through. The buyer's software contacts a subset of those payment processors that they are capable of sending payment through to get finalized transaction details (such as price or speed) before executing the most desirable transaction.

Examples

Details

Requirements

• A messaging format that can encapsulate an offer being sold and the current value and currency required to acquire the offer.
• The messaging format should be extensible (e.g. Linked Data, JSON-LD).
• The messaging format should be cryptographically verifiable (e.g. via digital signatures, PKI).
• The messaging format should enable the receiver of funds to specify acceptable payment instruments.
• A protocol that is capable of reading this selection and of discovering the payer's payment instrument(s) and the payer's payment processor(s).
• A protocol that is capable of choosing the best (lower) fee for the payer.
• A protocol for transmitting the payment order to the selected payee's PSP.

Priority

Enter a priority (low, medium, high, critical) and your name beside it below:

Reviewers

Katie, Jean-Yves

Feedback

• this Use case seems to me quite similar to Purchase request -- jean-yves

This use case would be the responsibility of the payment agent to know exact or approximate fees that might apply.

Choosing the Attributes of Price

Payee and payers negotiate secure price in an open market. They are free to choose all three essential attributes of the numeric quantity expressing a price (e.g. 10.99), namely: a unit-of-account (e.g. $ £ € ¥ etc.); a medium-of-exchange (e.g. debit card, credit card, web payment etc.); and, a value-in-exchange benchmark (e.g. WM Reuters Spot Exchange; Purchasing Power Parity; Commodity Index; etc.)

Examples

Details

Requirements

Priority

Enter a priority (low, medium, high, critical) and your name beside it below:

Reviewers

Erik, Mountie

Feedback

Several members of the group suggested that merchants may want to constrain the options

Currency exchanges (in real time) will need to be tied to an index. How will that be accomplished?

This use case appears to operate somewhat like "Ripple."

Suggest using this use case for information only by the IG.

"medium-of-exchange" should be harmonized with use of "payment instrument". - David E.

• IMHO, a currency can't be described as a unit of account : since the end of gold standard, there is no other way than to determine and to inform the payer and the payee how conversion will be done, and the price paid shall be converted according to due conditions -- jean-yves

App-Store Purchases

A buyer uses a native non-browser application on their mobile phone or tablet, or a web browser to make a purchase at an app store.

Examples

• Customer POV: Dave selects to buy the latest version of “Vampire Crush” for his smartphone. The app-store provides details of payment methods available. Dave selects his normal credit card (tokenized) for payment.

Details

It is not clear that this use case is at all different from any other purchase using a web server.

Requirements

Priority

Enter a priority (low, medium, high, critical) and your name beside it below:

• Low - David E.

Reviewers

David, Manu

Feedback

• Is this use case is enough different from any online purchase from a web site to warrant separate treatment?

Offline Purchases

A buyer can approve a payment while offline and have the merchant deliver the payment to the payment scheme/network at a later time.

Examples

Details

Requirements

Priority

Enter a priority (low, medium, high, critical) and your name beside it below:

Reviewers

Chaals, Evan

Feedback

In-App Purchases

A buyer makes a purchase from within an application for premium content, virtual goods, or subscriptions.

Examples

Details

Requirements

Priority

Enter a priority (low, medium, high, critical) and your name beside it below:

Reviewers

Katie, Stephane, Laurent

Feedback

Payment Tokenization

Temporary payment tokens for merchants. If token is stolen, thief does not get access to financial account. Tokenization mechanism that protects the buyer and merchant from theft of credentials.

Examples

• Ellen wants to buy a book she finds, but does not know whether to trust the merchant with her credit card details. Instead, her normal transaction processor gives her a pre-paid "credit card" valid for the amount of the transaction.
• From a PSP's POV : Tokenization could be a solution to the problem of mobile payments where there is no network available
• From a merchant's POV : Tokenization could be a solution to manage recurring payments by credit card, alleviating the burden to be PCI compliant, if they keep only record of a token, instead of sensitive payment data.
• From a consumer's POV: Tokensization is a solution to deliver value added fidelity services (e.g. the "card linked offers")

Details

Requirements

Priority

Enter a priority (low, medium, high, critical) and your name beside it below:

• Very much depending on what tokenization is used for (jean-yves)

Reviewers

Jean-Yves, Stephane

Feedback

One goal of web payments is that "no breach at a merchant should harm a customer."

Registration-less Purchases

The buyer goes to a merchant website and clicks a buy button to complete a purchase without having to go through any registration process. During the purchase the buyer chooses which information to share with the merchant which the merchant then uses to uniquely identify the buyer if they perform any repeat purchases.

Examples

• Customer POV: Lilith finds a song that she really likes through one of her favorite music blogs. Without registering with the blog, or the artists website, she initiates a purchase and is sent to the artist's website to show the proof of purchase and download the song. At no point did Lilith have to register for a user account, enter her credit card number, or email address.
• Merchant POV: A proof of purchase for a song is shown to a merchant website. The proof of purchase is validated and the merchant website provides a download for the customer.

Details

There are a large number of "paywall" websites on the Web that require registration to use. 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.

Requirements

• A Web-native data format that can express a proof of purchase / digital receipt.
• The data format should be extensible (e.g. Linked Data, JSON-LD).
• The data format should be cryptographically verifiable so that merchants can be certain that funds have or will be transferred and that the receipt is valid.
• A data format for expressing credentials that may need to be a part of the delivery of a proof of purchase. For example, a proof of purchase coupled with a shipping address.
• A protocol for requesting a proof of purchase from a payer.
• A protocol for delivering a proof of purchase to a payee.
• A protocol for transmitting credentials that works in concert with the delivery of a proof of purchase.

Priority

Enter a priority (low, medium, high, critical) and your name beside it below:

• medium/high - This is something that'll drastically smooth the purchase friction online. If you don't have to create an account, or one is created for you automatically, then a large barrier to purchasing is removed from the Web. -- manu

Reviewers

Manu, Erik

Feedback

• On first reading this sounds like a requirement for the payment agent to operate automatically. -- ?
• Actually, I think this is the most elementary payment function to be provided (like in the real world). Should be good for direct downloads and 'paywalls'. --joerg
• This is also a big credentials use case, and that community is working on the details of how this should work. I suggest we engage them to figure out if we can offload this work to a credentials group at W3C. -- manu

Push-based Payments

When a customer wants to make a purchase, the merchant presents the customer with an electronic invoice which in turn can be presented to a payment processor. The payment processor then provides a validated proof-of-payment to the merchant.

Examples

• Customer POV: John goes to CandyCart.com and clicks “buy” to purchase chocolates. John is redirected to the CandyCart.com’s payment processor's website which presents him with a payment UI. John completes the purchase, and is redirected to CandyCart.com’s website, to which he can now post a digital receipt confirming the purchase.
• Customer POV: Francis purchases items in a local novelty store. The store system notifies his mobile application what methods of purchase can be used, and also sends his mobile application an electronic invoice for the transaction. The mobile app presents Francis with options for payment, and Francis chooses to pay with his tokenized credit card. The token and invoice are sent to the payment processor from the mobile app. The payment processor responds with a signed proof of payment electronic document.
• Merchant POV: A customer scans or clicks 5 items to purchase. The merchant system presents an electronic invoice (either total only or with a breakdown of the transaction), including the merchant's identifier, to the customer's device. The customer's device returns a digest of the invoice, having been created with the payment processor's private key.
• Payment Processor POV: A customer sends an electronic invoice, including the merchant and customer identifiers, to the payment processor. The payment processor checks the customer and merchant for validity, posts the requested amount to the merchant's acquirer, which returns a digest on the merchant/customer/amount/time tuple for proof of payment. The payment processor then returns a signed digest of the invoice plus the acquirer digest proving payment to the customer's device, which it in turn posts to the merchant system to prove payment.

Details

For this use case, the customer asks the payment processor for payment directly, preventing the need for sensitive customer information to be shared with the merchant, keeping the merchant out of "PCI scope." No direct communication between merchant and payment provider is required for this use case. It may be possible to create an electronic receipt format that satisfies the requirements for this use case as well as others.

Requirements

• All acquirers must have an available public key.
• All payment processors must have an available public key.
• All merchants must have a global identifier.
• All customers must be recognized by the payment processor.

Priority

Enter a priority (low, medium, high, critical) and your name beside it below:

• High - David E.

Reviewers

David, Stephane

Feedback

• This use case is extremely important, in that it promises to define new "rails" for payment exchange.
  • +1, I'd say this is in the top 3 most important use cases this group could work on -- manu
• I have reorganized the description to be less biased. – David E.
• The original description (now the first example) is very vague on how things happen. - David E.
• It might be possible for a “signed proof-of-payment” to be identical to an “electronic receipt.” - David E.
  • The intent with the original text (and the Web Payments CG) was to make those terms interchangeable. I think we settled on "digital receipt" (aka proof-of-payment, electronic receipt) -- manu
• Who issues the merchants' "global identifier"? is it registered or discoverable? --Wendy
• what does "recognized" mean for "customers must be recognized by the payment processor"? --Wendy

Subscriptions

A buyer visits a merchant's website and initiates a payment. Their payment processor presents them with an option to subscribe to a merchant's product or service, which will result in periodic payments at a known value to the merchant.

Examples

Details

Requirements

Priority

Enter a priority (low, medium, high, critical) and your name beside it below:

Reviewers

Erik, Katie

Feedback

• The general description doesn't seem to be general enough, uses terms that are too specific like 'buyer', 'payment processor', 'merchant'. -- Manu
• Payment processors are generally not associated with a buyer, instead they're associated with a merchant. -- Laurent

Non-interactive Purchases

A payer visits a payee's website and initiates a payment. The payer's payment processor presents them with an option to assign a pay-as-you-go token with a specific spending limit (and/or other limitations) for future purchases with the payee. An option is also presented to require the display of a receipt when a purchase occurs (and/or other interactions), or to perform the purchase in the background with no interactive purchase process required.

Examples

• Customer POV: Yanos visit's his favorite financial news site, which requires articles to be purchased if the customer does not have a subscription. Yanos initiates a purchase. The website, in the payment request, requests a multi-use payment token from Yanos' payment processor to spend up to $15 a month on Yanos' behalf when he purchases certain for-pay articles. Yanos' payment processor asks him if he would just like to perform a one-time purchase, or grant the payment token to the news site. Yanos doesn't want to be bothered to approve a $0.50 purchase, as he does many of them on the website, so he authorizes the initial payment and also authorizes the multi-use payment token. The multi-use payment token is delivered to the financial news site along with proof-of-purchase for the initial article he intended to buy.
• Merchant POV: An online video game company following a freemium business model would like to enable in-app purchases for their content. In order to do so, they would like to request a multi-use payment token from their customer. They enable a button in their game that requests a multi-use payment token and when a customer approves it, the company stores it in their systems. The multi-use payment token is only good for 3 months and has a spending limit that is set by the customer.
• Payment Processor POV: A payee's payment processor receives a request for a multi-use payment token from a payer via the payee's device. The payment processor ensures that the details of the payment token are acceptable to the payee, enables them to add constraints to the payment token, and upon approval, grants a unique identifier for the payment token to be returned to the merchant. The payment token is always linked between a payer's source account and a payee's destination account such that the theft of the payment token does not result in the ability of the thief to move money from the payer's source account to an arbitrary payee.

• This seems to be more like a different sort of payment instrument than performing a non-interactive purchase? -- manu - Alice bought some books on nihil.com. She received a "discount e-voucher" for an amount of x% of her actual payment, identified by a Unique Voucher Identifier. When she will be back on nihil.com, she will have the opportunity to take advantage of this by entering the UVI in a special field, before starting to pay and the amount of the new order will be discounted in this due limit.

Details

There are a number of types of purchases that don't require the full attention of the payer when they happen. For example, an in-game purchase for an item that costs $0.05 is not necessary until a pre-set limit set by the payer is reached. It is important to not make the payment experience cumbersome for markets that perform micro-payments, or require the processing of many repetitive payments. If the payment authorization step can be automated to the point of disappearing without creating a bad customer experience or generating fraud, then it should be eliminated.

Requirements

• A data format to express a request for a multi-use payment token that is capable of expressing an amount, a recharge frequency, and an optional expiration date.
• A data format to express a multi-use payment token that is capable of expressing a unique id, an optional amount, a recharge frequency, and an optional expiration date.
• A protocol to request a multi-use payment token from a payment processor.
• A protocol to specify that a payment request should be fulfilled using a multi-use payment token (or perhaps we don't have the merchant deal with this information at all - which would be preferable.)

Priority

Enter a priority (low, medium, high, critical) and your name beside it below:

• low (JY)
• high (Manu)

Reviewers

Jean-Yves, Manu

Feedback

• There is a great deal of overlap with this use case and the 'payment tokenization' use case. -- manu
• Question : is it really payment ? or just rebate ? -- jean-yves
  • This use case is about the ability to perform automatic payments given the prior approval of the payee. The functionality is needed for low-value a-la-carte purchases (in-game apps) and paywall-like services. -- manu
• Sounds like a payment agent use case, but probably not a "first-out" use case.
  • Disagree, this is fundamental to solving the paywall / in-app purchases use cases.
• This could be interpreted to be the basic NFC/ EMVCo proposition - 'just tap to pay up to 25 € of purchase value'. Very relevant to proximity payment. --joerg

Digital Wallet Portability

An entity (payer, payee, merchant, buyer) stores wallet, credentials, and digital receipts with a particular identity/wallet/data storage provider. The entity decides to switch to a different identity/wallet/data storage provider and all wallet, receipt, and credential data comes with them.

Examples

Details

Requirements

Priority

Enter a priority (low, medium, high, critical) and your name beside it below:

• high - if we don't figure out how to do this properly in version 1.0, we're going to create a vendor lock-in ecosystem. -- manu

Reviewers

Manu, Mountie

Feedback

• Where is the master image stored? Device? Cloud? Home computer?
• If we don't figure out how to do this properly in version 1.0, we're going to create a vendor lock-in ecosystem. -- manu
• This has repercussions from a credentials standpoint. We need to engage that community. -- manu
• This Could be a derivate from a 'wallet sync scenario'. Basically the user might be able to copy non-device bound items (credentials). For others, we should have a unique handle which supports wallet service providers and issuers to figure out in how far they allow for 'move' or 'copy' operations. Very good topic, but not easy to do... --joerg

Real-time Regulatory Reporting

A payment processor tracks mandatory financial regulatory events and submits machine-readable information to a regulator-provided URL to automatically meet regulatory compliance.

Examples

• Merchant POV: the sales device (either ECR or web server) sends a fiscal message after each transaction. This message must be signed (certified).

Details

Regulatory (fiscal) reporting has the following:

• Environment
  • "Electronic Seal" - electro-mechanical switch mechanism (allows protection of validation materials, such as the "fiscal certificate."
  • "Fiscal Certificate" - unalterable certificate for validating fiscal information.
• Reports:
  • Device configuration (data and parameters)
  • Electronic Journal
    • E/J Z Detail Report
    • E/J Receipt Detail Report
  • Event logs

Fiscal reporting is the responsibility of the merchant only. It is not visible either to the customer or to the payment processor.

Requirements

• All the required information (see "details") must be stored securely prior to transmission to the authority.

Priority

Enter a priority (low, medium, high, critical) and your name beside it below:

• Medium - David E. (Not actually sure if this might be a critical use case in some localities.)

Reviewers

Erik, David, Pat

Feedback

• What about fiscal printer requirements in various regions?
• Person to person transactions will trigger regulatory events.
• This sounds like a standardized web service for fiscal reporting. Privacy concerns prevail. - David E.

Digital Receipts

A merchant cryptographically-signs a standardized offer for a good or service. A buyer purchases the good or service from the merchant resulting in a standardized, cryptographically signed, machine-readable, digital receipt that is issued to the buyer. Entities involved in the transaction (merchant, buyer, payee) may then use the receipt as a proof-of-purchase for the good or service.

Examples

• Customer: Jeff buys a lot of heavy metal music for his car, through the "buy this track" function in the radio. When he buys a new car, he wants to transfer his collection, and needs to provide the receipts to show he has already paid for the songs.
• Merchant: Rockinradio, smoothSounds, and classicClassic are independent specialised music retailers. However they accept prrof-of-purchase from each other to provide a track that is in their online catalogue even if it was originally bought from another provider.
• Processes: Willie buys e-tickets for a football game, but his mobile phone is stolen while standing in the queue. Since he has a receipt and identifies himself, he can still get in to watch the match.

Details

Requirements

Priority

Enter a priority (low, medium, high, critical) and your name beside it below:

Reviewers

Pat, David

Feedback

• Requires signing to be fully useful. "Push" payments will use this receipt as part of the transaction.
• Even 'only informational' sales slips would be welcomed by users (according to what we know) - many would not take the paper slip anymore, and hope for the ability to copy these items to their PCs. Still, if signed, they would be much more useful. --joerg

Escrow

This use case is common on eBay and Ali Baba.

• Customer Escrow

when customer has no credit for merchants, Escrow Service Provider protect Customer by verifying merchant's credit

customer pay to escrow service provider and confirm pay out to merchant when customer received the service or product.

• Merchant Escrow

when merchant has no credit for customers, Escrow Service Provider protect Merchant by identifying customer's identity and credit

customer pay to escrow service provider and merchant provide service or product when escrow provider confirm's customer's identity and credit

• Escrow for Customer and Merchant

when customer or merchant has no credit for each other, escrow provider give protection for customer and merchant credit

Examples

• Sasha finds a remote-controlled helicopter for sale, and orders it. Instead of passing the money directly to the seller, his payment processor collects it, and holds it until the delivery service notifies them that it has been delivered.
• Jo books a 5-day stay in a hotel. Her payment processor reserves the amount of the booking, against her established line of credit, releasing the deposit to the hotel after the no-cancelation date. But since Jo made a last-minute not to go to the hotel, cancelling after the deposit was paid, the rest of the payment is cancelled.

Details

Requirements

Priority

Enter a priority (low, medium, high, critical) and your name beside it below:

• medium - We need more people from the escrow space to weigh in on this. Clearly, it's important, but we probably can't do it justice w/o someone like Alipay at the table. -- manu

Reviewers

Manu, Katie

Feedback

• Clearly, this use case is important, but we probably can't do it justice w/o someone like Alipay at the table. -- manu

Specific Prepaid payment solutions (Fuel, rental car, coffee, ...)

A merchant (payee) can issue a card or "payment instrument", associated with an account, in order to receive payments in money, and to keep record of prepaid units of consumption (tokens, units, ...). Such specific pre-paid instruments on which monetary value is stored, are designed to address precise needs that can be used only in a limited way : to purchase goods or services only in the premises of this merchant and issuer, or within a limited network of merchants under direct commercial agreement or because they can be used only to acquire a limited range of goods or services.

Examples

• Customer POV: Alice loves coffee and is happy to buy 100 coffees in advance, at a 20% discounted price, being sure she will be able to drink them when and where she likes, in any of the shops of 'CoffeeMart'. When she enter one of these CoffeeMart'shop, she will be able to "pay" by deducting the items she orders form this "coffee account". This account could be stored on her phone, in the cloud, on CoffeeMart's Computers, Alice's "coffeeaccount" being identified and secured through an app on her phone, an chip (and pin?) card or any other solution for identification.
• Merchant POV: CoffeeMart is most happy to integrate immediatly the money received for the 100 coffees into sales. This income received in advance improves its cash account, even if it, from GAAP's principles, he shouldn't consider this income as an actual revenue until coffees are actually ordered.
• Regulatory POV : [EU jurisdiction] there almost no need for such specific payment instrument to be authorized and regulatory requirements generally are almostzero.

Details

Requirements

Priority

Enter a priority (low, medium, high, critical) and your name beside it below:

Reviewers

• David, Manu

Feedback

Preauthorization with Completion

Transactions over a certain amount may require a preliminary check on ability to pay and also have provision to “lock in” the amount. Delivering services or products that are difficult to “undo,” such as performing an oil change, dispensing fuel, or renting a car, are examples of such situations. [such a description seems equivalent to the "Dual message system" (authorization) used by schemes Visa or MC to monitor and protect transactions with cards as Cirrus or Maestro... this is usually not accepted as "prepay" transactions in Europe]

Examples

• Customer POV: George pulls up to a pump in a petrol station. His in-vehicle application recognizes the station location and the pump, and asks if he wants to approve a fill up. He answers “yes” and is prompted for which method of payment he’d like to use. He makes his selection. He exits the vehicle and lifts the nozzle and selects the grade of fuel and fills his car. When he returns to his vehicle, an electronic receipt for the purchase is displayed by his in-vehicle application.
• Customer POV: Doris uses her mobile application to approve fuel fill-up for her van. She realizes after exiting her vehicle that the site is not ADA compliant, and so she can’t actually deliver the fuel. She uses her mobile application to cancel the transaction.
• Merchant POV: the merchant's in-store control system gets a message from the payment processor that pump 14 should be approved for a fill-up. The message includes a single use cryptogram that can be used to prove authorization. The equipment arms the pump and allows the fueling to proceed. On completion, the merchant system sends the actual amount to pay along with the single use cryptogram back to the payment processor.

Details

This use case allows for a two part transaction - the first either checks availability or reserves funds, the second completes the transaction with the actual amount. There are many different ways these two segments can be completed.

Requirements

This use case needs to enable:

• request directly from the customer through his/her own mobile application (similar to push-payment)
• request through the merchant equipment, similar to how it works today.

Priority

Enter a priority (low, medium, high, critical) and your name beside it below:

• High - David E.
• Medium - Jean-Yves

Reviewers

David, Jean-Yves

Feedback

• The approval amount needs to be limited by either the customer, the merchant, or the payment processor.

Refunds and Reversals

The funds that are transmitted from payer to payee are reversed after a decision by a merchant, regulatory authority, or payment processor.

Examples

• Customer POV: Pele buys a slice of pizza at a local restaurant and is accidentally charged for five slices of pizza. He notices the mistake on his bill and requests a refund, which the waiter approves. The overcharged funds are returned to his account.
• Merchant POV: A customer claims that a blender that they purchased online was faulty and returns the product to the merchant. The merchant provides the customer with a partial refund and a partial store credit based on the return policy.
• Regulator POV: 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.

Details

Requirements

• A protocol for transmitting a proof of purchase and reversing the transmission of funds in the proof of purchase.
• A way of identifying a particular individual, organization, or financial account and reversing all transactions to that entity.

Priority

Enter a priority (low, medium, high, critical) and your name beside it below:

• High - Manu
• High - Jean-Yves

Reviewers

Manu, Jean-Yves

Feedback

Design Criteria

When exploring systems design, there are concepts that clearly fit into use cases and concepts apply to all use cases. We are calling the latter class of concepts design criteria, which are goals that should be kept in mind while designing the overall web payments system.

Web Intents / Protocol Handlers

Consider using a Web Intents or Protocol Handler-like mechanism to provide an abstraction layer that could be used to solve both payment initiation and other problems on the Web.

Examples

• Trisha signs up with a new payment processor service, and during the registration, the service asks if it may be used to process the "buy:" intent/protocol.
• Ravi finishes placing all the items to buy into his shopping cart, when he clicks the "Pay" button, the "buy:" intent/protocol handler is initiated, resulting in a UI flow that requests that he picks which of his payment processors he'd like to use for the purchase.

Details

Web Intents or Protocol Handlers could be used as a simple way of solving the payment selection NASCAR problem. Instead of showing a large array of payment providers that are supported by the merchant, a dialog can be shown instead that only shows the payment mechanisms that are supported by both the payer and the payee. A payment provider may register as one potential handler for a particular intent/protocol scheme, and when the scheme is invoked, the payer is asked which handler they'd like to use to handle the request.

Priority

Enter a priority (low, medium, high, critical) and your name beside it below:

Reviewers

Feedback

• "Web Intents" appears to be deprecated. I believe we should investigate using RESTful Web Services with an adequately defined "hyper-media" GET command to ease discovery issues. - David E.

Data Portability

Require data portability for financial data and credentials that is required for core transaction functionality.

Examples

• Ginger would like to move her banking provider from MehBank to GoodBank. She goes to GoodBank and initiates a "Transfer My Account" process. GoodBank connects to MehBank, with the authorization of Ginger, and pulls her entire account history, digital receipt data, and balance to MehBank.

Details

It is often difficult to easily switch financial providers. This will become more difficult if the use of digital receipts becomes pervasive. If one needs a digital receipt to prove that a purchase has been made, then the curator of those digital receipts, like a bank, could use them as a customer lock-in mechanism. Therefore, it is important that any information that is expected to be used in transactions has a provable data portability story.

Priority

Enter a priority (low, medium, high, critical) and your name beside it below:

Reviewers

Feedback

• Switching from one bank to another is a banking management issue more than a payment phase situation -- pascal

Legacy Support

Ensure the Web payments solution can provide an abstraction layer that integrates with existing payment methods (eg: VISA, Mastercard, ACH, PayPal, debit card, Premium SMS, etc.)

Examples

• Harold buys a movie ticket to his local movie theatre via the Web. He is given a choice of paying with a credit card, PayPal, or Bitcoin. The digital receipt delivered to the merchant will be in one machine-readable format to ensure that the merchant can process each type of digital receipt in a generic fashion.
• Reece gets a weekly share of vegetables through a community-supported agriculture initiative. He may choose to pay using fiat money, or via work credits based on the number of hours he's worked on the farm. He pays in work credits, which is a hyper-local currency issued by the community-supported agriculture program. The digital receipt format only differs in the type of currency that was used to complete the sale.

Details

In order for the Web Payments initiative to be successful, it must not discriminate based upon payment instrument or currency. As many types of payment instrument as possible should be supported.

Priority

Enter a priority (low, medium, high, critical) and your name beside it below:

Reviewers

Feedback

• Regional legislation and payment scheme may require very different data to be available on a payment ticket -- pascal
  
• Security requirements on the payment ticket are also scheme dependent -- pascal

Authorization Configurability

Allow payment processors to define the required level of authorization for particular transactions based on their preferences and local regulations. For example: No auth for small amounts, PIN auth for medium amounts, Secure Element for large amounts.

Examples

• Sven buys a single play for an online video game. His payment processor allows the purchase with no authorization due to the low value of the transaction.
• Joyce initiates a monthly mortgage payment. She is asked to verify the purchase using a 2-factor authentication method that she had previously registered with her payment processor.
• Nimo buys a new car online. He is asked to authorize the purchase by digitally signing a purchase contract and then using his two-factor authentication device to verify the transfer of funds.

Details

There is an important balance between convenience and security that is typically context-sensitive. It not only depends on the situation and the type of transaction, but the payment processor and the payee's preferences as well. It is important that the type of authentication used for transaction is left to the entity's involved in the transaction, and is not hard-coded into the payment protocol.

Priority

Enter a priority (low, medium, high, critical) and your name beside it below:

Reviewers

Feedback

• Card payment means usually define one or more of those three common limits : the "Floor limit" above which an online authorization demand is necessary, the "CVM limit" above which a cardholder verification method (2nd factor) is requested, the "Upper limit" above which payment should never be allowed. -- pascal

Smart Contracts

Ensure the technology can be extended or does not prohibit the implementation of simple digital contracts and smart contracts.

Examples

• Quoma owns a small-scale bakery that sells bread to local stores. She creates a smart contract for pricing goods with her local stores ensuring that she can make a 20% profit over the input of goods into her bread. She ties the cost of wheat, energy, and water to the smart contract so that the price per loaf of bread tracks the market price for the inputs.
• Harim buys a piece of land on a 15 year mortgage. The smart contract that he executes with the mortgage lender will execute a withdrawal from his account to the lender's account on a monthly basis.

Details

Smart contracts, which are typically referenced when discussing Distributed Autonomous Organizations, provide the capability of algorithmically defining the distribution of economic value. While it is too early to define a smart contract platform for the Web Payments work, the creation of such a platform or set of protocols and formats in the future should not be prevented.

Priority

Enter a priority (low, medium, high, critical) and your name beside it below:

Reviewers

Feedback

• I believe this one should be out of scope for now. - David E.

Physical Receipts

Don't prevent a physical version of a digital receipt that can be verified, perhaps by printing out a QR Code on a slip of paper with some additional information.

Examples

Bertrand purchases a bus ticket at a booth using his mobile phone. The digital receipt for the ticket is printed out on a piece of paper, which he then takes and presents to a gate with a barcode scanner that scans the ticket and gives him access to the public transportation building.

Details

In designing the protocols and formats for the Web Payments work, it is important that offline-only is taken into account. One manifestation of this design requirement is the paper receipt or magnetic-stripe ticket.

Priority

Enter a priority (low, medium, high, critical) and your name beside it below:

Reviewers

Feedback

• Digital receipt should be digitally signed by a the acquirer or/and by the payment processor using their private keys and therefore could be authenticated by the merchant and by the buyer using the acquirer/payment processor public key certificate. -- pascal

Use Cases from ISO20022

(TBD).

Use Cases from X9

• TBD

Use Cases from Web Payments IG

• multisig to approve transactions over $3K. 1 signature for sender of payment, another for regulatory body.

Additional suggestions

• Splitting a bill among multiple business diners
  • Andy, Barbara, Charlie, and Devin meet for dinner after a working meeting. Andy and Barbara charge their meal to Barbara's company; Charlie pays for his meal and for the wine he selected for the group; Devin pays for his meal and leaves the tip. Barbara needs a receipt for her expense account.
• Making a payment from multiple accounts, by a single non-profit (tax-free) payer
  • Eleanor works for a non-profit entitled to tax-exempt purchases. She buys some office supplies to have shipped to the office. Before check-out, she realizes that she will get free shipping if she adds $5 more to the order. She adds a lamp for her home, and wants to charge that to her personal account.
• Tipping on a payment
  • Fester frequents a favorite business. He wants to add a tip for excellent service as a percentage of his purchase price. As a computer scientist, he wants to write an algorithm to calculate that percentage based on indications he makes at the time of payment.
• Delegating: Giving a child ability to make limited-value purchases on a parent's account, then suspending that authorization when the child gets detention
  • Gail gives her daughter Hilda an allowance of 5 euro/week. She would like to enable Hilda to save from week to week, and to make independent online purchases against that balance, up to a combined value of 20 euro/week (more than that amount requires parental approval). When Hilda is punished for acting up in class, Gail suspends her ability to make purchases.
• Payroll management
  • Incorporated Widgets wants to send payments to its employees each week as soon as their supervisors acknowledge performance. Jorge wants to split the funds he receives among a retirement savings account, a college account for his son, and a cash account.