Copyright © 2013 the Contributors to the Web Payments Design Principles Specification, published by the W3C Web Payments Community Group under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.
Underlying most standards are a set of design principles that often capture not only the technical considerations underpinning the system being created, but the philosophical considerations that influenced the direction of the technology. This document outlines the design principles and general philosophy behind the Web Payments work. It is used to guide the standards making process behind the technology that the group creates, and is meant to be a set of general guidelines rather than a set of prescriptive rules.
This specification was published by the W3C Web Payments Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.
Technologies are often targeted, either willfully or accidentally, toward empowering a certain group of individuals. Speaking generally, patented technology primarily empowers the creators of that technology with secondary empowerment coming to the consumers of the technology. Technologies, such as the Web, primarily empower the individual with secondary gains coming to large organizations that can capitalize on the core infrastructure that the Web provides. The Web Payments technologies should focus on empowering the individual, local groups, and large organizations, in that order.
In general, this means choosing technologies that are not patented, and ensuring that all participants in the Web Payments ecosystem are capable of performing the same activities (within reason). There will be certain activities that will require licensing of some kind or another. In these cases, solutions should be attempted that remove the need for acquiring the license in the first place while simultaneously staying true to the local, federal, and world laws.
By focusing on individual empowerment, the hope is that certain side-effects like increased competition, access to technology, and increased rates of innovation can be achieved.
Competition simultaneously drives innovation and commoditization of technology. If the goal of the Web Payments group is to empower the individual and get the technology to as many people as possible, then the standards must attempt to maximize competition. Keep in mind that this is different from merely promoting competition. For example, the standards could be written in such a way as to only push banks to compete with each other. However, maximizing the competition would enable a larger group than just banks to compete in order to provide financial services to customers. Ultimately, the ideal scenario is that the financial service is designed so that the individual doesn't need a 3rd party to gain the benefit of the particular service.
In order to maximize the impact of the Web Payments technologies, they must be compatible with a variety of (often conflicting) local, federal, and global laws. At no point should the group consider standardizing technologies to enable the large-scale evasion of tax, money laundering, or funding of illegal activities.
Technologies standardized by the Web Payments group should be broadly implementable by software developers and engineers that are well-versed in the art of programming. This also means that the need for software patents and black-box modules should be avoided in the primary design of the system.
To be clear, this means that Digital Rights Management (DRM) technologies should not be employed in the primary payments system. However, it also means that DRM systems may be layered on top of the payment system if a particular ecosystem (such as the information security ecosystem) requires use of the DRM technology.
Part of promoting competition is ensuring that customers may switch from one service provider to another in a standarized manner. Ideally, switching from one provider to another should take as long as transferring data from the old provider to the new one. In order to facilitate this migration, all important transactional data should be designed to be easily moved from one provider to another.