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.