A card serves as the actual payment instrument. Cards can take many forms: They can be plastic, virtual or tokenised elements that work though a variety of devices, like smart watches, mobile phones and rings.
Regardless of the form of the payment instrument, they are all considered cards.
There can only be one card entity per card number. The card is linked to an account and a customer. The card holds data related to the card, like card specific usage limiters and card delivery type. Similar to an account product, a card product is also predefined during implementation.
Any card product specific features like allowed transaction types, fee types, usage limiter types, BIN range and expiration period are automatically applied when a card is created via API.
Here’s a list of card level data:
customerId
) and account to which it is linked to (accountId
)
cardID
is the Enfuce database ID for the card that is used for updates and as the main identifier in API and Data Export Files.PAN
) (maskedCardNumber
)
expiration
)
pinStatus
)
segment
) (optional service)
pinAddress
)
cardAddress
)
status
)
usageLimits
, regionAndEcommBlocking
)
Regardless of whether the card is physical or virtual, it can be tokenised. Tokens allow the card to be utilised through digital wallets.
When a card is created, it’s linked to an existing customer and account. A detailed guide on how to create a card can be found here. It should be noted that the Card API has different endpoints for creating cards depending on if the card to be created is a Visa or a Mastercard branded card and whether it is physical or virtual.
The required data when creating a card is limited to:
(**customerId**, **accountId**)
**cardRole**
)**firstName, lastName**
)The Card API has additional fields that can be used to convey more embossing lines for the embossing house or, if several card designs are used, to inform which plastic template should be used for specific order. Potential use of the optional fields available in the Card API should be separately agreed upon and aligned on during the implementation phase.
When Enfuce receives the card creation request, the system creates a card entity and links it to the account and customer defined in the request. The card information received (firstName, lastName, cardRole) in the creation request are captured and saved as part of the card data.
Both physical and virtual cards are available for use instantly. This means that card details (PAN#, expiration date and CVV) used for e-commerce purchases can be viewed right after the card is issued. Also both physical and virtual cards can be enrolled to digital wallets (e.g. Apple Pay or Google Pay) right after the card is issued and is in use. It should be noted that if a physical card has an initial block, it needs to be removed before the physical card is in use (activate plastic via API call).
More about plastic status can be found in the below paragraph Plastic statuses.
Card statuses present the status of a card at any point of time. The card level statuses are used to determine the status of a single card contract, i.e. card number. A single card contract status does not impact other cards linked to the same account or the account itself, but only the single card. The following card statuses are in use:
Code | Status | Description |
---|---|---|
00 | Card OK | Card is open and in normal status. Potentially suspended tokens linked to card are activated when status is set. |
05 | Card Blocked | Temporary block on the card that will prevent approval of authorisations. Can be used instead of account level temporary block if the goal is to block only a specific card. Tokens linked to card are automatically suspended when status is set. Card status is automatically updated to “Card blocked” when account status is set to “Account to close”. |
205 | Suspected fraud | Temporary block on the card that will prevent approval of authorisations. Functionality the same as for “Card blocked”, the different code allows to differentiate between the blocks. |
04 | Card closed due to fraud | Used to close a card due to known fraud. Changing card to this status will trigger an EMV script if the physical card is used, which means that the chip will be blocked permanently. It will also close possible tokens and inform merchants automatically that card has been closed (VAU/MABU services). Due to this the status is final and can’t be reverted to Card OK anymore. |
41 | Card lost | Used to close a card in case it is lost. Changing card to this status will trigger an EMV script if the physical card is used, which means that the chip will be blocked permanently. It will also close possible tokens and inform merchants automatically that card has been closed (VAU/MABU services). Due to this the status is final and can’t be reverted to Card OK anymore. |
43 | Card stolen | Used to close a card in case it is stolen. Changing card to this status will trigger an EMV script if the physical card is used, which means that the chip will be blocked permanently. It will also close possible tokens and inform merchants automatically that card has been closed (VAU/MABU services). Due to this the status is final and can’t be reverted to Card OK anymore. |
105 | Card closed | Used to close card by request from customer or issuer. Tokens linked to card are automatically deactivated when status is set. Cards are automatically updated to this status when account is set to Auto-Closed. |
14 | Card invalid | Final card closure status, that blocks also clearing transaction posting. |
50 | Card no renewal | Set to cards that are not expected to be renewed (e.g. passive cards). The existing card is valid until the end of the expiration time. |
Via the Account API, the issuer can define a reason for the status change. The reason can be used to differentiate between changes that are initiated by yourself and the ones initiated by your customer. The set reason is available in both View API as well as the data export card properties file.
The plastics are fully managed by Enfuce. While the card status represents the status of the card as a whole, Enfuce also keeps track of every physical manifestation, or plastic that has been produced of the card number. Every time a new physical card with the same number is generated, a new plastic is created in the Enfuce system. The core functionality is that Enfuce keeps track of which plastic, also called “sequence”, can be used and which can’t. The issuer can fetch the plastics with the cardID by using Get a list of plastics for given card. The following chapters will provide a more detailed description of each plastic status.
Status | Description |
---|---|
Active | The card is active and may be used to perform transactions. |
Inactive | The plastic is not yet produced. |
Closed | Status of old plastic after new plastic has been activated/used. |
Locked | Used if cards are sent with initial status locked and require activation. |
Based on the card product setup, the cards can be produced either as locked or active. Both locked and active indicate that the embossing process at Enfuce has been completed for the card and a PIN has been calculated. By default cards are produced as active which means that they are ready to be used immediately as well as enrolled to digital wallets. If card´s are produced as locked, the card cannot be used (authorisations are declined) nor enrolled to digital wallets before it’s activated via API call.
Considerations:
Plastic status inactive indicates that the embossing process at Enfuce has not been completed.
Considerations:
After the card creation, the issuer can change the customer’s contact details e.g. address or name when the plastic status is still inactive knowing that the changes will be taken to the card manufacturing with that current order. When the plastic status has changed to active or locked it means that the card has been sent to card manufacturing. In that case, contact details can be of course changed too, but then a new card order needs to be done.
Card order can be canceled as long as the plastic status is inactive, Update plastic
Closed plastic status is set when there is more than one plastic and the newer plastic has been used/activated.
Customer’s name has changed and a new card with a new name has been reissued (=new plastic created):
Next night, Enfuce runs embossing and the plastic statuses will change. After the embossing run, the new plastic has status active to indicate it is in use. The old plastic’s status has changed from active to closed indicating it is not the latest plastic in use anymore.
Although the old plastic with sequence number 1 is now closed, the cardholder may continue to use the plastic until the new plastic with sequence number 2 arrives and is taken into use.
Use case | Plastic status | |||
---|---|---|---|---|
Inactive | Active | Locked | Closed | |
Card embossing process as Enfuce has been completed | N | Y | Y | N/A |
Card can be used for purchases | N | Y | N | Y |
Card can be enrolled to digital wallets | N | Y | N | Y |
Instant issuing means that physical card product´s virtual form can be instantly in use. After the card onboarding, customers can enroll the card in digital wallets or start using the card credentials in e-commerce transactions immediately. This will make the onboarding journey smoother and create a more convenient user experience – no need to wait to start paying with a new card.
The default for Enfuce issuers is that physical cards can be used instantly by enrolling them to digital wallets or using the card credentials for e-com purchases. In order to enable instant usage, there will be two plastic IDs created – one as inactive and one as active. The first plastic is the virtual form and the second plastic ID is the physical card that will be manufactured.
Here is an example of how the plastic statuses will look like when a card that can be instantly in use is created:
There is one plastic as inactive and one as active. The embossing process for the inactive plastic with sequence number 2 has not yet completed so there is no PIN calculated for that card. On the following night when Enfuce will run embossing, the plastic statuses will be changed as follows:
The PIN code is personal to the card, consisting of 4 numerical digits, and is used during card present transactions, i.e. when the physical card is inserted in or swiped at a physical terminal. The lifecycle of the PIN code consists of:
Each physical card created will have a PIN code, and it will either be a random PIN or set by the cardholder using the Set PIN API.
PIN distribution can be either by a PIN letter and distributed physically, or delivered digitally to the card holder. Alternatively, both of these options can be used in combination.
Card embossing refers to the manufacturing process of physical cards. During the card embossing, Enfuce shares relevant data to the embosser. This data is then saved onto the magnetic stripe, EMV chip and the visible parts of the physical card, i.e plastic template/picture and the names/text embossed on the card.
The process is initiated when a card plastic is created in Enfuce system. There are multiple use cases that trigger the manufacturing of a new plastic card:
As the plastic is created, it is simultaneously marked to be included in the embossing process. Enfuce runs the embossing process every day at approximately 03:00 UTC. We generate embossing files that are encrypted before placed on the SFTP server from where the embossing house will process it. Embossing files are created per institution and contain all cards that have been marked for production since the previous run. Enfuce has standard embossing file formats (.xml and .json) that are used with embossing partners.
The data included in the embossing file is generated by Enfuce (e.g. PAN, expiration date, PIN) and partly provided by the issuer. Enfuce supports the issuer through giving the following information through the API and forwarding it to the embosser:
manufacturer
: Enfuce can support a multi-manufacturer setup where some cards are sent to one manufacturer and some to another e.g. based on the geographic location of the customer. Information on who should manufacture the card should be provided in the card creation request.
externalLayoutCode
: If there are multiple card layouts at the embosser, it is possible to store the information and Enfuce will include information of the chosen one in the embossing file. If only one layout is defined, this information is not needed.
companyName
: Name of the company to which the card belongs to. The length is limited to 26 characters to ensure fit on the card. If the name cannot be fit to 26 characters, the issuer should abbreviate the name. There is no standard as to how the name should be abbreviated and issuer can use own consideration.
There is a default set of characters that are supported when card is embossed (i.e. stamped) as well as an extended set of characters available for issuers that use laser overlay that allows for laser printing. Issuer should align with embosser and Enfuce on the supported character set. Enfuce supported characters are available in the API description.
firstName
: First name of the cardholder. The length is limited to 26 characters to ensure fit on the card. If the name cannot be fit to 26 characters, the issuer should abbreviate the name. There is no standard as to how the name should be abbreviated and issuer can use own consideration. One option is to abbreviate first name and keep last name complete e.g. “J. CARSON”.
There is a default set of characters that are supported when card is embossed (i.e. stamped) as well as an extended set of characters available for issuers that use laser overlay that allows for laser printing. Issuer should align with embosser and Enfuce on the supported character set. Enfuce supported characters are available in the API description.
lastName
: Last name of cardholder. The length is limited to 26 characters to ensure fit on the card. If the name cannot be fit to 26 characters, the issuer should abbreviate the name. There is no standard as to how the name should be abbreviated and issuer can use own consideration. One option is to abbreviate first name and keep last name complete e.g. “J. CARSON”.
There is a default set of characters that are supported when card is embossed (i.e. stamped) as well as an extended set of characters available for issuers that use laser overlay that allows for laser printing. Issuer should align with embosser and Enfuce on the supported character set. Enfuce supported characters are available in the API description.
additionalField1 / additionalField2 / additionalField3 / additionalField4 / additionalField5
: These fields can be used instead of the “Name” fields or in addition to them, depending on how many lines are supported on the plastic card. The additional fields have the same logic as the “Name” fields (length, characters supported), but if an actual name is not printed on the card, these fields enable not needing to store e.g. “Vehicle 1” type of information in name fields in the system. Usage of additional fields and the number of lines embossed and possible additional layouts need to be aligned with Enfuce and the card embosser.
Note that the embossing data is only relevant for physical cards and the information is not automatically reflected in virtual card designs.
Card printing refers to the manufacturing process of physical cards. During the card printing, Enfuce shares relevant data to the embosser/card manufacturer. This data is then saved onto the magnetic stripe, EMV chip and the visible parts of the physical card, i.e plastic template/picture and the names/text are printed on the card. The process starts when a card plastic is created in the system. There are multiple use cases that trigger the manufacturing of a new card:
When the plastic card is created, it is simultaneously marked to be included in the printing process. Enfuce runs the embossing process every day at approximately 03:00 UTC. We generate embossing files that are encrypted before being placed on the SFTP server from where the embossing house/card printer will process it. These files are created per institution and contain all cards that have been marked for production since the previous run. Enfuce has standard embossing file formats (.xml and .json) that are used with card printers.
The data included in the embossing file is generated by Enfuce (e.g. PAN, expiration date, PIN) and partly provided by yourself. Enfuce supports you by giving the following information through the API and forwarding it to the embosser or card printer:
**manufacturer**
: Enfuce can support a multi-manufacturer setup where some cards are sent to one card manufacturer and some to another e.g. based on the geographic location of the customer. Information on who should manufacture the card should be provided in the card creation request.
externalLayoutCode
: If there are multiple card layouts at the manufacturer, it is possible to store the information and Enfuce will include information of the chosen one in the embossing file. If only one layout is defined, this information is not needed.
**companyName**
: Name of the company to which the card belongs to. The length is limited to 26 characters to ensure it fits on the card. If the name cannot be fit to 26 characters, the name needs to be abbreviated. There is no standard as to how the name should be abbreviated so you and your customer can use your own consideration and preference.
There is a default set of characters that are supported when card is embossed (i.e. stamped) as well as an extended set of characters available for issuers that use laser overlay that allows for laser printing. You need to align with the embosser and Enfuce on the supported character set. Enfuce-supported characters are available in the API description.
**firstName**
: First name of the cardholder. The length is limited to 26 characters to ensure fit on the card. If the name cannot be fit to 26 characters, the name needs to be abbreviated. There is no standard as to how the name must be abbreviated so you and your customer can use your own consideration and preference. One option is to only print the first initial of the first name, e.g. “J. CARSON”.
There is a default set of characters that are supported when card is embossed (i.e. stamped) as well as an extended set of characters available for issuers that use laser overlay that allows for laser printing. You need to align with the embosser and Enfuce on the supported character set. Enfuce-supported characters are available in the API description.
**lastName**
: Last name of cardholder. The length is limited to 26 characters to ensure fit on the card. If the name cannot be fit to 26 characters, the name needs to be abbreviated. There is no standard as to how the name must be abbreviated so you and your customer can use your own consideration and preference. One option is to only print the first initial of the first name, e.g. “J. CARSON”.
There is a default set of characters that are supported when card is embossed (i.e. stamped) as well as an extended set of characters available for issuers that use laser overlay that allows for laser printing. You need to align with the embosser and Enfuce on the supported character set. Enfuce-supported characters are available in the API description.
**additionalField1 / additionalField2 / additionalField3 / additionalField4 / additionalField5**
These fields can be used instead of the “Name” fields or in addition to them, depending on how many lines are supported on the plastic card. The additional fields have the same logic as the “Name” fields (length, characters supported), but if an actual name is not printed on the card, these fields enable not needing to store e.g. “Vehicle 1” type of information in name fields in the system. Using additional fields and the number of lines embossed and possible additional layouts need to be aligned with the card printer.
Note that the embossing data is only relevant for physical cards and the information is not automatically reflected in virtual card designs.
During the card lifecycle, there are times when a card has to be renewed, reissued or replaced. First, let’s align on the definition of each of these terms:
If a card is enrolled to a digital wallet, the card lifecycle events are also linked to the token lifecycle events. For more information see the digital wallets guide.
Card renewal is automatically triggered by Enfuce a set number of days prior to a card’s expiration. The default amount of days is 45. For example, if a card expires on 06/2022, Enfuce will trigger the renewal 45 days prior to the card expiry date 2022-06-30, i.e. 2022-05-16. Only cards that have the status ‘Card OK’ will be renewed.
When renewing the card, the card number (PAN) remains the same but the expiration date will increase and the card’s CVV2/CVC2 number will be regenerated. The PIN remains the same.
You can trigger a card (with OK status) to be reissued through the API (REISSUE_CARD). Usually, you would trigger this because the previous plastic being worn out or broken.
When reissuing the card, the card number (PAN), expiration date and CVV2/CVC2 number will remain the same (unless there is less than 2 months left of expiration). The PIN remains the same unless ‘set PIN’ is chosen during reissuing. This means that the customer will potentially need to update the card credentials for any recurring payment orders.
In cases where the card has been lost, stolen or there are other reasons to create a new card with a new number, the **REPLACE_CARD**
functionality is used. When triggering the replacement, the previous card status will be changed to Card Lost and a new card number will be created automatically. As REPLACE_CARD will change the status to LOST, the issuer is expected to change the previous card status to match what it was (for example Card stolen, Closed due to fraud).
As the card is replaced, it will remain linked to the same account and customer. Enfuce will generate a new card entity, which will get a new card number (PAN), expiration date and CVV2/CVC2. The PIN will be regenerated unless ‘set PIN’ is chosen during replacement.
Card production events refer to specific event during the card life cycle. Enfuce will trigger a notification when event changes. These events can be also seen via Get Card API (field: “productionType”) and in the DWH files.
Name | Code in API and DWH files | Applicable with Instant issuing | Applicable with physical (without instant issuing) | Applicable with virtual only | Description |
---|---|---|---|---|---|
New Card | NCRD | Y | This card production event is created at the same time when a new card is created via API. Only the first plastic of each card will have this production event | ||
New Card – Virtual | NVRT | Y | Y | This card production event is created at the same time as the new virtual card is created | |
New Card – Instead Lost | NLOST | Y | This production event comes with a replacement (REPLACE_CARD). The previous card will be put to lost and a new card will be created with the production event NLOST | ||
New Card – Instead Lost Virtual | NLOSTVRT | Y | Y | Same as the production event “NLOST” but no physical card is produced. | |
Reorder PIN – Renew | ROPIN | Y | Y | This production event comes when a reorder PIN (REORDER_CARD_PIN) has been ordered | |
Replace All – Instead Lost | RALLNLOST | Y | This production event will change the PAN# and replace the PIN. Used for creating the physical card for Instant Issuing when using REPLACE_CARD | ||
Replace All – Renew | RALLRE | Y | This production event comes when the physical form of the card is ordered | ||
Replace Plastic – Expired | RPL | Y | Y | This production event comes automatically when the current plastic has expired for a physical card | |
Replace Plastic – Renew | RPLRE | Y | This production event comes with the reissue (REISSUE_CARD) when only plastic is renewed | ||
Replace Virtual – Expired | RVRT | This production event comes automatically when the current virtual card has expired |
Issue payment card on Enfuce.com.