# Account Identifiers
source: https://developer.mastercard.com/user-account-management-service/documentation/use-cases/account-identifiers/index.md

## Create and map partner identifier details {#create-and-map-partner-identifier-details}

This use case describes how validated partner identifier details are created and mapped to a cardholder's primary account. A unique reference ID is generated for the membership and returned to the third-party vendor.

### Pre-requisites {#pre-requisites}

Following are the pre-requisites for the cardholder to use this flow:

* The third-party website is embedded in the bank website.
* The third-party vendor is integrated with the issuer channel and Mastercard.

### Sequence diagram {#sequence-diagram}

Diagram map-partner-identifier

#### Following are the execution steps: {#following-are-the-execution-steps}

1. The cardholder enters membership information (partner identifier details) on the bank website.
2. The embedded third-party website (within the bank website) shares the partner identifier details to the third-party vendor.
3. The third-party vendor sends the partner identifier details to the applicable external loyalty provider.
4. The external loyalty provider validates the request.
5. The external loyalty provider sends the response to the third-party vendor.
6. If validation fails, the third-party vendor presents an error on the bank website and does not call User Account Management.
7. The bank website displays error to the cardholder and prompts for correction.
8. After successful validation, the third-party vendor calls User Account Management to enrol and map the membership.
9. User Account Management creates and maps the partner identifier details to the applicable identifier type and primary account and also generates a unique Reference ID for the membership record.
10. User Account Management returns the Reference ID to the third-party vendor.
11. The third-party vendor confirms successful enrolment through the bank website.
12. The bank website displays successful enrolment to the cardholder.

Note:   

* Partner identifier details are stored only after successful validation.
* No data is stored if validation fails.
* Partner identifier details are always anchored to the primary account.

### Endpoint {#endpoint}


API Reference: `POST /accounts/identifiers`

## Update partner identifier details {#update-partner-identifier-details}

This use case describes how an existing membership mapping is updated in User Account Management. The update can change the membership identifier or supported personal information, such as first name, last name, prefix, or suffix. The existing Reference ID is reused and no new Reference ID is created.

### Pre-requisites {#pre-requisites-1}

Following are the pre-requisites for the cardholder to use this flow:

* A membership mapping already exists in User Account Management.
* The third-party vendor has the existing Reference ID.
* When membership details change, the third-party vendor can validate the changed details with the applicable external loyalty provider.

### Sequence diagram {#sequence-diagram-1}

Diagram update-partner-identifier

**Following are the execution steps:**

1. The cardholder enters updated membership or personal information through the bank website.
2. The embedded third-party website (within the bank website) shares the updated information to the third-party vendor.
3. If the membership identifier changes, the third-party vendor validates the changed details with the external loyalty provider.
4. If validation fails, the third-party vendor presents an error and does not call User Account Management.
5. If validation succeeds, or if only supported personal information changes, the third-party vendor calls User Account Management with the existing Reference ID and updated values.
6. User Account Management updates the existing membership mapping.
7. User Account Management returns the existing Reference ID to the third-party vendor.
8. The third-party vendor confirms the update through the bank website.
9. The bank website displays updated information.

Note:   

* The update can originate from a digital channel or another authorized channel, but the User Account Management API flow remains the same.
* The existing Reference ID must be used for the update.
* No new Reference ID is created.
* Supported updates include the membership identifier and supported personal information fields.

### Endpoint {#endpoint-1}


API Reference: `PUT /accounts/identifiers`

## Retrieve partner identifier details {#retrieve-partner-identifier-details}

This use case describes how a third-party vendor retrieves previously stored partner identifier details already stored in User Account Management. Retrieval can use the search criteria comprising the RANAC value and the applicable loyalty provider.

### Pre-requisites {#pre-requisites-2}

Following are the pre-requisites for the cardholder to use this flow:

* A membership mapping already exists in User Account Management.
* The third-party vendor is authorized to retrieve the membership information.

### Sequence diagram {#sequence-diagram-2}

Diagram retrieve-partner-identifier

**Following are the execution steps:**

1. The cardholder accesses the membership information (partner identifier details) from the bank website.
2. The embedded third-party website (within the bank website) requests for the partner identifier details from the third-party vendor.
3. The third-party vendor initiates a retrieval request.
4. The third-party vendor calls the User Account Management retrieval API using:
   * RANAC
   * Loyalty Provider
5. User Account Management searches for matching membership mappings.
6. User Account Management returns the following information to the third-party vendor:
   * Membership details
   * Existing Reference ID
7. The third-party vendor sends the response to the bank website.
8. The bank website displays the membership details and Reference ID to the cardholder.

Note:   

* Only partner identifier details that were previously validated and stored are returned.
* Partner identifier details are always retrieved at the Primary Account level.

### Endpoint {#endpoint-2}


API Reference: `POST /accounts/identifiers/searches`