Warning:
This wiki has been archived and is now read-only.
Vision2017
The Web Payments Interest Group has held a number of discussions since its launch in 2015, some of which have led to detailed discussions in Working Group and Community Groups. At this time, the Interest Group seeks to identify a new set of business use cases for initial discussion within the Interest Group. This task force will propose new areas of work for the Interest Group, taking into account the IG Vision (and possibly proposing modifications to it) and previous work flow discussions.
IG participations: David Ezell, Ben Smith, Dapeng Liu, Guy Berg, Pascal Bazin, Joerg Heuer, Manu Sporny, Ted Guild, Mark Tiggas
Questions? Contact Ian Jacobs <ij@w3.org>.
Contents
Outcomes
- The work of this task force was discussed at the IG FTF meeting in Chicago in March 2017.
- Discussions continued after the FTF meeting on these topics: regulatory landscape (though at a slower pace), security of web payments WG deliverables, automotive payments, digital offers.
- Discussion did not continue on: digital receipts.
Goals
The goals of this task force are:
- To identify new topics of broad interest for the Interest Group to take up in 2017 that have the potential for future standardization work.
- If necessary to accommodate this new work, propose changes to the Vision.
Non-goals:
- To propose revisions to the IG Charter, which expires at the end of September.
- That is work that should be done within the IG, but not in this task force.
- To adjust the Interest Group's mode of work.
- That may also be useful but should be done once the IG has taken up new topics.
Timeline
- 26 Jan: Task force participants introduce topics of interest (26 Jan minutes)
- 3 Feb: We will review the summary of the previous meeting and proposed set of topics to continue to advance. We will discuss assignments, and work with participants so that people understand what is expected and can commit to delivering proposals at the 10 February call. (3 Feb minutes)
- 10 Feb: The task force will review proposals. For each topic you wish to propose, please endeavor to answer the questions that we discussed on 26 January. The task force will look at the topics that look the most promising and may decide to focus on those moving forward. (10 Feb minutes)
- 17 Feb: Continue to review proposals. (17 Feb minutes)
- 24 Feb: Continue to review proposals (24 Feb minutes)
- 3 Mar: Before the call, I would like to work with each Champion to write down a draft plan (deliverables, milestones, etc.) first for discussion in the task force, with an eye toward the FTF meeting. Then we can discuss the plan at the next meeting. Champions will receive feedback and then revise the plans. (3 March minutes)
- 20 Mar: Presentations available to the IG
- 22 Mar: Presentation of proposals at IG FTF meeting in Chicago. Selection of priority proposals.
- Post FTF meeting: implementation of plans
Proposals
About Proposals
- Initial proposals should take the form of a short slide presentation to introduce an industry use case and problem statement(s).
- Each proposal should endeavor to provide the information requested in the next section.
- As proposals mature, the amount of information provided to answer those questions will increase.
Information to Include in Proposals
- Title for your topic
- End user story that illustrates the problem to be addressed
- Stakeholders and benefits
- Who are the primary stakeholders?
- What are their incentives for change?
- How will they benefit?
- Specifically, how will users benefit?
- More about the problem
- How big is the problem
- What work is happening elsewhere to address (part of) this problem?
- Have there been previous attempts to address this problem? What was their outcome?
- In what way would improved interoperability help address this problem?
- Community
- Who specifically should be part of the discussion at W3C?
- Which parties are critical for implementation?
- Why is W3C uniquely positioned to address this problem through standards or otherwise add value to the ecosystem?
Proposals
Automotive
Security
Web-based Digital Wallets, Loyalty, and Payments
Web-based Digital Wallets Presentation
Representative Scenario: Jane loves her local coffee shop, Muggs Coffee. Sam, the owner of Muggs, is a local businessman that desires to create a stronger relationship with his customers through a loyalty program. Sam provides digital loyalty cards to his customers. His customers store these digital loyalty cards in their digital wallets. Sam can then, via his loyalty card software, send his customers individually tailored digital offers via their mobile phones. Muggs' Loyalty Card holders may then choose to purchase the products and services described in the digital offers directly via their phone giving Sam direct feedback on whether his loyalty program is working.
Digital Receipts
Problem
Because of the lack of a clear standard or guidance, consumers and merchants face a range of complexities when it comes to issuing, storing, retrieving, and analyzing digital receipts on the Web. Ready access to proof of purchase is needed by consumers and merchants to address a variety of challenges. For instance, merchants care about controlling fraud in returns or refunds, and consumers may have legal requirements to prove purchase of items in their immediate possession: Guarda Financia (Italy) may require proof of purchase during any street encounter.
The format and the process must be consistent in order to provide ease of review for users, especially those with disabilities. Having to navigate merchant websites to find information, provide email information to receive receipts, and then deal with a variety of formats makes life difficult for everyone. Historically, payment systems have always provided a receipt as part of the payment process, even though the receipt is produced on behalf of the merchant.
The goal of the proposed activity is to provide a concrete list of minimum required receipt semantics supporting a consistent and portable user experience. Potential candidate artifacts include:
- Consistent "container" format for digital receipts (may support various internal formats).
- Web based "push" protocol for receipt delivery.
Activities that will support that goal include examining existing external work, creating guidance in knowing how to integrate that work into the web payment process, and proposing new work items if they are deemed necessary.
Stories
Story 1
Dan buys a book on Danube Online, and receives a digital receipt into his wallet. On receiving the book, he discovers that it’s the wrong book, and wants to return it. Danube has a local brick and mortar store and he takes the book to the store to exchange it. He must provide a proof of purchase to make the exchange, so he presents his digital receipt to the merchant when he goes to exchange the delivered book for the correct one.
Story 2
Karie is visually impaired and makes most of her purchases on line. For each purchase, she is careful to store a digital receipt in her digital wallet. Her QuickAccounting program allows her to import her latest credit card statement, but to balance she must enter the receipts for the items purchased. She queries the receipts stored in her digital wallet to import into QuickAccounting and can successfully balance her accounts.
Stakeholders and Benefits
- Primary stakeholders
- Consumers
- Receive proof of purchase of individual items, in a consistent format
- Easy access to information through multiple interfaces
- Proof of purchase for taxes, returns, rebates
- Management of expenses and budgeting
- Merchants/Retailers
- Better control over customer relationships
- Coupon tracking and settlement
- Better management of transaction processes including returns, credit card disputes and rebate authorizations
- Green Initiative
- Marketers
- Targeted Marketing
- Coupon Redemption tracking & Settlement
- Reduced Coupon Fraud
- Regulators
- Processing of sales records for controlled merchandise.
Additional Information
- Size of the problem
- The problem is pervasive, and is solved by technology providers (in some cases), as well as attempts at standardization (see below).
- Many solutions in various industry verticals and technology layers are extant.
- What work is happening elsewhere to address (part of) this problem?
- Here is a small sample of work that is either underway or has been attempted
- Have there been previous attempts to address this problem? What was their outcome?
- See the section above. While there are “standards”, none of them appear to have global “uptake.”
- In what way would improved interoperability help address this problem?
- All participants in the retail system would be able to manage and audit their purchases/sales in a consistent way.
Community
- Who specifically should be part of the discussion at W3C?
- The Web Payments WG, as well as groups involved in either encryption, authentication, or other protective measures for the data (Web Security, Verifiable Claims).
- Which parties are critical for implementation?
- Ultimately, browser implementations should recognized “standard” receipts and know what to do with them. Other implementations (like for accounting systems) will use the same data models.
- Why is W3C uniquely positioned to address this problem through standards or otherwise add value to the ecosystem?
- Formulation of receipts for online purchases and management of the those receipts are primarily the responsibility of the programmers who write web applications. The W3C targets an audience that spans industry verticals and technology layers, whereas other attempts tend to be specifically useful in either a specific vertical or a specific layer.
Task Force Work
Process for achieving goals
- Refine the semantic requirements (below)
- Review UBL, ARTS and other potential formats for “best fits”
- Produce examples of how to use each potential format to fulfill the requirements.
- Define new data formats only if required.
Semantic Requirements
- Searchable Data
- Merchant identifier
- Transaction Identifier
- Hash (this receipt or partial fulfillment receipt)
- Date/Time
- Transaction Amount
- Financial transaction information:
- Total amount authorized in merchant currency
- Total amount authorized in local currency (matches the customer account)
- Amount settled now in merchant currency (partial fulfillment)
- Loyalty points applied, offers redeemed
- Issuing bank identifier (IBAN)
- Goods/services purchased descriptions
- Taxes applied
- Loyalty and other offers for customer (rewards)
- Consistent display capabilities