Welcome to our new developer portal! Use the "Ask" button to chat with our AI Agent.
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Retrieve profiles by D1 SDK

Overview

This page explains how the issuer application can retrieve Click to Pay profiles by using the D1 SDK.

The issuer application calls getProfiles (Android / iOS) API which triggers the same backend retrieval behavior as the issuer backend calling the Click to Pay get consumer profiles API.

Use this SDK flow when you want to display the current Click to Pay profile data directly in the issuer application, for example before allowing the end user to update profile details or opt out a card.

Flow

The SDK retrieve-profiles flow follows these steps:

  1. The issuer application initializes D1 SDK and logs in the end user.

  2. The issuer application calls the Click to Pay retrieve-profiles operation.

  3. D1 sends the request to the D1 backend by using the authenticated end user context.

  4. The D1 backend queries the configured Click to Pay directories.

  5. D1 aggregates the result and returns at most one profile per payment network to the issuer application.

Sequence diagram

The SDK flow has the same functional behavior as the backend retrieve-profiles flow, but it is initiated directly from the issuer application.

For the detailed sequence diagram, refer to Retrieve Click to Pay profiles.

Key points

  • This is a asynchronous operation. The issuer application receives the current profiles directly in the callback or returned result.

  • The response contains a ProfileResult.Profile collection. Each entry represents one Click to Pay profile in one payment network directory.

  • If several Click to Pay directories are configured, D1 consolidates the profiles into one response.

  • If the end user exists in D1 but is not enrolled in Click to Pay, the operation returns an empty list.

  • Use this flow when the issuer application must show the current Click to Pay State before calling Enroll cards in Click to Pay or Opt out cards from Click to Pay.

Treat an empty profile list as a valid functional result.

It usually means the end user is known in D1 but has no Click to Pay profile yet.

Response handling

The issuer application should expect the following data:

  • scheme: the payment network directory for the returned profile.

  • consumerInfo: the current end user data stored in the Click to Pay directory.

  • cards: the list of cards associated with the Click to Pay profile for that payment network.

  • message: optional troubleshooting text returned when D1 can only provide a partial response.

Use the returned data to:

  • show the current Click to Pay enrollment state,

  • display which cards are available in each payment network directory,

  • prefill a profile update user interface, or

  • help the end user choose the right next action.

Handle Click to Pay push notifications

Unlike enrollment or opt-out, retrieving Click to Pay profiles does not require a dedicated push notification flow.

This operation returns the current result directly to the issuer application. No asynchronous completion event is expected for the profile retrieval itself.

You can still keep Click to Pay push notifications enabled in the issuer application for other operations, such as enrollment or opt-out. For the implementation details, refer to Handle Click to Pay push notifications.

SDK API

The getProfiles (Android / iOS) API is available through D1 SDK.

Use the returned profile data as the source for the issuer application user interface.

Do not assume that every payment network returns a profile for the end user.

Last updated

Was this helpful?