Customer Creation

Key Points

• CCG uses three primary identifiers: enterpriseId, hsid, and mcid
• Identification follows a strict precedence order to ensure consistency
• Enterprise wallets enable a unified customer experience across merchants
• Local wallets are created when enterprise identification is not possible but can be shared within merchant groups

Who is a Customer?

• Customers are authenticated users, who have a wallet with the Convenient Checkout system.

Overview

CCG (Convenient Checkout Gateway) creates and manages customer records using multiple identifiers to ensure accurate mapping and a seamless experience across merchants and channels. The primary identifiers are:

• hsid (HealthSafe ID)
• enterpriseId (Enterprise Identity)
• mcid (Merchant Customer Identifiers)

important

Customer creation requires at least one primary identifier; if none is provided, the process cannot continue.

Primary Identifiers

1. enterpriseId: A global identifier representing a consumer's enterprise identity. This enables CCG to consolidate all wallets and payment methods for a customer across all merchants, providing a unified experience and supporting enterprise wallet upgrades.
   Example: "enterpriseId": "603041336"

2. hsid: HSID (HealthSafe ID) is the authentication (credentials) method developed by UHG for authenticating users for websites and mobile applications.
   Format: uuid (Universally Unique Identifier)
   Example: "hsid": "123e4567-e89b-12d3-a456-426614174000"

3. merchant customer identifiers (mcid): Merchant-specific identifiers (such as patientId, subscription ID, dependent code, exchange ID, etc.) that allow merchants to uniquely identify their customers within their own systems. CCG supports multiple mcids per customer, as defined by each merchant's configuration.
   Example: "patientId": "222333444", "subscriberId": "ABC789"

Types of Wallets

CCG supports two types of wallets to accommodate different customer identification scenarios:

1. Enterprise Wallet: Created when a customer can be identified with EIMP using enterpriseId or hsid or merchant-specific identifiers (mcid) . This wallet type enables customers to have a unified payment experience across multiple merchants within the enterprise.

2. Local Wallet: Created when a customer can only be identified using merchant-specific identifiers (mcid) but cannot be matched to an enterprise identity. Local wallets can be shared across merchants that belong to the same merchant group, providing a consistent experience within that group.

Enterprise Wallet Upgradation

Local merchant wallets can be upgraded to enterprise wallets when additional identification is available. For details on how this process works, see the Enterprise Wallet Upgradation documentation.

Identification Precedence

The system follows a strict precedence order when identifying customers:

1. enterpriseId - Highest precedence, direct match to enterprise identity
2. hsid - Second priority, can be resolved to an enterpriseId
3. mcid - Uses merchant-specific identifiers with configurable matching rules defined in enterpriseSettings

For details on the enterpriseSettings configuration and how it affects customer identification with mcid, see Customer Look up Logic using enterpriseSettings.

---

Process Flow

Identification Process

1. Initial Request: Merchant sends customer data to CCG.
2. Identifier Evaluation:
   • First check for enterpriseId
   • If not present, check for hsid
   • If neither is present, use mcid with matching rules from merchant's enterpriseSettings
3. EIMP Lookup: Query the Enterprise Identity Management Platform (EIMP) to resolve identifiers
4. CCG Database Check: Determine if the customer already exists in CCG
5. Wallet Creation or Retrieval:
   • If customer exists in CCG, retrieve the existing wallet
   • If customer exists in EIMP but not CCG, create a new enterprise wallet
   • If customer does not exist in EIMP but has valid mcid, create a local wallet

Wallet Handling Logic

• Enterprise Wallet Creation: When a customer's enterpriseId or hsid matches an identity in EIMP
• Local Wallet Creation: When a customer cannot be matched in EIMP using mcid, or when multiple matching records are found
• Wallet Updates: When a customer already exists, the wallet is retrieved and updated with any new information
• Special Cases:
  • When a wallet needs to be made inactive, associated payment methods must be handled appropriately
  • When a customer has different identifiers across different merchants, the system may need to consolidate wallets

---

Customer Identification & Wallet Creation Workflow

View Identification Workflow Diagram

---

MCID Identification with Enterprise Settings

Enterprise Settings Configuration

When identifying customers using merchant customer identifiers (mcid), the system relies on the merchant's enterpriseSettings configuration. This configuration defines:

1. The specific merchant identifiers used for customer lookup
2. How these identifiers map to enterprise identity fields
3. Which fields are required vs. optional for a positive match
4. The precedence order for trying different identification strategies

For detailed information on how this works, see Customer Look up Logic using enterpriseSettings.

Local Wallet Creation Process

Local Wallet Creation Workflow

When a customer cannot be identified through EIMP (or when multiple/ambiguous matches are found), a local wallet is created. This process ensures merchants can still provide a consistent payment experience even when enterprise identification isn't possible.

Local wallets created for mcid-only customers are shared across merchants within the same merchant group.

---

Example Scenarios

Scenario 1: Customer with enterpriseId

• Request: Merchant sends a request with enterpriseId
• Process:
  1. System checks for the enterpriseId in EIMP and finds a match
  2. System checks for the enterpriseId in CCG and finds a match
  3. System retrieves the existing enterprise wallet
• Result: Returns existing enterprise wallet with updated customer information

Scenario 2: Customer with only hsid

• Request: Merchant sends a request with hsid
• Process:
  1. System checks for enterpriseId (not provided)
  2. System checks for hsid in EIMP and finds a match
  3. System checks for hsid in CCG but doesn't find a match
  4. System creates a new enterprise wallet linked to the hsid
• Result: Creates and returns new enterprise wallet

Scenario 3: MCID with Multiple Matches in EIMP

• Request: Merchant sends a request with mcid (e.g., patientId)
• Process:
  1. System checks for enterpriseId and hsid (not provided)
  2. System searches for mcid in EIMP using the criteria defined in enterpriseSettings
  3. System finds multiple matching records in EIMP, preventing conclusive identification
  4. System creates a new local wallet with the mcid
• Result: Creates and returns new local wallet shared within merchant group

Scenario 4: MCID with No Match in EIMP

• Request: Merchant sends a request with mcid only
• Process:
  1. System checks for enterpriseId and hsid (not provided)
  2. System searches for mcid in EIMP using enterpriseSettings but finds no matches
  3. System creates a new local wallet with the mcid
• Result: Creates and returns new local wallet shared within merchant group

Scenario 5: No Identifiers Provided

• Request: Merchant sends a request without any primary identifiers
• Process:
  1. System checks for enterpriseId, hsid, and mcid but finds none
  2. System returns an error response
• Result: Returns error with appropriate message and HTTP status code

---

Integration with Merchant Groups

The merchant groups concept is critical for local wallet functionality:

• Merchants within the same group can share local wallets
• A customer identified by mcid at one merchant can have their wallet reused at another merchant in the same group
• This enables scenarios like healthcare provider networks or related retail chains to provide a consistent customer experience