Core Concepts

Read more about Core Concepts

Core concepts

Data Model

The data model used in our system is represented as follows :

The different resources are identified by corresponding references.

References can be internal, which means generated by our system and transmitted to the issuer.

Wordline supports also the usage of external references that means the bank provides us the value; this implies that the generation of this identifier follows rules shared by Wordline (unicity of the reference).

External references must be provided generally during the resource generation such as for:

External contract reference during contract creation
External card reference during card creation
External account reference during account creation

Please find below a table illustrating the resources for which external reference is allowed.

Resources	Resource Reference This reference acts as a key for the resources	Issuer External Reference This optional reference is used to ease API integration with client
Issuer	IssuerId
Product	issuerProductExternalReference
Customer (Person) - Company	customerReference	issuerCustomerExternalReference
Contact	contactReference
Address	addressReference	issuerAddressExternalReference
Contract	contractReference	issuerContractExternalReference
Card Contract	cardcontractReference	issuerCardContractExternalReference
Card	cardReference	issuerCardExternalReference
Order	orderReference
Account	accountReference	issuerAccountExternalReference
Operation	operationId
Authorization	transactionId
Authorization Business Case	businessCaseId
Tempory Credit Limit	temporaryCreditLimitReference
Authorization Restriction	authorizationRestrictionReference
Authorization Restriction Override	authorizationRestrictionOverrideReference
Velocity Limit	velocityLimitReference
Velocity Limit Override	velocityLimitOverrideReference
Dispute	disputeFolderReference	issuerDisputeExternalReference
Insurance Contract	insurancePackageReference

Product concepts

Products are organized in a product catalogue. A product is a set of parameters and features that define the behaviour and functionalities of a set of Cards and Accounts.

Models and template concepts

The configuration of the product is performed by Worldline, based on Issuer requirements, through the definition of cards and accounts templates.

The first step of product configuration is the definition of models.

A model defines the possible behaviour for a product (general parameters grouped by rules and functions); several models belonging to the same type can be defined for a product.

There are card models and account models:

Card models
- Card creation model
- Replacement model
- Card event fee model
- …
Account models
- Restriction model
- Transaction fee model,
- Markup fee model
- Amount due model
- …

A template is composed of models and defines the default values of the product by selecting one model per model type. The other models defined in the product can be then used later for customization.

The below diagram provides an overview of the configuration linked to the Issuer and the product. It illustrates especially:

the possible models for card and account
the parameters linked to an issuer

Account management

Account templates are used to create accounts for the customer.

Accounts are linked to form a hierarchy in order to set up multi-purpose products (mixture of debit and credit accounts), represent organizations (families or corporate structures), set up multi-currency accounts.

This account hierarchy is based on the account hierarchy template defined during the product configuration and according to the issuer requirements.

An account hierarchy template is defined with 1 or more levels of accounts, account templates at each level.

In a hierarchical structure, we refer to parent accounts and child accounts. The parent account offers the capability to link all child accounts and support some specific functions:

Credit risk verifications can be expanded across the hierarchy.
Consolidated invoicing and payment management can be done on parent level account for accounts lower in the hierarchy.

The account at the top of the hierarchy will be the parent of all accounts and will be called "Root account".

Some examples of account hierarchy:

a 2-level hierarchy will be defined to manage a family structure.
- A root account is created based on a root account template and is configured as paying account, credit limit check.
- A child account is created based on a child account template. Each member of the family has a child account used for operations postings performed with his own card
A 3-level hierarchy can be defined to manage corporate cards if an intermediary level is requested to attach the employees to a department level

Usage of the concepts in APIs

The templates and models are used in the APIs in order to facilitate the creation of the Contract and its associated Cards and Accounts.

It is possible by API to replace a model with another one in order to customize the contract for a customer. For example in order to modify

The fees on card event (fee type, fee amount, …)
The due amount calculation algorithm (full repayment, partial repayment with minimum amount, ..)
The closure date

In order to identify a contract and its related Cards and Accounts, the corresponding Worldline internal references are known by the Issuer:

Product reference (ProductReference)
Account template reference (accountTemplateReference)
Card template reference ( cardTemplateReference)
Model references (selectedModels)
parentAccount identifier
childrenAccount identifier
payingAccount identifier,
rootAccount identifier
accountOwner identifier

Pass-trough data concept

“Pass-through data” correspond to data provided by the issuer in the APIs and transmitted without business process to an external system by Worldline card issuing solution.

This can be typically data requested by the embosser and transmitted directly by the issuer (e.g.: photo reference ID, …).

Pass-through data are identified in the API fields “specificFields”.

The data must be provided with the following format: labelname:value separated by a “|” character.

The fields can be attached to a contract, a card, an account, a card contract, a card order, a PIN/TAN mailer, or a customer.

Clearing messages supported

Read more about Clearing messages supported

Clearing messages supported

Mastercard

First Presentment (1240/200) [FP]
Addendum (1644/696) [ADD]
Second Presentment (1240/205-282) [SP]
Fee (Debit & Credit) (1740/9xx) [FEE] (1740/7xx)
Financial Advice (T5G2 related to MasterCom) [FA]

Note: the “Financial Advice” are not imported from the clearing files, but from specific T5G2 MCI files, but with the same treatments as a clearing file.

VISA

First Presentment (TC05/06/07/25/26/27 & UC = 1) [FP]
Addendum (TC50) [ADD]
Second Presentment (TC05/06/07/25/26/27 & UC = 2/9) [SP]
Fee (Debit & Credit) (TC10/20) [FEE].
Financial Advice (TC33 VCR related to VROL Disputes and without transaction level interchange fee information) [FA].

Note: all types of clearing messages are supported such as:

OCT, AFT
MoneySend

The "Financial Advice" are incoming messages generated by the Schemes to confirm actions performed in the Scheme Dispute applications (MasterCom / VROL), such as:

ChargeBack accepted
ChargeBack rejected
ChargeBack reversal accepted
Pre-Arbitration
Arbitration

Process transactions and give the control to cardholders !

Read more about Process transactions and give the control to cardholders !

Process transactions and give the control to cardholders !

With more than 10 billion of transactions processed every years, Worldline Card Issuing is today a reference in terms of processing platform. In this chapter, we will highlight the processing facilities of Worldline Card Issuing as well as its full-fledged panel of settings enabling cardholders to take the control of their cards.

Worldline Card Issuing: a reference in transaction processing

1.Transaction processing overview

Worldline Card Issuing comes with strong authorization and clearing/settlement modules mandated to process any transaction in the card payment ecosystem. Today, these modules are fully compliant with Visa and Mastercard schemes but can obviously be fine-tuned to support other card schemes.

2.Authorization Processing

As illustrated, authorization being the backbone in the approval / rejection of transactions, this module has a strong impact on the Issuer business as:

It enables to reduce the costs of fraud by being connected to third party system(s) in charge of analyzing fraud patterns,
And, its decisions directly influence the level of interchanges fees captured.

Fully compliant with EMV authorization standard, our authorization module supports a wide variety of use cases such as:

Retail transactions done in Point Of Sales or in E-commerce, through a plastic or a virtual card:
- Purchase (goods and services),
- Refund (credit) transactions,
- Mail order / telephone order (MO/TO) transactions,
- Reversal transactions,
- Inquiry transactions,
- Automated Fuel Dispenser (AFD) transactions
Financial transactions on ATM,
Non-financial transactions on ATM like Pin change, balance inquiry,
Money transfer transactions

Two main steps are performed by our authorization module on each incoming authorization request:

A technical authentication aiming at verifying the authenticity of the card (and the cardholder) and some card attributes (card status, EMV cryptogram…)
A financial authorization covering pure financial checks on the balance or credit lines related to the card.

Technical authentication

Six main controls are performed in standard by Worldline Card Issuing:

Format protocol message check aims at controlling the technical format of the message received, this latter having to comply with the scheme definition.
Card authenticity check consists in checking if the card is a genuine one. At this stage CVV/CVC, magnetic stripe track format and chip card cryptography controls (standard EMV) are done.
Cardholder verification relies on PIN verification either on-line PIN or chip status for offline PIN. The number of PIN tries is also controlled during this step.
Card status check aims at controlling several card’s attributes like: the card status (is the card active or blocked), the acceptance context (i.e. ATM/POS, domestic/international).
Card restriction check consists in verifying the usage restriction applied on the card:
- Transaction types
- Merchant (through Merchant Category Code – MCC)
- Countries
Fraud detection check aims at asking to a specific third party fraud engine, not included in Worldline Card Issuing, to perform a risk assessment based on the transaction context.
- If needed by an issuer and as an option, we can offer our Worldline Fraud Management service. This service is based on our powerful tools enabling real-time fraud prevention and fraud pattern detection operated by Worldline experts in risk and fraud management.

Once the technical authorization is completed with success, the financial authorization process can start.

Financial authorization

The Issuer can delegate this process to Worldline Card Issuing in two steps :

Velocity checks aiming at verifying if the incoming authorization complies or not with the restrictions set on the card (and related account). These restrictions consist in a number of maximal usage that can be narrowed down using:

The transaction type (purchase, cash withdrawal etc.)
The type of the processing (foreign, stand-in, on-us)
A time dimension aiming at precising if this restriction applies on a fix period in time (weekly, monthly or on a number of day) or on a time interval (rolling or jumping approach)

Below some examples of classical configurations for velocity limits:

Authorize the use of the card 5 days per week,
Authorize max 10 transactions for the card per day, 50 transactions for the card per week,
Authorize max 3 foreign transactions for the card per day

Stand-in for Debit Cards

For debit cards, financial authorizations are given by the issuer (bank host).

Worldline Card Issuing supports switch-outs towards external systems during the authorization process relying, in standard, on JSON or ISO8583 protocols. If the external system for a switch-out is unavailable, on demand of the issuer, Worldline Card Issuing can perform Stand-in Process (STIP) based on the card checks and card usage limits.

A "Store-and-Forward" handling for authorization advice to the external system is supported in this context.

The stand-in processing allows only transaction until a certain amount (for e.g., 300 euro)

Stand-in for Credit Cards

For credit cards, financial authorizations can be fully performed by Worldline Card Issuing making checks on the related credit card accounts supported by the solution. In this context, the financial authorization is granted by checking:

Credit limit, cleared transactions and pending authorizations to determine the open to buy (remaining global amount to be spent)
The velocity limits (spending limits)

Once the real-time financial authorization completed, the authorization response (positive or negative) is returned to the terminal through the scheme, allowing to pursue or not the transaction with the cardholder.

3.Clearing & Settlement

The illustration shows how clearing is managed on Worldline Card Issuing. A fundamental part of this process is validating clearing files originating from schemes. For each message contained in these files, several checks are done leading to the posting of operations towards the internal accounting or dispute modules of Worldline Card Issuing.

In parallel, on a regular basis, ledger files and reports are generated by Worldline Card Issuing and shared with the Issuer’s systems (Core Banking System) and schemes.

Clearing File Management

As soon as a clearing file is received from a scheme, Worldline Card Issuing starts processing it. Note that our solution fully complies with Mastercard and Visa clearing requirement and will store the original messages coming from these schemes (Base II and IPM formats) before translating it in our internal format for our processing purposed.

Regarding clearing file processing, Worldline Card Issuing comes with high level fault tolerance mechanisms allowing to:

Pursue the processing of a file in case of error happening on a message,
Detect duplicated files,
Re-process only unknown messages when re-integrating a file after an error occurred.

Besides of the high level technical processing checks this checks are

Issuer Identification: for each message, this first step consists in identifying the issuer by analysing an identifier in the incoming message.
Card Check process: for messages containing a PAN, Worldline Card Issuing is going to check if the PAN is known by the system and the status of the card related to this PAN. A card “blocked” for instance will lead at the end, to the post of an operation towards the dispute management system whereas, in the other case, it will trigger the post of an operation in the accounting module.
Matching process: in this step, Worldline Card Issuing is going to reconcile the incoming message with the original authorization message. More than creating a logical link between messages enabling to offer an holistic view on a card transaction, this matching process directly impacts the reserved amount and Open to Buy.
If a matching is done with an authorization, a message to cancel the reserve is sent to the authorization server.
If no matching is done, a “failing” flow is executed (define with the Issuer) leading either to the post of an operation in the dispute management system or, to the post of an operation in the accounting module.
Fee messages process: this step is applied for messages related to fees requested either on dispute cases or fees requested by schemes. In the first case (dispute), the “standard” behavior on Worldline Card Issuing will be to feed the dispute management system with this new message whereas, in the other case, Worldline Card Issuing will post an operation in the accounting module (on the specific account setup with the Issuer)
Embargo process: following European regulation, checks against sanction lists are mandated for certain type of transactions (aka. P2P transactions…). Worldline Card Issuing doesn’t come with an embedded embargo system but offers the possibility to manage a connection towards a third party solution deployed on the Issuer side.
Posting process: this final step is going to orchestrate, depending about the message received and the previous checks ‘results either the posting of an operation towards the accounting module or, the posting an operation towards the dispute system.
Posting operations towards the accounting module: based on the settings configured at the product, contract and card levels, the posting process is going to:
- calculate potential fees that shall be paid by the cardholders to the Issuer (and then debited on the related cardholder’s account),
- adjust the scheme reconciliation amount using currency conversion if needed. Currency conversion is configurable for the Issuer, with or without the application of a mark-up, using either:
  - ECB rates (European Central Bank),
  - its own rates,
  - specific Scheme rates,
Posting operations towards the dispute management system: on top of sending a message towards the dispute management system, several specific rules can be defined with the Issuer (not part of the “standard” configuration) to:
- automatically “Refund” to cardholder,
- automatically declare a “Fraud” to the Scheme (MasterCom / VROL)
- automatically generate a “ChargeBack” or a “Write Off”

Settlement Services

Our Settlement Service offers based on the data from the card schemes Visa/Mastercard) and the data from the Worldline Card Issuing system a comprehensive reporting. The reporting serves as the basis for payment transactions between Worldline and the issuer as well as for the following issuer's reconciliation processes.

The Worldline Settlement Service arranges payments to the card (Visa/Mastercard) in the name of and on behalf of the customer (issuer) on the basis of the settlement information.

Card in control: all the Card limit & control

Card Control enables the cardholder to self-manage functionalities of his debit/credit card through the existing App of the bank. The cardholder can set several usage limits and deactivate channels (ATM, e-commerce, POS, NFC) or merchant categories with just one switch. Regions can be adjusted and for each authentication request the cardholder can receive a push notification.

Cards are issued by default setting as agreed in the product set up. Depending on card sort (or package type) the default settings can differ. Setting can be set per card.

Card Control will reduce calls to the customer services and can diminish fraud, as the cardholder can set settings which will restrict the usage of the card.

Card control is able to manage:

Overall card limit
General card blocking, temporary or permanently
Amending or blocking the following limits:
- Cash/ATM
- Card not present
- Point of Sales
- Country/Region
Blocking the following functionalities:
- Contactless payments (NFC on Card)
- Merchant Categories (e.g. Casinos)

Customer Service Management

Together with the Worldline Card Issuing Service, 1st and 2nd line customer service support for issuers can be bundled. Worldline Customer Service supports all European languages from 16 locations across Europe (Aachen, Barcelona, Blois, Brussels, Frankfurt, Helsinki, Karlsruhe, Luxembourg, Munich, Riga, Seclin, Stuttgart, Timisoara, Utrecht, Vienna, Zurich).

Customer Service provides both inbound and outbound capabilities and supports multiple communication and relationship channels. The channels phone, email, chatbots etc. can be operated 24/7, customer journeys can be flexibly adapted as required and branded with the identity of the client.

For issuers we offer a specialized Cardholder Care:

Card Application services
Handle Cardholder card-transactions and account support
Emergency Cardholder Care (Card Block, Card Replacement and Claim Handling)
Collection of Customer Feedback
Requests for Additional Services can be handled as well:
- Dispute Management
- Risk and Fraud Management
- Collection Services for Credit Cards

To ensure an optimal customer experience Worldline Customer Service follows Lean Six Sigma and we are certified in ISO 9001 (Quality Management System), ISO 27001 (Information Security System), ISO14001 (Environmental Management Systems) and ISO 22301 (Business Continuity Management Systems).

Generate cards for your cardholders

Read more about Generate cards for your cardholders

Generate cards for your cardholders

Once the card products of your portfolio are designed in Worldline Card Issuing, you are able to generate cards for your cardholders.

Generating cards for cardholders on Worldline Card Issuing means 2 things:

Creating an entry for the cardholder and/or the legal entity (in case of corporate cards) with who you have signed a contract, logically called contract on Worldline Card Issuing.
Once the contract created, generate card(s) associated to a contract.

As illustrated in the diagram above, you, as an Issuer, will be in charge of performing the legal KYC, getting a contract signed with the cardholder (or a legal entity for corporate cards), and once done, reflecting this contract and order the related cards on Worldline Card Issuing.

Contract lifecycle Management

The standard contract lifecycle applied on Worldline Card Issuing reflects the relation between you (as an “Issuer”) and an individual cardholder (retail market) or a company (corporate market)

Contract “signed”

A contract newly created on Worldline Card Issuing gets this status. In this contract, terms and conditions between the issuer and cardholder(s) are reflected such as :

Transaction and mark up fees,
Card event related fees (i.e. replacement, PIN selection etc.),
Velocity (i.e. maximum amount per transaction, maximum spending amount etc.),
Wallet “ready” option: capability to onboard the card in wallets (i.e. Apple/Google/Samsung Pay etc.)
3D Secure / ACS option: decide if the card can perform 3D secure check
Instant Issuing option: decide if the card credentials have to be immediately available (PAN, expiry date, CVx2, cardholder name) without waiting for a physical plastic card.

Note that in this state, updates are always possible (i.e. change of fees, velocity on a card product included in the contract, addition of a new card product). Some updates will only be applicable for next card(s) issued in this contract such as card design, or embossing name for instance.

Contract “suspended”

A contract can be suspended at any time. This will directly impact all the card(s) belonging to this contract by “blocking” them temporarily. The removal of a suspension can be done either on demand or automatically at the end of a period that was set when you’ve suspended the contract.

Contract “closed”

Contracts can be ended at any time and for any reasons (i.e. cardholder leaves the bank) either on demand or automatically based on the “standard” rules below:

All cards belonging to a contract have reached their expiry date with no automatic renewals,
The end of a contract was scheduled.

Card Management

Card Lifecycle

Each card issued through Worldline Card Issuing follows the general card lifecycle highlighted :

Card Created

Cards will start their lives on Worldline Card Issuing on Issuers’ demands either by calling our APIs or sharing with us a provisioning file. Each card will be created using:

The card account information (IBAN) précised by the Issuer,
Limits and fees settings defined by the Issuer when he has created the card product on Worldline Card Issuing,
The BIN ranges selected by the Issuer[1]

Based on these data, Worldline Card Issuing:

Generates cards’ numbers/PAN, cards’ PINs and will calculate expiry dates (card variable data),
Generates and send a cardholder file (for physical crd) to the Embosser selected by the Issuer.

Card Active

Cards can be automatically activated or not, depending on the choice of the Issuer when defining its card product on Worldline Card Issuing. For cards not immediately active, 3 options are available to make them active:

On demand through an API call,
On demand through our WL Card Issuing Portal.
Automatically at the 1^st PIN based approved authorization

Card Blocking

Worldline Card Issuing supports both “temporary” and “permanent” blocking. Unlike “temporary” blocking which is reversible, “permanent” blocking is definitive and will be mainly used in case of fraud, lost or stolen. When a “permanent” blocking will be requested on a card, Worldline Card Issuing will:

Decline authorizations coming from this card,
Notify the scheme associated to this card,
Stop the renewal of the card

Card Deactivated

Card deactivation is also not reversible and can be done on WL Card Issuing through 5 ways:

On demand,
Automatically on expiry date,
At the contract termination,
X days after a replacement,
After the 1^st use of the new card following a renewal.

Card Cancellation

A card will be in this state on WL Card Issuing if any issue occurs during the card production (i.e. errors
when generating card data or errors on the embosser side).

[1] BIN can be owned by the Issuer itself or, as an option covered by Worldline through its sponsorship license.

Card creation: data preparation and personalization

The data preparation feature aims at collecting, generating and preparing all the data needed by the embosser to produce the card and personalize the chip card applications.

Worldline Card Issuing supports in “standard” the production of Card Order Files using XML format and based on EMV Card Personalization Specification (CSP). In terms of security, AES encryption mechanism is used to cypher sensitive data. Once produced, these files are compressed (ZIP format), encrypted using RSA standard and sent to the embosser.

As a return from the embosser, Worldline Card Issuing expects to receive from the embosser a file containing the personalization status.

A similar approach is used to generate and send files related to PIN distribution.

PIN creation

Regarding PIN creation, two strategies are available for an Issuer on Worldline Card Issuing:

Either creating cards with an initial PIN randomly generated by our solution,
Or creating cards with PIN selected by cardholders.

Card renewal

When a card is about to expire, this latter is usually renewed to offer to the cardholder a continuity in his card payment experience. Worldline Card Issuing offers 2 renewal mode automatic or “on-demand”.

Automatic renewal

In this mode, the production of new cards will be launched automatically X days before reaching the expiry date of cards in circulation. This delay can be set by the issuer on the platform.

Note that on top of checking dates, additional verifications are done by Worldline Card Issuing on:

The card status: when a card is “blocked”, this latter cannot be renewed,
The age of the cardholder: for instance prepaid card for kids,
The existence of any programmed card deactivation or contract closing rules for which a renewal doesn’t make sense

On-demand renewal

In this mode, the issuer will control the renewal of each card of his portfolio manually.

Whatever the mode selected, cards will be renewed using the same PAN and the same PIN. Worldline Card Issuing also supports renewal with new PAN and/or PIN.

Card replacement

Several scenario may lead to the replacement of the card such as: card defect (PIN non compromised), embossing name change, lost or stolen card.

For card defect or embossing name change cases, Worldline Card Issuing will order a new card reusing the same PAN/PIN/Expiry date whereas these data will be generated again for lost/stolen cases.

Note that before ordering a replacement, Worldline Card Issuing will perform verifications on:

The card and contract status: preventing from replacing a card which is blocked or for which the related contract is suspended,
The expiry date of current card: to avoid launching a replacement for cards having a renewal date coming soon,
The existence of any programmed card deactivation or contract closing rules for which a replacement doesn’t make sense.

Specific pre-paid card product parameters

Read more about Specific pre-paid card product parameters

Specific pre-paid card product parameters

Parameter

Deferred debit/

Charge cards

Description

Closure calendar

Is mandatory and used to calculate all cycles including closure date and all related events per cycle (statement issuing date, payment due date, etc)

Minimum payment amount

Full payer

Customer has to repay its full statement balance every month/cycle

Statement

optional

Statement raw data are prepared at cycle closure date and can be provided to an output management service (file) or via web service (online)

Delinquency

optional

At payment due date or upcoming cycle closure date card account can become delinquent (usually activated if customer pays from an external bank account)

Payment method: direct debit, self-payer

The customer can be debited from its bank account (Direct debit) or as self-payer he/she has to transfer the money from its own bank account to its card account to repay its card account

Prepaid accounts

Allowed for an overlimit of the open-to-buy amount

Default choice

With delay posting of financial operations leading to an overlimit of the open-to-buy amount (debit balance)

optional

Preventing posting of financial operations leading to an overlimit of the open-to-buy amount (debit balance)

optional

Incoming fund transfer

LOAD

Customer can transfer its money to issuer in order to load its prepaid card

Maximum allowed open-to-buy

optional

Issuers can define a maximum allowed open-to-buy per prepaid card.

This amount can be set to 0 to prevent any load request.

Maximum allowed amount per load request

optional

Issuers can define a maximum amount per load request, e.g. customer cannot load more than 500€ per load request

Maximum allowed amount per load request depending on customer’s age

optional

The maximum allowed amount per load request can depend on the customer’s age, e.g.

- Maximum 500€ per load request if customer is under 18 yo

Maximum 5.000€ per load request if customer is above 18 yo

Outgoing Credit transfer

Contract termination

Card termination

On demand from Open-to-buy

Credit card product’s parameters

Read more about Credit card product’s parameters

Specific credit card product parameters

Parameter

Deferred debit/Charge cards

Revolving credit cards

Description

Closure calendar

Is mandatory and used to calculate all cycles including closure date and all related events per cycle (statement issuing date, payment due date, etc)

Minimum payment amount

Full payer

Customer has to repay its full statement balance every month/cycle

Partial payer

Can be % of statement balance, fixed amount, % of statement balance with a minimum fixed amount (e.g. 50% and minimum of 2.000 SEK)

Grace period

Whether balance is fully repaid by grace period end date then debit interest amount is waived

Debit Interest

If debit interest rate is set then calculated on payment balance

Statement

Statement raw data are prepared at cycle closure date and can be provided to an output management service (file) or via web service (online)

Delinquency

optional

At payment due date or upcoming cycle closure date card account can become delinquent (usually activated if customer pays from an external bank account)

Payment method: direct debit, self-payer

The customer can be debited from its bank account (Direct debit) or as self-payer he/she has to transfer the money from its own bank account to its card account to repay its card account

Credit installment

optional

It is possible to convert a transaction (already posted to card account), an online approved authorization, the statement balance into a credit installment plan. It is also possible to open a credit installment to transfer money to an external bank account

Credit interest

optional

Possibility to calculate credit interest from credit balance for each month/cycle

Incoming fund transfer

From external bank account by customer

Direct debit on demand from issuer side

Outgoing Credit transfer

At cycle closure date

optional

Daily basis

optional

Contract termination

optional

Card termination

optional

On demand (credit balance only)

optional

On demand from Open-to-buy

optional

Common card product parameters

Read more about Common card product parameters

Common card product parameters

The table below summarizes the common parameters of a debit, credit or prepaid card product that could be used by an Issuer to define a new product in its portfolio.

Parameter	Description
Product form
PAN calculation algorithm	The issuer chooses the PAN calculation algorithm for this card product - Standard: Random, - Manual: provided by the issuer
PAN length	PAN length in the BIN range (Luhn key included)
Service code	Service code of the card
Card definition parameters
Card range	BIN provided by the Card scheme for the card product.
Sub card range	For each card product a sub-BIN range can be defined within the main BIN (each card created with this card product will have its PAN included within this defined sub-BIN range)
Issuing Scheme	Indicates the issuing scheme (e.g. Mastercard, Visa etc.)
Brand
Card Type
card scheme reporting default behavior	Indicates if card info should be reported to the scheme (ABU/VAU)
Card technologies	Magstripe (ISO tracks 1 & 2)/EMV Chip contact or contactless/virtual only
Card digitizable card flag	Indicates if the card is digitizable
Card designs	List of card designs: - Simple (mandatory) - with photo (optional) - with picture (optional)
Card creation
Card Production	For physical cards, indicates if the card is ordered at card creation time or later on demand.
Card Activation	Indicates how the card is activated: - either the card is issued as active at creation time, it can be immediately used (at least for e-commerce transaction) - or the card is activated later on demand (e.g. from ATM, MobileApp)
Card lifetime	Card life time in months for this card product
Expiry date - closed months	List of closed months that are excluded for the expiry date calculation (cards cannot be ended in this month) This is to avoid e.g. renewal during summer.
Sending mode	Allowed sending mode for first card. Our standard sending modes are: Normal, Urgent, Ultra urgent At card creation, one of the sending mode among the list is selected.
Card production
Embosser name	Name of the card embosser (ex: Idemia, Thales)
Embossing name provided by issuer?	Does the issuer provide the embossing name?
Embossing name calculation	Embossing name calculation algorithm (required if not provided by the issuer)
Cardholder Name	Cardholder Name in the chip/magstripe
Order production	For physical cards, indicates if the card is ordered immediately at card creation time or later on demand
Risk management
Velocity limits	Count of transactions (number of transaction within the given timeframe) Volume of transactions (amount within the given timeframe) Max. amount per Transaction Usage controls (restriction of card usage to specific types of merchants and/or transaction types)
PIN management rules
Self-selected PIN allowed	Indicates if the cardholder can choose his PIN
PIN mailer	Indicates if the PIN is sent to cardholder by mail (PIN mailer function).
PIN mailer editor	Name of the PIN mailer editor
PIN display	Indicates if the PIN can be displayed to cardholder (PIN display functionality)
PIN reminder	Service to remind the forgotten (existing) PIN to customer (a letter is sent to the customer)
PIN reorder	Service to order a new PIN to customer. (a letter is sent to the customer)
TAN mailer management rules (TAN used for self-selected PIN)
Automatic TAN request	When a new PIN is required, this parameter indicates if a TAN is requested automatically
Manual TAN request allowed (API)	Indicates if a TAN request is allowed for self-selected PIN (case of a PIN change)
if automatic or manual TAN request is allowed, then provide following TAN parameters
TAN delivery channel	Indicates how the cardholder receives the TAN
TAN lifetime	TAN life time in days
TAN allowed tries number	Maximum number of tries the cardholder has to choose his PIN
TAN length
TAN mailer editor	Name of the TAN mailer editor
Delivery rules	The delivery type indicates who receives the card and the pin mailer. The possibilities are: - to the Cardholder address - to the branch The sending mode can be normal, urgent. Provide all the allowed combinations per relevant event. Card: first issuer, replacement, renewal PIN: first PIN, new PIN in the context of replacement, renewal, PIN reorder, PIN reminder TAN request (Manual or automatic)
Fees
Card transaction fees	Fees depending on card transaction types are calculated and posted to the cardholder account.
Card fees	Indicates if fees depending on card events are required. If yes, the fees are calculated and posted to the cardholder account.
Account event fees	Indicates if fees based on account events are required.
Account setup fees	Indicates if account setup fees are required
Membership fees	Annual or monthly fees
Additional service fees	Fees related to (monthly fees or one shop fee at additional service subscription)
Automatic Renewal
PAN preservation	Indicates if the card is renewed with same PAN & same PIN
Renewal anticipation delay	Default renewal anticipation delay (in days)
Specific Renewal anticipation delay	Specific renewal anticipation delay for certain months (per month, indicates the delay in days)
Automatic renewal sending mode	Default sending mode for automatic renewal
Renewal expiry date calculation	Indicates how calculate the Expiry date for renewal: calculation started at current month or the month following the expiry date
Proposal for renewal	Worldline can extract and provide the list of cards, in an output file (XML format), that will be renewed X days before the renewal batch. The Issuer has the possibility to flag a card as "not to be renewed" via a web service.
Delay for proposal file	When the proposal for renewal is activated, the parameter indicates the extraction delay before the card expiration
Replacement card
Behavior expected by reason category	Replacement behavior for reason codes: lost, stolen, fraud
Behavior expected by reason category	Replacement behavior for reason codes as malfunction, new embossing name
Sending mode	Allowed sending mode for replacement

DAM Doc Section

Read more about DAM Doc Section

Create your card portfolio

Read more about Create your card portfolio

Create your card portfolio

The first step you will follow as an Issuer will be the creation of your card portfolio. In Worldline Card Issuing, a card portfolio will be represented by several card products, each card product being a set of parameters defining the behaviour of the future cards created.

3 categories of business parameters are supported in Worldline Card Issuing :

Card personalization & life cycle parameters : activation rule, PIN production, replacement rule, renewal rule, card artwork (design), form factor…
Card account parameters : debit/credit or prepaid, scheme, limits, cycling closure (for credit), instalments policies…
Card membership fee : annual/monthly fee, reimbursement rule and add-ons (ie. insurance)

Choose the type of cards for your issuing portfolio

In the Worldline Card Issuing system, several standard card products are already preconfigured, this allows issuers to speed-up the card portfolio creation. The defined card products are based on the moment when they pay for the goods they get and the funding options.

In order to perfectly match issuers’ strategies, these pre-configured card products can be overridden or/and adjusted for every issuer.

Anatomy of a Debit card product

A “standard“ debit card product corresponds to a card linked to a cardholder’s current account managed on the Issuer side, with velocity limits, leading at the end to a direct debit of the cardholder’s account for each authorized transaction.

Anatomy of a credit card product

Two kinds of credit funded card products can be defined on Worldline Card Issuing:

Deferred Debit or Charge: the cardholder has to repay the debt to the Issuer in full by the due date, usually on a monthly basis. The given time of settlement is linked to a predefined billing date, typically reached monthly. The charge card, unlike a credit card, does not charge interest.
Revolving Credit Cards: a revolving credit account is created to grant a credit line to the cardholder. In contrast to the full payment required by the charge card or deferred debit card, credit cards allow the consumers a continuing balance of debt, but subject to interest charge.

Contrary to debit cards associated to cardholders’ current accounts managed on the Issuer side; for credit cards, Worldline Card Issuing entirely support the complexity of managing credit limit and billing cycles.

Anatomy of a Pre-paid card product

A “standard“ prepaid card product corresponds to a card with a preloaded amount by you as an Issuer that can be reloaded on cardholders demand. For this kind of card product, Worldline Card Issuing supports: loading rules, authorization and spending rules…all these parameters allowing you as an Issuer to support a wide variety of use cases as illustrated below:

Commercial Card Overview

Commercial Cards are defined by the European Commission as a payment card which is used for professional expenses addressing commercial organizations and its employees. It is a complete range of payment cards meeting all the needs of a company, including but not limited to the following business objectives:

Whatever their funding type (credit, charge, debit, prepaid or even charge), Worldline Card Issuing supports multiple product types for Corporates – physical cards, virtual cards, and lodged account. Corporate customers can gain benefits for Travel and Purchasing use-cases, not matter if realized by multi-purpose Business Cards or by use-case specific card product like Corporate Cards.

To enable Worldline Commercial Card Issuing, the product settings and business processes are altered:

Master-data-structures can depict hierarchies up to 15 levels within the same company
Several payment products can be allocated into the same hierarchy structure
Application processes support multi-level product like Corporate Cards
Corporate can chose if the payee is the Corporate or the Employee
Payment delay & Different billing cycles
Dedicated charges can be rolled up to company level
Issuer Reports contain additional data

Multi Use Cards

A multi-use card is a card product that contains multiple funding sources (e.g. prepaid, debit and credit). Multi use cards allow issuers to offer, for example, a debit and a credit card on one physical card body. The term combo cards is also often used for the combination of two financing sources in one card.

To select or distinguish between the two funding sources of the card, the physical card is equipped with two PANs, one for each use case (e.g. debit PAN and credit PAN). At the merchant's POS, the cardholder can select the funding source directly at the POS terminal. With the "Debit" option, for example, he would opt for a direct debit payment; if he chose the "Credit" option, the payment would be processed as a credit transaction.

In this way, a single physical card can be created for multiple purposes.

Define the Fees for your Card Portfolio

Having a flexibility in the definition of fees being key in an issuing strategy, Worldline Card Issuing allows you to constantly adjust fee policies for each card product of your portfolio by accessing to a fine-grained list of settings.

In addition to the “standard” settings shown in the illustration besides, additional ones can be added on credit card products such as: