Payments Task Force

From W3C Wiki

What do people want? What can W3C practically achieve? Who would work with W3C to drive this forward?

Web application developers want to monetise their work, particularly on mobile where ads are not as effective as on desktop. The Open Web Platform does not yet offer standard ways to transfer money, demonstrate proof-of-purchase, and meet other payment needs. Without a standard, developers are forced to turn to native platforms, or use solutions that work for one service provider but not another.

What are the opportunities and challenges for Web based payments? Can we provide a means whereby users have a free choice in which means of payment they can use in any given situation? What is the relationship to eWallets that reside in your phone or in the cloud? How can we enable valued added third party services?

There was a headlights initiative on this in 2012, as well as a Community Group looking at particular approaches. The W3C staff believes that the platform and industry have evolved in the past year to the point where we need to revisit the question as a community.

Organizational Context

W3C management reviews W3C priorities and resources on an ongoing basis, and annually explores major re-allocations of resources to align with important trends. This task force is due to report to the W3C Advisory Committee at the Tokyo meeting in June 2013, and is likely to be followed up by a W3C Workshop later in 2013. The purpose of the Task Force is to gather information that would help with determining the appropriate scope for the Workshop and the likely demand for it. Any standards work that follows on from the workshop would be driven by W3C Member contributions.

At the time of writing, a reasonable scope is likely to be the interface between a Web application (whether locally installed or hosted by a website) and a virtual wallet (based in the device or cloud) for the purposes of enabling applications to request a payment. This interface would be expressed as a JavaScript API, and would be neutral with respect to the payment providers supported by the wallet. Some additional possibilities for a broader scope include pre-paid vouchers, discount coupons for loyalty schemes, person to person payments, and offline payments. It is likely that any standardization activity would start with a narrow scope, but it is useful particularly in the context of a Workshop to explore a broader scope to ensure that we don't blindly create standards that cause problems later when we want to expand the scope to a broader set of features.

Feedback is sought on the suggested scope, and the value of defining open standards for a Web payment API. What are the requirements for the information flows involved, and how would they apply to specific payment providers, e.g. carrier billing, debit or credit cards? We are also looking for suggestions for where and when to host the Workshop, and will be looking for volunteers to host or sponsor it. Please feel free to respond on the mailing list (see below), on this wiki, or if you prefer, send your suggestions and comments direct to Dave Raggett <>. Note that much of the material on this wiki has been gathered in a brain storming mode as an exercise in setting out the background to web payments, and your help in reviewing and updating it would be appreciated.

Draft plan of action

The process will last several months culminating in a presentation at the Tokyo AC meeting in June. The aim is to reprioritize W3C resources to ensure we remain relevant to our mission to lead the Web to its full potential.

How to get involved

Please subscribe to the public mailing list See the link on that page for details. See also the welcoming email. If you already have a W3C Account, you will also be able to edit this wiki. To get a W3C account, fill out the account request form. In case of further questions, please contact the following:

  • Dave Raggett <>

Note: anyone making a substantive contribution to W3C specifications on the Recommendation track will be required to commit to the requirements of the W3C Patent Policy.

How will the task force operate?

Mostly through email and communal editing* of this wiki. We will organize teleconferences if the need arises. Likewise, if it makes sense, we could organize a face to face meeting. If you're willing to host a meeting let us know!

* Note that the W3C site should not be used as a marketing platform for products, so all contributions to this wiki will be reviewed for their suitability.

Sign up to help with a particular area

We're looking for volunteers to help with particular areas. If you are interested, please let us know on the mailing list (see above).


You are invited to add your name and affiliation to the list on the following page.


What is the scope for web payments? Here are some ideas for consideration:

  • Online payments to a website, or web app developer
  • Small payments as part of a prior arrangement
  • Offline payments, that can be redeemed when you go online
  • Payments via tapping your device against another
  • Mobile and cloud based wallets
  • Person to person payments
  • Use of community based currencies
  • Use of third parties as means to bridge gaps, e.g. currency conversion and different kinds of payment systems
  • Proof of purchase
  • Support for holding payments in escrow pending completion of transaction
  • Secure means to track your payments
  • Relationship of payments to systems of identifiers (people, organizations, currencies, products, etc.)
  • Anonymous payments
  • Role of national governments and international treaties in relation to web payments, e.g. questions of open markets, accountability, anonymity, community based currencies, cross-border payments, taxation, and so forth.
  • Value added services including prepaid vouchers, discount coupons, recommendations, reviews, etc.
  • Other standardization efforts relating to web payments
  • Security requirements and strong authentication, including the use of biometric techniques such as finger printer readers

In addition we need to characterise the ecosystem for payments as it relates to the requirements for realizing open standards for web payments.

Web Payment APIs


Use this space to ask questions to frame the group's discussion. See Draft Plan of Action for further links.

Note that you are strongly encouraged to put details into fresh wiki pages linked from here. Please use page names that are unique to avoid clashes with other users of this wiki.

  • What is unique about Web payments? What do we need that isn't satisfied by current credit/debit card or money transfer solutions? What would an open standard bring?

Today many newspaper sites offer some free content, but to read more, you need to set up a subscription with your credit card. Open standards would reduce the barrier for users to purchase content, by allowing them to pay with their wallet, without the need to first set up a subscription with the news site. Small payments are practical through payment providers that offer debit accounts that are prefilled and drawn down. Users would be encouraged to switch to a subscription model via reduced rates for content. Open standards would allow the user to pick the payment provider rather than having this hard wired by the website.

  • To what extent is it possible to define an API that web applications can use to request payments, such that this API is independent of the user's choice of payment provider?

Whilst the broad requirements are the same, the details may vary from one payment provider to the next. One approach is for the app to present a set of requests as appropriate for different payment providers. The browser would pass the relevant request to the payment provider picked by the user. Each request can be represented as a signed JSON object. Ideally, there would be a standard form of request that would be usable with a wide variety of payment providers. The same holds true for the data passed back asynchronously from the payment provider to the app that requested the payment. In the Firefox OS mozpay API, the response is passed to the server via a post-back URL provided in the request. For offline payments with installed packaged apps, a local response would be needed.

  • How does the selected payment provider interact with the user?

One solution is for the provider to fill an iframe element provided to it by the browser. This allows for the user interface to be implemented with HTML5 in a sandboxed environment that isolates the payment provider from the application. The payment provider would have access to native cryptographic support via the WebCrypto API from the Web Cryptography Working Group, and to secure hardware via the proposed Secure Elements API from the System Applications Working Group.

Related Pages

See also Team internal wiki (obsolete)