Card Management

General Overview

A Card in our system represents the cardholder’s physical or virtual card. These cards utilize funds provided by the linked Balance Account. It’s important to note that multiple Card resources can be created per Balance Account.

During the onboarding process for new clients, the organization must first onboard and upload information about its beneficial owner and control person, as described in the previous sections. This prerequisite ensures that necessary background checks and verifications are completed before cardholders, cards, and associated balance accounts can be created.

This structured approach helps maintain regulatory compliance and ensures that all necessary parties and accounts are properly established before card issuance. If you have any questions or need assistance with card management processes, our team is available to provide guidance and support. We’re committed to facilitating a smooth and compliant card management experience for your organization.

Create Cards

For detailed technical information, please refer to the “Create card” API documentation.

Cards are issued based on the associated Legal Entity of the cardholder applicant. The residential address country of the cardholder applicant will determine the available card products. The legal entity’s official name will determine the card name displayed on the card.

These cards can be physical and/or virtual. Virtual cards have the option to be converted to physical cards at a later stage through the Convert Cards process.

Upon creation, newly issued cards will have a status of NEW, which will automatically transition to ORDERED. This process triggers two events:

  • card.created (card = NEW)

  • card.updated (card = ORDERED)

If a manual activation flow is configured, the card must be activated (through the Activate Cards process) before it can be used for payments.

This structured approach ensures that cards are issued accurately and in alignment with regulatory requirements, providing a frictionless experience for cardholders. Should you have any questions or need assistance with card creation processes, our team is available to provide support and guidance. We’re dedicated to facilitating a smooth and efficient card issuance process for your organization.

Card Delivery Address

In accordance with the card program, a cardholder (legal entity) may have either a physical or virtual card associated with their account. Physical cards require a delivery address linked to the cardholder, whereas virtual cards do not need a delivery address.

In scenarios where no address is provided for a physical card, the residential address specified in the Legal Entity resource is utilized.

It’s important to understand that verifying the individual’s residential address through the Know Your Customer (KYC) process is essential for card delivery. The delivery address must either align with the residential address or be left empty. In cases where it’s null, the default residential address of the legal entity will be used as a fallback.

This rigorous approach enhances security and compliance with regulatory standards, safeguarding the integrity of the card issuance process. If you have any inquiries or require assistance with card delivery procedures, our team is available to provide support and guidance. We’re committed to facilitating a seamless and compliant card delivery experience for your organization.

Embossed Name

The name embossed on the card originates from the name submitted by the cardholder applicant or from the name on the submitted ID document. However, you have the option to override this default behavior by specifying the embossedCardHolderName attribute of the card.

For cards featuring multi-line embossed names, '\n' serves as the line separator.

It’s important to note that the embossed name is considered a protected detail of the card and therefore will not be returned by the cards API. However, it is accessible through the Card Image Visualization API documentation.

This approach ensures that the embossed name accurately reflects the cardholder’s information while maintaining confidentiality and security. Should you have any questions or require further information regarding embossed names on cards, our team is available to assist you. We’re committed to ensuring a seamless and personalized card issuance process for your organization.

Activate Cards

For detailed technical information, please refer to the “Activate a card” API documentation.

There are several available activation flows for cards:

  1. Active after creation: Cards are automatically activated upon creation.

  2. Manual activation with no additional validation parameters: Cards are activated manually without requiring additional validation.

  3. Manual activation with CVV validation: Cards require manual activation, with the additional step of validating the CVV.

  4. Manual activation with last four digits validation: Cards require manual activation, with the additional step of validating the last four digits of the PAN.

  5. Manual activation with access code validation: Cards require manual activation, with the additional step of validating the account holder’s access code

Please consult with your implementation manager to configure the appropriate card activation flow based on your specific requirements.

Upon activation, a card.updated event is triggered to indicate the change in status.

This flexibility in activation flows allows you to tailor the card activation process to best suit your organization’s needs and security preferences. If you have any questions or need assistance with configuring the card activation flow, our team is available to provide guidance and support. We’re dedicated to ensuring a smooth and secure card activation process for your organization.

Block / Unblock Cards

For detailed technical information, please refer to the below documentation:

Cards can be blocked either by us or by you, the client. Once blocked, a card can be subsequently unblocked.

We reserve the right to block cards according to our Terms and Conditions, which may include instances of fraud attempts or other suspicious activities.

You, as the client, have the authority to block cards based on your Terms and Conditions or in response to cardholder requests.

When a card is blocked, a card.updated event is triggered to reflect the change in status.

This capability to block and unblock cards provides flexibility in managing card security and addressing potential risks. If you have any questions or need assistance with blocking or unblocking cards, our team is available to provide guidance and support. We’re committed to ensuring the security and integrity of your card management processes.

Cancel Cards

For detailed technical information, please refer to the “Cancel a card” API documentation.

Cards can be canceled either by us or by you, the client. Once canceled, a card cannot be activated again.

We reserve the right to cancel cards according to our Terms and Conditions, which may include situations such as cardholder requests, loss, or theft.

You, as the client, also have the authority to cancel cards based on your Terms and Conditions or in response to cardholder requests, such as instances of lost or stolen cards.

Upon cancellation, a card can no longer be used or activated. This action ensures the security of the cardholder’s account and prevents unauthorized use of the card.

If you have any questions or need assistance with canceling cards, our team is available to provide guidance and support. We’re committed to ensuring the security and integrity of your card management processes.

Lost / Stolen

If a card is canceled due to loss or theft, a new card of the same type (physical or virtual) can be automatically generated and requested. By default, when cards are canceled for this reason, a replacement card is automatically ordered; however, this setting can be adjusted in the API or the Qenta Portal if a replacement is unnecessary.

If the new card is physical, it will be delivered to the same address as the previous card. You will receive details about the new card through a card-created event. The new card can be linked to the old one through the previousCardId attribute.

The process triggers the following events:

  1. card.updated (old card, status = CANCELLED)

  2. card.created (new card, status = NEW)

  3. card.updated (new card, status = ORDERED)

This automated process ensures that cardholders are promptly provided with replacement cards in the event of loss or theft, while also maintaining security and continuity of service. If you have any questions or need assistance with managing lost or stolen cards, our team is available to provide support and guidance. We’re committed to ensuring the security and integrity of your card management processes.

Change the Authentication Details

For detailed technical information, please refer to the “Update the cards authentication details” API documentation.

When changing authentication details, it’s important to note that updating the authentication phone number will also update the phone number used for 3DS (3-D Secure) authentication.

This ensures that the authentication process remains accurate and up-to-date, providing enhanced security for card transactions. If you have any questions or need assistance with changing authentication details, our team is available to provide support and guidance. We’re committed to ensuring the security and integrity of your authentication processes.

Card Features

For detailed technical information, please refer to the “Update the cards features” API documentation.

The following card features are implemented:

  1. ATM Enabled: This feature allows ATM withdrawals. It can be disabled by setting it to false, blocking ATM withdrawals.

  2. NFC Enabled (Tap and Pay, Contactless): NFC payments are enabled and are on by default. It can be disabled by setting it to false, blocking NFC payments.

  3. E-Commerce Enabled: This feature facilitates online payments, enhancing your platform’s versatility. It can be toggled on or off, providing control over e-commerce transactions.

    • 3DS (3D-Secure) Authentication: This security protocol verifies the identity of cardholders during online transactions, providing an additional layer of protection against fraud. Integrating 3DS makes e-commerce transactions more secure, mitigating the risk of unauthorized use and fraudulent activities.

  4. Digital Wallet Integration: Digital wallet integration allows users to link their payment cards to digital wallet applications, enabling convenient and secure transactions through mobile devices.

    • Push Provisioning: Card programs support Apple Pay, Google Pay, and Samsung Pay and cardholders can follow the standard Apple Wallet, Google Wallet, and Samsung Pay flows to enter their card details and load their cards. Additional steps are needed to enable push provisioning for Apple Pay and Google Pay.

    • Seamless Transactions: Users can make purchases in-store, online, or within apps by simply tapping their mobile device or using biometric authentication, streamlining the checkout process and eliminating the need to carry physical cards.

  5. Region Restriction:

    • No Restriction: Payments are not blocked due to regional aspects.

    • Region: Payments with merchants located outside the defined region (EU/EFTA and US) will be blocked.

    • Domestic: Payments with merchants located outside the issuing country will be blocked.

These features provide flexibility in controlling card usage and enhancing security based on specific requirements and preferences. If you have any questions or need assistance with configuring card features, our team is available to provide support and guidance. We’re committed to ensuring the security and integrity of your card management processes.

Card Limits

Limits are configured based on BIN (Bank Identification Number) requirements and your specific needs. If you require custom limits for your cards by default, please consult your implementation manager.

Limit configurations can be divided using the following criteria:

  1. Transaction Category:

    • ALL: Applies to any authorization.

    • CASH: Applies to ATM or cashback authorizations.

    • PURCHASE: Applies to other authorizations besides cash (including the purchase part of cashback).

  2. MCC (Merchant Category Code) List:

    • The limit calculation is restricted to the configured MCC list. If enabled and no list is provided, any MCC will be included in the calculation.

For each limit configuration, the following limits can be defined:

  • Daily limit

  • Weekly limit

  • Monthly limit

  • Yearly limit

  • Daily rolling limit

  • Weekly rolling limit

  • Monthly rolling limit

Both normal limits and rolling limits can be configured with the following parameters:

  • Enabled: Specifies whether the limit configuration is active or disabled.

  • Max Spending: Sets the maximum sum of all authorized amounts.

  • Max Transaction Count: Sets the maximum number of all authorizations.

Rolling limits also define the window size. For example, a daily rolling limit with a window size of four will consider the sum of transactions over the last four days, including the present day.

This comprehensive approach to limit configuration allows for precise control over card usage and spending, ensuring compliance with regulatory requirements and alignment with your organization’s specific needs. If you have any questions or require assistance with configuring card limits, our team is available to provide support and guidance. We’re committed to ensuring the security and integrity of your card management processes.

Convert Cards

For detailed technical information, please refer to the “Update the cards type” API documentation.

Virtual cards can be converted to physical cards. This conversion process is facilitated using the request object, as physical cards require a mandatory delivery address and support the usage of a PIN.

Upon card conversion, a new Card resource is created. The virtual and physical cards will share the same card number and have different CVV and expiry dates if the conversion occurs in a different month than the virtual card creation. If the conversion occurs in the same month, the CVV and expiry dates will be identical.

Both the virtual and physical cards will be active and usable by the cardholder with their unique details (CVV and expiry date). Once the physical card is activated, the virtual card will be automatically canceled.

It’s important to note the following:

  • As both cards share the same card number, certain operations will affect both card resources, including block/unblock, cancel, and change of authentication phone number.

The conversion process triggers the following events:

  1. card.created (new card, status = NEW)

  2. card.updated (new card, status = ORDERED)

  3. card.updated (new card, status = ACTIVE, please see Activate Cards)

  4. card.updated (old card, status = CANCELLED)

This conversion functionality provides flexibility for cardholders to transition from virtual to physical cards as needed, while also ensuring seamless management of card resources. If you have any questions or require assistance with card conversion processes, our team is available to provide support and guidance. We’re committed to ensuring a smooth and efficient card management experience for your organization.

Card Image Visualization

We do not host card images ourselves. Please consult your implementation manager regarding the image file to use and host on your system.

To display the card image along with the card data we provide, an endpoint is available for fetching the image. This fetch operation should be initiated directly from the cardholder’s device. The data must not be routed through your system unless you are PCI DSS certified.

The fetch operation is unauthenticated and must be initiated from a trusted environment.

Our recommended flow is as follows:

  1. The cardholder initiates the process to view the card.

  2. You authenticate the cardholder (e.g., through fingerprint).

  3. You initiate the call from your backend.

  4. The data is fetched on the cardholder’s device and combined with the card image.

It’s important to note that card visualizations cannot be created for physical cards configured with a manual activation flow using card details (such as the last four digits) if they have not been activated yet.

By following this flow, you can provide cardholders with a seamless and secure experience when viewing their card details. If you have any questions or need further assistance with card image visualization, our team is available to provide support and guidance. We’re committed to ensuring a smooth and secure experience for both you and your cardholders.

Initiate a Visualization

For detailed technical information, please refer to the “Creates a card visualization” API documentation.

This operation involves an authenticated backend-to-backend call. It initiates the creation of a One-Time-Code (OTC), which is valid for 15 seconds.

The OTC serves as a secure token for initiating the visualization process. It ensures that only authorized parties can access and display the card details.

By generating an OTC through this backend-to-backend call, you can facilitate the visualization process securely and seamlessly. If you have any questions or need assistance with initiating a visualization, our team is available to provide support and guidance. We’re committed to ensuring the security and integrity of your card management processes.

Fetch the Card Data / Show the Image

For detailed technical information, please refer to the “Represents the card data of a card visualization” API documentation.

This operation involves an unauthenticated call that must be made from the cardholder’s device. It requires the use of the same deviceId as used for the initiate call, along with the provided One-Time-Code (OTC) from the initiate call response.

The card data fetched through this call should be combined with the card image and displayed to the cardholder.

It’s important to note the following conditions for a valid fetchCardData call:

  • The OTC (One-Time-Code) and deviceId must match those provided during the initiate call.

  • The call must be made within 15 seconds of the initiate call.

  • The call must be done the first time.

By adhering to these conditions and combining the fetched card data with the card image, you can provide a secure and seamless experience for cardholders when viewing their card details. If you have any questions or need assistance with fetching card data and displaying the card image, our team is available to provide support and guidance. We’re committed to ensuring a smooth and secure experience for both you and your cardholders.

Card Name

When specifying multi-line card names on your cards, please use '\n' as the line separator. This ensures that the card name is displayed correctly with the appropriate line breaks, enhancing readability and visual appeal.

If you have any questions or need further assistance with card naming conventions, our team is available to provide support and guidance. We’re committed to ensuring that your card designs align with your branding strategy and enhance the overall user experience.

Investigate Problems/Results

For detailed technical information, please refer to the “Represents a card visualization” API documentation.

Use the GET API to observe and track the status of the initiated visualization. This API provides details on whether the visualization was successfully retrieved and the frequency of retrievals.

By accessing this API, you can effectively investigate any issues or discrepancies related to the visualization process. It enables you to monitor the success rate and usage patterns of visualizations, allowing you to identify and address any potential problems or concerns.

If you encounter any issues or need further clarification on the results obtained from the GET API, our team is available to provide support and guidance. We’re committed to ensuring that the visualization process operates smoothly and efficiently for both you and your cardholders.