The purpose of this document is to condense the information available across the multiple sources into as single living document. This document will be the standard for this branding effort moving forward. This document exists to ensure all parties are working with the same assumptions and guidelines, and all input is highly valued.

The Visual Identity task force meets bi-weekly; see the meeting invitation and minutes: 15 Oct, 11 Oct, 27 Sep, 13 Sep, 30 Aug, 16 Aug, 2 Aug

• Payment Request API exists to enable users to complete a transaction more easily by reusing information stored in the browser or by third party payment handlers.
• Up till now making payments has been frustrating and often confusing. Every website has a different method and flow, often repeating addresses, payment credentials, and contact information.
• The goal of WP API is to streamline the payment process, create trust and reduce shopping cart abandonment.
• This is achieved by allowing the user to store and reuse information in their browser to use across multiple platforms and use it quickly for a smooth check out process.
• Furthermore, having a standard API for payments on the Web may foster payment innovation, including enabling more secure payments.

• To create a trusted and complete visual identity for the Payments Request API user experience with emphasis placed on a single identifiable recognized ‘Mark’ or ‘Bug’
• Logo, color palette, type family, and style guidelines.
• Mod-able logo/Bug that vendors can alter to suit their visual identities.
• Possible UI to maintain cohesive look/feel of the brand for use by Vendors.

• Landing page for logos and policies

• Logo/assets in web and print formats, and a usage guidelines document in PDF format.
• Ready made assets for common use cases.

• WP API is a trusted and secure product that provides a streamlined user experience with greatly reduced developer work.
• Reduces customer frustration by enabling reuse of their stored information for the speedy and low friction check out. Less typing, consistency across multiple platforms.
• Can be used by multiple vendors.
• Any payment method can be used with the API. The APIs are designed to support both Web-based and native mobile payment handlers.
• Reduces the time consuming burden on developers to create and maintain checkout pages that require multiple payment methods.
• Reduces the friction of updating due to new payment innovation and adoption.
• W3C is also working to improve the security of Web payments.
• Because the API enables a streamlined check out through user-stored data, merchants may choose to not store payment credentials, which can reduce liability and cost.

• Unknown product that needs to build trust and credibility.
• While it reduces the burden of merchants to build a checkout experience, it also implies that the merchant will have less control over aspects of their customer experience.
• Some users will resist storing their credentials if they do not feel secure in the products safety and trustworthiness.

• Explore visual identity first.
• Provide a logo/brand treatment that communicates trust and simplicity as an introduction to the product.

• Become the standard across web/mobile as a reliable, recognizable and secure payment method to both merchants and customers.

• Primary: customers, then merchants
• Secondary: payment service providers, payment app providers

• GitHub provides exposure to other developers.
• Slack channel provides a second forum.
• For Later: developer relations groups within browser vendors (and other W3C Members).

• Request AutoComplete. Lacks several important features from WP API.
• Pay buttons.
• Browser branding, perhaps. Should the browser render this in a manner consistent with the browser skin?
• See Competitor Visual Brands

• HTML5 Logo, specifically its boldness and recognizability while still being adaptable for merchants, etc.
• Traditional marks used by traders/businesses to certify trust and legitimacy of their product. Examples:
  • Marks used by traders to symbolize their goods.
  • Jewelers hallmarks to certify quality of metal and origin.
  • Images that evoke trust, money and security.
  • Examples: Wallets, vaults, locks, coins.

Discussion Point - What are the positive and negative things that can be said about the product by competitors and the average layman user?

• Makes checkout incredibly easy.
• Reduces cart abandonment and increases customer conversion.
• Solves problems for both customer and merchants.
• Creates less work for developers (and has the potential to increase security through adjacent Web technologies).

Discussion Point: What other characteristics are considered unique to Web Payments API?

Efficiency/Speed Simplicity/Convenience Payment/Money Security/trust Practical/Useful

Discussion Point: Has the group considered a motto/tagline?

Discussion Point: Is the layman name Web Payments?

• Will be used by multiple developers and vendors, thus needs to be customizable to match their brand/platform.
• Easy to identify
• Looks good at smaller scales
• Needs to work on a checkout page where it is the “buy” button, as well as on pages with multiple brands.
• Global: Not specific to one currency or one payment method.

Discussion Point: Should the logo provided be 100% customizable or should it be mostly our brand with a smaller portion that provides opportunity for customization?

• Looks good in its simple black and white form.
• Feels secure and trustworthy.
• Easily identifiable at small scales.
• Easily identifiable when surrounded by several other brands/in other platforms.
• Continued brand recognizability when altered by merchants/developers.

Discussion Point: Are there any other considerations that have not been presented in this document?

Heath: Continued research and sandboxing of trustworthy identities that currently exist as well as traditional symbols/marks. Will present this Visual Brand Exploration document.

Ian: Read over Discussion Points and contribute thoughts/clarification.

• Spec provided calls out landing page, need to confirm this is only design work and not coding/developer work.
• Any additional audiences that need to be considered/researched?
• Any additional outreach being used or developed?
• Any additional competitors whose branding/strategies need to be considered/researched?
• What other characteristics are considered unique to Web Payments API?
• Has the group considered a motto/tagline?
• Is the layman name Web Payments?
• Should the logo provided be 100% customizable or should it be mostly our brand with a smaller portion that provides opportunity for customization?
• Are there any other considerations that have not been presented in this document?

Wondering if we need an alternative to "Web Payments". Suggest ideas below!

• Include visual identity in the sheet, to connect it in users' minds.
• In browser settings pages, include the identity so that users recognize the link to the button
• Have enough merchant identity in the sheet so users recognize the connection to the merchant site (e.g., favicon).