Paze^SM offers Merchants a simple, and convenient way to simplify their customer's checkout. A Consumer’s Paze Wallet contains payment, contact and shipping information. Their credit and debit card, contact and address data are derived from participating Issuers’ records. Contact and shipping information can be updated or augmented over time as a Consumer shops with Merchants that accept Paze. Consumers may also update their contact and shipping information directly with their Issuer.

Paze returns tokenized payment credentials as well as other data required to submit a Payment Transaction for approval. This information can be used by a Merchant to initiate payment processing or can be handed off to a dedicated payment processor.

This document describes the Merchant integration guidelines and best practices and is intended to be used alongside the following documents:

• Paze Merchant JavaScript Software Development Kit Technical Requirements
• Paze Merchant Business to Business API Technical Requirements
• Paze Merchant Mobile API Technical Requirements
• Paze Checkout User Interface Standards
• Paze Platform API OAuth Access User Guide (required with Merchant Business to Business API and Mobile API)
• Paze Suggested Test Cases

Overview

Merchants may integrate with Paze directly or indirectly depending on their existing tech stack and how they work with their service providers. Paze supports Merchants that have in-house commerce and payment processing capabilities, as well as Merchants that work with service providers for one or both of those functions.

In general, a Merchant’s Paze integration should follow the pattern below, with additional degrees of complexity added at the Merchant’s discretion. Error states have been omitted for clarity.

Integration Process

Service Provider Implementation

Service Provider implementation can be requested directly through the Merchant JavaScript SDK or Merchant Mobile API Technical Requirements. This precludes the use of the Merchant Business-to-Business API.

For Merchants that have separate providers for commerce and payment processing functions, the payment processor can receive the encrypted payload in two ways:

1. The commerce site requests the full encrypted payload from Paze. Upon receipt, the commerce site transmits the payload to their payment processor.
2. The commerce site requests the payload identifier from Paze. Upon receipt, the commerce site transmits the payload identifier directly to the payment processor. The payment processor uses the payload identifier to request the full encrypted payload from Paze.

Use Cases

The Paze Merchant JavaScript Software Development Kit Technical Requirements and the Merchant Mobile API Technical Requirements are designed to be implemented by Merchants in a variety of ways to meet their business objectives. Paze offers increased consumer convenience for checkout, account creation and card update.

Note: Example flows provided in this section are the Service Operator’s simplified representations of potential Merchant flows. This document does not represent legitimate front end designs for Merchants’ digital properties.

Checkout

A Merchant can invoke Paze when a consumer enters their cart with the intent to make a purchase. Depending on the Merchant’s implementation, this can facilitate both guest and registered users’ transactions.

Checkout Example

Note: Some screens have been removed for a more concise flow. For a full consumer experience flow, refer to the Consumer Experience Flow.

Account Creation

During the checkout process a Merchant can invite a consumer to create an account with the Merchant directly. The Merchant must get explicit consent from the consumer to save this information but with such consent the Merchant may use the information from Paze. The token received from Paze should be exchanged for a Merchant dedicated network token as outlined in Network Tokenization. Subsequent transactions and interactions do not need to involve Paze.

Paze Offers – Specification Update

Paze provides specific messaging and checkout customization optionality to Merchants in order to support Paze-specific offer campaigns. Namely, Paze offers three distinct surfaces where offer information and call-to-actions can be surfaced.

• Messages under the button via our custom HTML element
• Messages in the start of auto-initiate flow 
• Customized checkout screen based on Merchant Inputs

Messages Under Button: 

• Merchants should integrate our custom HTML element below the button as part of their initial integration. Once initially integrated, no further code updates will be required to populate a message. 
• Paze will push messages, as appropriate, to the surface.
  • For example, when running a co-branded marketing campaign during May, Paze can push the following message to the surface: “Save 15% off your transaction using Paze this graduation season!”

Messages in the Auto-Initiate Flow

Paze will be able to push messages to the auto-initiate launch screen without any merchant inputs required. For example, “Get 20% off by checking out with Paze!”

Customized checkout screen based on Merchant inputs

• Merchants are suggested to provide additional discount-related inputs which can be used to customize the review screen based on dynamic inputs. 

  • These discount inputs help are used to continue the discount experience through the final review screen. Please see the following example

• New fields which drive review screen customization are available in the _transactionValue_ object. 

  • The _transactionValue_ object is an object nested within the _checkout_ call. 
  • Merchants use the _checkout_ call to launch the Paze checkout UI. Users authenticate and select a card for payment within the Paze checkout UI. 

• The new fields are: _discountAmount, subtotal, taxAmount and shippingAmount_ o   The updated _transactionValue_ object is represented by _transactionValue_

  

• New fields which drive review screen customization are available in the _transactionValue_ object.

Custom Message HTML Tag

Paze provides specific messaging and checkout customization optionality to Merchants in order to support Paze-specific offer campaigns. Namely, Paze offers three distinct surfaces where offer information and call-to-actions can be surfaced.

• Messages under the button via our custom HTML element
• Messages in the start of auto-initiate flow
• Customized checkout screen based on Merchant Inputs

This HTML tag is specifically used to drive message under button experience. Refer to the Merchant Integration guide for up-to-date UX representation.

Placement of the Paze message tag should be displayed near the Paze checkout button/radio button. Condition, the SDK initialize() function has been called to allow for messages are to be displayed near button. The SDK will replace the tag with custom messaging from Paze if applicable; otherwise, the tag will not be displayed.

Custom messaging will only be displayed when there is written agreement. Merchant and Paze Merchant Team will work together to define and approve display language.

Attributes

Code Sample

<paze-message
  message-id=”1”   
  message-placement=”checkout”   
  theme=”light”   
  size=”medium”></paze-message>

Card Update

A Merchant can invoke Paze to allow consumers to update the payment credentials associated with their Merchant accounts. Registered users may update their card information on their account management page, or this can also occur simultaneously with a Payment Transaction.

Card Update Example

Note: Some screens have been removed for a more concise flow. For a full consumer experience flow, refer to the Consumer Experience Flow.

Intent Configuration

The Paze Service enables Merchants to customize the Paze user experience to be consistent with the user journey(s) presented on their digital property. Intents further refine the experience presented for each use case and should be used in conjunction with Merchant messaging to clarify the action that is being taken.
Note: Example flows provided in this section are the Service Operator’s simplified representations of potential Merchant flows. This document does not purport to represent legitimate front-end designs for Merchants’ digital properties.

Review and Pay

Review and Pay is the default intent used for the Paze user experience. It should be used when the consumer is going through a checkout experience and will be given the option to confirm their order details prior to finalizing their transaction. It can also be used in lieu of the other intents if a Merchant chooses not to customize their flows.
Review and Pay is compatible with the purchase, card-on-file, and combined scenarios, as it presents generic language to consumers.

Review and Pay Example

Express Checkout

Express Checkout provides the consumer with messaging that the Merchant will immediately process the transaction upon their return from Paze. It should be used when the Merchant has finalized details for that order (e.g., fixed-cost digital goods sale, pre-calculated shipping fee and sales tax).

Note: Express Checkout requires the value of the transaction to be passed in.

To implement Express Checkout, Merchants should call the Complete API in either the web SDK or Mobile API upon receiving a successful response from the Checkout API.

Express Checkout Example

Note: Some screens have been removed for a more concise flow. For a full consumer experience flow, refer to the Consumer Experience Flow.

Add Card

Add Card indicates that the consumer is adding their payment credentials on file with the Merchant. It should be used when the transaction’s only purpose is to add or update a payment card on the Merchant’s digital property.

Note: Add Card requires the value of the transaction not to be passed in and the shipping address not to be requested.

If a Merchant would like to offer card-on-file alongside a purchase, they should utilize the Review and Pay intent instead.

Add Card Example

Note: Some screens have been removed for a more concise flow. For a full consumer experience flow, refer to the Consumer Experience Flow.

Initiation Points

Paze recognizes a consumer wallet by an email address or mobile phone number. However, the way in which a consumer’s email address or mobile phone number are collected is configurable based on a Merchant’s preference. In keeping with the Paze core principle of offering flexible implementation options, Merchants may choose to present the Paze experience differently depending on the consumer’s journey through the Merchant’s digital property.

Note: Merchants should confirm that they have provided all disclosures, notices, and options to consumers required under applicable law and privacy requirements in order to provide or otherwise make available information or data to Paze℠ for use in the service. Before the consumer is redirected to the Paze℠ experience, Paze℠ may collect several data attributes when the Initialize API is called, such as email address, device ID, IP address, and browser. Such information is collected by Paze℠ and may be disclosed to third-party vendors to make fraud risk decisions throughout the checkout experience.

When deciding on initiation points, Merchants will need to assess the tradeoff between consumer convenience and wallet accessibility. Providing an email address or mobile phone number on a consumer’s behalf preempts manual data entry; however, it runs the risk of not matching the consumer to their wallet. This will occur if the consumer has different email addresses or mobile phone number for their issuer(s) and the Merchant.

Static Button Initiation

A Merchant may want to integrate with Paze by placing a static button on their website. This gives consumers the option to click into the Paze experience at their discretion.

Note: The static button can be implemented for registered users with or without reference to their email address or mobile phone number on file with the Merchant.

Static Button Initiation Consumer Outcomes

Dynamic Button Initiation

A Merchant may want to allow consumers to choose from multiple payment methods, while also preventing them from seeing options that they cannot use. By adding logic that only shows a button to consumers who have an active wallet with Paze, Merchants can prevent consumers from entering a flow that they cannot complete.

Dynamic Button Initiation Example

Automatic Initiation

A Merchant may want to offer Paze to eligible consumers. By sending consumers’ email addresses or mobile phone number to Paze without adding a button to their site, Merchants can direct eligible consumers to the Paze wallet without impacting ineligible consumers’ experience on their site.

Note: With automatic initiation, for consumers who accidentally exit Paze to allow them to re-enter, it’s strongly suggested to include a static Paze button on the primary checkout page. If a consumer exits Paze, they should be taken to the Merchant primary checkout page and not placed back into the Paze flow.

Merchants are recommended to perform frontend validation to confirm that data has been entered into the email address or mobile phone number fields before calling the Paze Checkout API. Otherwise, defocusing from that field when it is empty will launch an experience that requires the consumer’s email address or mobile phone number to be collected within Paze.

Automatic Initiation Example

Cobrand Card Presentment

Paze offers an optional feature for Merchants who have cobranded cards with participating Issuers. Merchants who use this feature can highlight their cards for Consumer awareness.

Consumers’ default card selection will not be overridden if their wallet contains a cobranded card. Cobranded cards will be displayed more prominently relative to non-default cards.

Merchants should ensure that the cobrand name provided matches what is on file with the Issuer and Payment Network. If a Merchant has multiple cobranded cards, they should provide them to Paze in the order that they should be displayed.

Merchant iFrame

The Merchant iFrame is a dynamically sized inline frame that provides the Consumer with essential introductory information about the Paze Service. The Paze Implementation Team will enable and provide the URL for approved Merchants. As needed, Paze will be responsible for updating the contents within the iFrame, with no further action required by the Merchant.

Note: The Merchant iFrame may only be used on the Merchant's Checkout screen with approval from the Paze Implementation Team. The Paze Implementation Team retains sole discretion to provide approval and may revoke approval for use of the Merchant iFrame at any time and for any reason.

Onboarding, Integration, and Support

The use of Paze requires the participation of a Distributor who will contract with the Merchant and approve the distribution of production keys. The following outlines the steps to register and move to production access, including available support channels.

Note: A Merchant’s Distributor or Technical Integrator may be responsible for some or all of the of the outlined steps below. Coordinate with your Distributor and or Technical Integrator on your required responsibilities.

Onboarding and Integration Checklist

Register

• Work with your Distributor (or Technical Integrator if appliable) on their specific onboarding process, it may include Merchant to complete the Paze Merchant Setup Form, as part of registration a Rivest–Shamir–Adleman (RSA) certificate is required by the party managing the description of Paze℠ payload.
• A sandbox account is created for Merchant.
• Documentation is shared through Venue (virtual data room); Merchant Support Team will assign login.
• As required, test Paze wallets are created for testing the Paze User Interface.
• Marketing assets and materials are shared through Partner Portal; Merchant Support Team will assign login.
• Sandbox credentials generation and delivery method vary depending upon technical implementation.
  • Option 1: Paze Merchant Support Team sends credential to Merchant through Customer Portal (Early Warning secure document transfer site)
  • Option 2: Distributor sends credential to Merchant
  • Option 3: Technical Integrator sends credential to Merchant

Integrate

• Merchant (Technical Integrator or Distributor depending upon technical implementation approach) completes technical integration to applicable specifications following best practices, including integrating Paze into their digital property
• Present Paze per the Paze Checkout User Interface Standards Guide

Test

• Merchant tests in sandbox.
• Pre-defined test cases are available for sandbox testing.

Launch

Merchant signs Agreement with Distributor related to Paze Service

• Production access and release of credentials are managed by Merchant’s Distributors; credential generation and delivery method vary depending upon technical implementation
  • Option 1: Sent to Merchant through Customer Portal (Early Warning secure document transfer site)
  • Option 2: Distributor sends credential to Merchant
  • Option 3: Technical Integrator sends credential to Merchant
• Merchant to provide contact details to Paze for notifications regarding documentation changes, production releases, outages, etc.

Support

• Paze has ongoing communication about documentation changes, production releases, maintenance windows, outages, rule changes, etc.
• Merchant Support will provide ongoing support

Support Channels

Support is provided through:

• Merchant’s Distributor
• Merchant’s Technical Integrator (Optional)
• Paze Merchant Support (Early Warning)
• Technology Operations (Early Warning)

Distributors will be the main contact for support to their Merchants. If appliable, a Technical Integrator may be the main contact in providing support. Merchant shall contact the appropriate party (Distributor, Technical Integrator or Service Operator) corresponding to their inquiry. Paze℠ Merchant Support Team will assist with any escalations from Distributors, Technical Integrators or where Merchant connects directly to Paze Service.

Paze Merchant Support Email: [email protected]

Available Monday – Friday, 8 AM – 6 PM Central Standard Time

Support Responsibilities

Outage/Service Degradation

When assistance is required related to a Paze outage or service degradation please contact:
Early Warning Technology Operations

• Phone: 1.877.639.4457
• Email: ITOC @earlywarning.com
• Available 24 Hours a Day, 7 Days a Week

Environments

Test (Sandbox)

Sandbox requires full Merchant onboarding, including key exchange. It mirrors the production environment and allows for full testing, including with test cards. A Wallet Service Agreement with a Distributor is not required for sandbox access.

Production

Production is accessed after approval from a Distributor and the Wallet Service Agreements are executed between Merchant and Distributor. Updated credentials are shared with Merchant for the production endpoint..

Test (Sandbox)

Sandbox requires full Merchant onboarding, including key exchange. It mirrors the production environment and allows for full testing, including with test cards. A Wallet Service Agreement with a Distributor is not required for sandbox access.

Performance Guidelines

JavaScript API Latency Estimates

Merchants can estimate that API response latency for the Paze Merchant JavaScript Software Development Kit will roughly correspond to the following.

Note: The numbers below constitute estimates to be used for system design guidance and are subject to network latency and third-party services beyond Paze’s control. They do not represent a binding Service Level Agreement (SLA) or commitment by the Paze service.

JavaScript API Latency Estimates

Note: TLS versions 1.0 and 1.1 have been deprecated.

Estimated API Response Time

Supported Browsers

The Paze Service is tested on the most recent build of the following browsers.

• Google Chrome
• Safari
• Microsoft Edge

Other browsers may be compatible with the Paze user experience; however, they are not being tested alongside the list above.

Consumers’ user experience may differ based on individuals’ browser settings.

Functional Requirements

This section details high-level flows and describes the Merchant checkout functionality necessary to support Paze. Numerous possibilities exist for Merchant integration.

Simple Flow

In this flow, the Merchant handles its own Payment Transaction processing and initiates the Paze user experience (UX) automatically.

Expanded Flow

In this flow, the Merchant implements a dynamic button on their website and works with a payment service provider (PSP) to process Payment Transactions.

Transaction Processing

Paze Transaction Data is encrypted signed payload. When decrypted, this JWE object will contain a 16-digit network token, as well as the appropriate cryptogram. Other data returned to the Merchant is to be used largely for other purposes (e.g., order management, customer service).

In most cases, maintaining keys for the JWE and decrypting the JWE payload is performed by a Payment Service Provider (PSP) acting on behalf of a Merchant. A Merchant may directly maintain keys and decrypt the JWE, but using a PSP allows merchants to delegate payment card industry (PCI) compliance to them entirely. If a Merchant is using a third-party, such as a Distributor or Technical Integrator, this process may also vary.

Payload Signature and Encryption

Paze supports signed and encrypted payloads between Merchant and Paze platform. The payload encryption will be supported through the use of JWE (RFC 7516) and JWS transmitted using compact JSON serialization.

Paze supports the following algorithms:

• Key Encryption Algorithm: RSA-OAEP-256
• Encryption Algorithm: A256GCM
• Signature Algorithm: RS256

Paze tokens will evaluate and add support for newer algorithms as they become available.

Web Signature Summary

A JWS represents signed content using JSON data structures and Base64Url encoding. It consists of:

• JOSE Header – Protected Header
• JWS Payload
• JWS Signature

Each component is Base64Url encoded and concatenated with periods (.). For example:

BASE64URL(UTF8(JOSE Header)) || '.' || BASE64URL(JWS Payload) || '.' || BASE64URL(JWS Signature)

Signature Validation and Decryption Steps

Once a Merchant receives the securedPayload that is encrypted and signed as indicated by the content-type set to “application/jwt” or “‘application/jose,” (format: JWS(JWE<JWS<Payload>>)). The Merchant (or PSP) will decrypt and validate the payload in the following manner:

1. Merchant, Distributor, or Technical Integrator shall validate the signature (Paze signed public key), and JOSE Header, if valid decode CLAIM and extract securePayload.
2. If valid decrypt the securePayload using their private key.
3. Merchant, Distributor, or Technical Integrator to extract the payload from CLAIM.
4. Merchant, Distributor, or Technical Integrator shall validate the signature (Paze signed public key), and JOSE Header, if valid decode the payload
5. Merchant, Distributor, or Technical Integrator to send the payment instrument and mapping data for payment processing.

Key and Certificate Exchange

As part of onboarding; Merchant will provide a self-signed RSA Certificate with 2048 bits and SHA256 and share its public key in PEM format below or through one of the options listed below. This certificate will be used to validate the signature and decrypt the encrypted payload returned by the:

• Merchant JavaScript Software Development Kit (SDK)
• Paze Mobile API Technical Requirements, and the
• Merchant B2B API

Hint: OpenSSL can be leveraged to create a self-signed certificate.

Share the signed certificate public key via one of the options:

• Option 1: Share the public key (.pem) format file via secure email to your Paze Implementation Manager
• Option 2: Share the well-known URL with key
• Option 3: Share within the Merchant Setup Form.
• Option 4: Select from an existing key from your Distributor or Technical Integrator.

Network Tokenization

As a wallet, Paze stores Consumer payment cards as network tokens, meaning that the number on a Consumer’s physical card, the Funding Primary Account Number (FPAN) is not retained by Paze. This helps to limit Consumer impact if an individual network token is compromised, since their card’s issuer can simply deactivate the single affected network token while keeping the original card and its other network tokens as-is. This also allows Paze, as the token requestor, to receive automatic updates from Payment Networks in the event of card reissuance.

Network token availability is not limited to Paze. A Merchant, or a payment service provider (PSP) acting on a Merchant’s behalf, may work directly with Payment Networks to exchange consumers’ FPANs for network tokens. This allows the Merchant and their consumers to access the aforementioned benefits of network tokenization.

Network tokenization is distinct from other forms of tokenization. A Merchant may contract with a PSP to fully delegate management of payment credentials. PSPs can store this data in compliance with payment card industry (PCI) standards and generate a proprietary token for Merchants to reference, thereby preventing Merchants from needing to develop their own PCI-compliant systems.

A nuance of PCI compliance is that since network tokens and their associated data have the same structure as FPANs, automated auditing systems may flag them in a database as non-compliant. As a result, a Merchant may have a network token but still request that their PSP tokenize that value once more. PSP tokens are generally distinct in structure from FPANs.

The following diagram illustrates which entity retains which data across three potential tokenization scenarios.

Implementation Effort Estimation

Because the Paze Service includes several optional features, Merchants and their PSPs will have varying amounts of work required to complete an integration.

The following table below provides yes/no questions that can indicate a Merchant or PSP’s effort required to integrate with Paze, with “yes” answers requiring significantly less development than “no” answers. In most cases, the answer to the functional question is a suitable proxy for the answer to the technical question.

The Incremental Development column assumes that all preceding questions have been answered with “yes.”

Implementation Effort Estimation**

Even if a PSP supports all the above services, Merchants should confirm if their particular contractual agreement includes those offerings.

Multiple Transactions with the Same Authorization

Consumer-Initiated Transactions (CIT) where the Consumer actively participates in a purchase are supported directly through the Paze Service, or by relying on the Merchant as stated below.

Paze supports a unique solution for Merchant retention of Consumer payment cards on file. Typically, retaining a card on file means keeping the Consumer’s FPAN in a PCI-compliant fashion or working with the respective Payment Network to generate a network token from the FPAN. With Paze, Merchants can exchange the network token received from Paze for their own network token.

The following processes describe how to use Paze to enable a credential on file when a Merchant has received consent from the Consumer to store payment data for subsequent purchases. Data provided by Paze can be exchanged with the appropriate Payment Network for a dedicated Merchant network token, which will operate within the guidelines of that service.

Requirement: In order to obtain a credential on file, a Merchant must participate directly or indirectly as a token requestor with the applicable Payment Network Token Service Provider (e.g., Mastercard Digital Enablement Service (MDES), Visa Token Service (VTS)). Discover does not offer a service to enable a credential on file for Discover cards received from Paze. Aside from providing the required payment token, cryptogram and dynamic data, Paze does not participate in establishing a Consumer’s credential on file with a Merchant. This section is provided solely for Merchants’ reference and is recommended to be provided to their PSPs where applicable.

Note: The Payment Network resources provided below are subject to change at each Payment Network’s sole discretion. Refer to their respective developer documentation for the latest technical requirements.

Mastercard Tokenization

For Mastercard tokens, refer to:

• https://developer.mastercard.com/mdes-digital-enablement/documentation/ for a simple tokenization API
• https://developer.mastercard.com/mastercard-checkout-solutions/documentation/use-cases/card-on-file/ for a tokenization platform

For additional details, contact [email protected]

Use the following data to populate the request parameters:

MDES

tokenRequestorId`: the Merchant’s token requestor identifier with Mastercard
`accountNumber`: token received from Paze
`expiryMonth`: `panExpirationMonth`received from Paze`expiryYear`: `panExpirationYear`received from Paze`source`: “Existing Credentials”
`securityCode`: `dynamicData\` value received from Paze

SCOF

serviceId`: the Merchant’s token requestor identifier with Mastercard
`primaryAccountNumber`: token received from Paze
`panExpirationMonth`: `panExpirationMonth`received from Paze`panExpirationYear`: `panExpirationYear`received from Paze`cardSource`: “Existing Credentials”
`cardSecurityCode`: `dynamicData\` value received from Paze

Note: Distinct Mastercard cryptograms are used for a Payment Transaction authorization (20-byte cryptogram) and its subsequent tokenization request (3-digit cryptogram). A Merchant can use the Paze Merchant B2B API to request the 3-digit cryptogram within ten calendar Days of the consumer authentication event.

Visa Tokenization

For Visa tokens, refer to https://developer.visa.com/capabilities/vts.

Use the following data to populate the request parameters:

clientAppID`: the Merchant’s Token Requestor identifier with Visa
`clientDeviceID`: ECOM
`clientWalletAccountID`: the intifier that the Merchant will use to identify the Consumer when they next visit the Merchant’s website
locale: en_US
protectionType: CLOUD
panSource: TOKEN_FOR_TOKEN
`encPaymentInstrument`: token received from Paze
`name`: fullName received from Paze
`expirationDate`: ExpirationDate object containing the panExpirationMonth and panExpirationYear received from Paze
`billingAddress`: BillingAddress object received from Paze
`presentationType: ECOM\`

Miscellaneous

Card Display

After a Consumer selects the card that they wish to use for a Payment Transaction, Paze provides Merchants with the card art in rectangular form. Merchants are advised to apply styling, such as corner rounding, by referring to ISO/IEC 7810 standards for the ID-1 format.

Display Name Length

Merchants may have their display names truncated or otherwise display incorrectly if they are longer than a certain number of characters. The following is a non-exhaustive list of user interfaces that may be impacted by the length of merchant names.

Merchant Display Name Limits

Stubbed Authentication Values

Email Address Stubbed Authentication Values

Phone Number Stubbed Authentication Values

OTP Stubbed Stubbed Authentication Values

CVV Stubbed Stubbed Authentication Values

Appendix A: Consumer Experience

First-Time User

Returning User