Card Issuing and Management Technical FAQs

The card's expiry date is determined by the default card validity period specified for your card product during programme setup. There are two types of expiry dates that can be set up in our system:

• The expiry date to be printed on the card

• An internal system expiry date, which relates to how long the card record remains valid for after it is activated.

For more information, see the Physical Cards Guide: Generated Card Elements> Calculating the Expiry Date.

Yes, as with physical cards, virtual cards also have an internal system expiry date, which is determined by the default card validity period specified for your card product during programme setup. For more information, see the Virtual Cards Guide: Virtual Card Setup.

Yes, when creating or updating a card, you can override the default product-level expiry date value. Note that this only applies to the internal system expiry date and not to any expiry date already printed on a physical card.

• Using Web Services — specify the new date in the ExpDate field of the Card Create web service.

• Using Cards API (REST) — specify the new date in the expiryDate field of the Create Card API.

After card creation, you can use the Card Activate web service to update the expiry date at the time of card activation.

If using the Cards API, the equivalent API is Update Card to update the expiry date.

Offline chip limits are embedded directly into the chip profile. The chip profile is approved by the Card Scheme after testing. Offline card limits are typically low in order to reduce the risk of fraud. Thredd cannot increase or decrease the limits stored on the chip, because they are configured at the chip level by the card manufacturer. To increase or decrease the limits, you need to update your chip profile.

For more information, see the Chip Parameters Guide.

After a request for a card file has been sent to the manufacturer, it cannot be cancelled. However, you can destroy the tokens and issue new ones.

For more information on the card file generation process, see the Card Generation Interface Specifications: About the Card Generation File.

Only cards with one of the statuses 00, 02, or G1 are included in the card file for the card manufacturer.

For more information, see the Card Generation File Specification Guide.

The PaymentTokenUsageGroup is used to define the rules around digital wallet tokenisation for your card product. Thredd makes provisioning decisions on the card based on the PaymentTokenUsageGroup configuration options set for your programme. You will need multiple Payment Token Usage Groups set up on your programme, to link to configuration options for each Wallet Provider (e.g., Google, Apple) that you want to make available for the card. For more information, see the Tokenisation Guide..

In the Card Enquiry (Ws_Enquiry) and Customer Enquiry (Ws_Customer_Enquiry and Ws_Customer_Enquiry_V2) APIs, <PaymentTokenUsageGroup> contains an alphanumeric response of up to 50 characters. This comprises the unique 3-digit numeric code assigned to the payment token usage group at the time of creation and a description of the payment token usage group. For example: 123-Company XYZ Full VDEP.

<ProductID> is the identifier of your card product, or the Product ID, within Thredd. For details, check with your Implementation Manager.

<CrdProduct> is the Scheme name. For example, Visa, Mastercard or Discover.

The web services WSDL file enables schema validation of Web Services. The latest WSDL file is available to download from the Downloads page.

The address object contains the cardholder's address and is used for AVS (address verification service). The fulfilment object is used only for physical cards when the delivery address of the physical card is different from the cardholder's address.

When creating cards, customerReference is used to specify an account number or reference number. It is also used to query cards on Thredd Portal Thredd Portal is Thredd's new web application for managing your cards and transactions on the Thredd Platform. or Smart Client Smart Client is Thredd's legacy desktop application for managing your account on the Thredd Platform..

For physical cards, customerReference is passed to the card manufacturer in the card file.

Cardholder details are stored at a card level. If a cardholder has many cards, the details of each card need to be updated separately.

Typically only the cardholder's Mobile (for 3D Secure) and Address (for physical card delivery) need updating. Other fields such as dateOfBirth and email are not used for any processing or validation by Thredd.