Catalogue Overview
The Worldline Card Issuing solution offers a wide range of API that enable the issuer to interact easily with the Worldline platform :
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 | customerReference | issuerCustomerExternalReference |
| 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 |
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
-
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 !
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
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 1st 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 1st 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
|
Parameter |
Deferred debit/ Charge cards |
Description |
|
Closure calendar |
X |
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 |
X |
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 |
X |
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 |
X |
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 |
X |
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 |
X |
|
|
Card termination |
X |
|
|
On demand from Open-to-buy |
X |
|
Credit card product’s parameters
|
Parameter |
Deferred debit/Charge cards |
Revolving credit cards |
Description |
|
Closure calendar |
X |
X |
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 |
X |
- |
Customer has to repay its full statement balance every month/cycle |
|
Partial payer |
- |
X |
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 |
- |
X |
Whether balance is fully repaid by grace period end date then debit interest amount is waived |
|
Debit Interest |
- |
X |
If debit interest rate is set then calculated on payment balance |
|
Statement |
X |
X |
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 |
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 |
X |
X |
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 |
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 |
optional |
Possibility to calculate credit interest from credit balance for each month/cycle |
|
Incoming fund transfer |
|
|
|
|
From external bank account by customer |
X |
X |
|
|
Direct debit on demand from issuer side |
X |
X |
|
|
Outgoing Credit transfer |
|
|
|
|
At cycle closure date |
optional |
optional |
|
|
Daily basis |
optional |
optional |
|
|
Contract termination |
optional |
optional |
|
|
Card termination |
optional |
optional |
|
|
On demand (credit balance only) |
optional |
optional |
|
|
On demand from Open-to-buy |
optional |
optional |
|
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 |
|
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: |
|
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) |
|
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 |
|
|
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:
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. |
|
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: |
|
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 |
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:
- Interests on credit lines,
- Overlimit fee (Open-to-buy exceeded)
- Statement/statement reprinting fee
- Direct debit returned/rejected fee
