Customer Experience Enablers Technical FAQs

Yes, you can apply a temporary block on a physical card without impacting the token statuses if you have enabled the DPAN over FPAN status configuration option in the tokenisation configuration setup for your programme. For details, see DPAN over FPAN Status in the Tokenisation Guide.

No, you cannot transition mobile wallet tokens (DPANs) to a new physical card (FPAN). The DPAN must be set up by the cardholder using a token activation request, which results in a new DPAN being created that is linked to the FPAN. See the Tokenisation Guide: Token Provisioning.

This depends on the use case. If you want separate card controls or usage groups for physical versus mobile wallet usage, then an option might be to create two card records. as follows:

• Physical card — for use in stores, with its own card controls.

• Virtual card — which can be tokenised on a mobile device and have its own usage groups.

For more information, see the Virtual Cards Guide.

One Card Approach:

In the one card approach, the same card number (PAN) is used for both the physical card and the mobile wallet. However, you can still configure different controls for each usage type:

• You can assign different usage groups or control groups for mobile wallet transactions and physical card transactions.

• For example, you might allow higher transaction limits for mobile wallet payments due to their enhanced security (e.g., biometric authentication) while setting stricter limits for physical card usage.

• Using the Thredd platform, you can dynamically adjust controls based on the transaction source (e.g., mobile wallet vs. physical card). For example, you can block certain merchant categories or regions for physical card usage while allowing them for mobile wallet transactions.

• Mobile wallets use tokenised card details, which can be linked to specific controls. This allows you to apply unique rules for tokenised transactions without affecting the physical card.

Two Card Approach:

In the two card approach, separate PANs are issued for the physical card and the mobile wallet. This provides even greater flexibility in setting controls:

• Since the physical card and mobile wallet have distinct PANs, you can configure entirely separate controls for each.

• For example, you could enable international transactions for the mobile wallet while restricting the physical card to domestic use.

• Separate Reporting: Transactions for the physical card and mobile wallet are reported separately, making it easier to monitor and manage usage patterns for each.

• Risk Management: The two card approach allows for more granular risk management. For instance, you can deactivate the physical card while keeping the mobile wallet active, or vice versa.

Key Considerations:

• Security: Mobile wallets generally offer enhanced security features (e.g., biometric authentication, tokenisation), so you might want to allow more lenient controls for mobile wallet transactions.

• Customer Experience: The one card approach is simpler for customers, as they only need to manage one card. However, the two card approach offers more flexibility for issuers.

• Implementation: The one card approach requires careful configuration of usage groups and tokenisation settings, while the two card approach involves managing two separate card records.

Usually, a new Token Activation Request (ProcessCode = 330000) creates a new Payment Token with a new payment_token_id. However, if a Token Activation Request message arrives with the same digitisation_ref (Correlation ID) and creator (MC-MDES/VISA-T), and there is already a token in the table that is marked as deleted txn_status = D, then instead of creating a new token, the system reuses the existing payment_token_id and updates that record. This behaviour supports how Mastercard or Visa reuse digitisation references for deleted tokens.

Therefore, if you see multiple Token Activation Requests tied to the same payment_token_id, it is likely falling under that scenario.

Mastercard and Visa payment network token lifecycles include a period after deletion during which tokens are logically retained for transaction processing before being fully retired and potentially reusable. For example, MDES payment token identifiers may potentially be reused after a 95-day period. Check with your Scheme (MDES or VDEP) for details.