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

The different resources are described below :

Account ➔

Accounts manage monetary operations, balances and restrictions, and are typically assigned to account owners. An account owner is typically an individual, or a legal entity, who has signed a contract with an issuing institution, so a customer.

Accounts are used to process operations, manage a balance in a dedicated currency,  control the credit risk, perform transaction charging, calculate interests (credit or debit), generate an invoice (statement), process payments.

Address ➔

A customer address is the generic term for postal address, email address or phone number. Addresses can be of two types, personal address or company address, and could be used in several ways according to the purpose for which the address is used, as example for statement sending or card delivery.

Authorization ➔

Authorizations are request message from a connected scheme which are processed by our authorization server. Based on several business rules (e.g. card status, velocity limits check ...) the authorizations could either be accepted or declined.

Authorization Business Case ➔

An authorization business case can refer to one or several consecutive Authorizations (for example, a reservation in a hotel with a subsequent confirmation or a purchase with a subsequent cancellation).

Authorization Restriction ➔

The card usage can be restricted using multiple criteria, such as transaction type (ecom, ATM), acceptance domain (allowed regions), active start and end date.

Authorization Restriction Override ➔

Restrictions are either enabled or disabled by default and can be overridden.

Customer ➔

A customer is a person or a company who has subscribed to services offered by the issuer.

Contract ➔

Contract refers to the Customer contracts created in our solution. The contract is the link between cards, accounts and customer data. The contract inherits default value from Product with the possibility to override  some specific parameters, such as fees, terms and conditions, credit limit, card layout reference.

Card Contract ➔

A Card Contract represents a single card owner by a cardholder and is linked to a card profile which defines all allowed business rules (e.g. replacement, renewal) and card properties (e.g. chip data) required to create a card. Under a card contract the first card is created and all next cards in case of automatic renewals, card replacements.

Card ➔

A card is a payment mean that enables a customer to access funds or make purchases against a line of credit. Cards can have different technologies (EMV, Magnetic Stripe, Contactless), could be physical or virtual.

Order ➔

An order refers to card order and PIN mailer data extractions that are sent to card producer and PIN mailer editors respectively.

Operation ➔

Operations can be transactions received from clearing or internal generated operations ( e.g. fees, refund, chargeback...)  that are posted on accounts.

Temporary Credit Limit ➔

A temporary credit limit, that extends or reduces the account credit limit could be defined at account level. In this case, the value of the temporary limit override the content of the normal credit limit.

Velocity Limit ➔

The velocity limit is a restriction based on usage frequency and the total amount on the card account. The purpose of a velocity limit is to limit a transaction in terms of amount and frequency, e.g. it might be allowed to withdraw 500€ per day on POS terminals in Europe.

Velocity Limit Override ➔

On account level the defaults can be overridden. Overriding can be timely restricted by providing an activation period.

The different resources are identified by corresponding references.

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

WL 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 WL (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.

A quick tour of Worldline Card Issuing

Worldline Card Issuing includes all the core features enabling to instantly issue cards and process payments : 

• Issue any type of card : debit, credit, pre-paid whatever its form physical/virtual,

• Authorize and process transaction efficiently thanks to a proven technology already processing more than 10 billions of transactions a year

• Launch a new product on international schemes but also on local ones, Wordline Card Issuing being GLOCAL ! 

• Embrace the wallet revolution by having the possibility to tokenize you card portfolio and make it compatible with mobile wallet providers

• Manage disputes and initiate chargeback to a merchant in line with the schemes’ rules and regulation.

Creating and managing your cards portfolio using Worldline Card Issuing will follow 4 main steps that can be easily done through our powerfull REST/json APIs.

Authentication

Worldline APIs require authentication on all endpoints and methods.

We currently support one Authentication scheme:

• Bearer Token (OAuth2 - Client Credentials)

Bearer Token

Bearer tokens are temporary security credentials that can be used to authorize 'third parties' (bearers) access to the Worldline API.

These tokens are created by calling the accesstoken endpoint.

Once created the token field must be used in the HTTP Authorization header using the Bearer scheme.

Example HTTPS request with a bearer token in Accept Transactions API

GET /v1.0/acquiring/transaction/acquirers/{acquirerId}/transactions HTTPS/1.1

Accept: application/json

Authorization: Bearer fsdfdsfdsfdsfs9857958hjiIsInR5cCI6IkpXVCJ9

Create Bearer Token - OAuth2 Client Credentials

The Client Credentials grant type is used by clients to obtain an access token outside of the context of a user.

The OAuth 2.0 client credentials grant flow permits an API (confidential client) to use its own credentials, instead of impersonating a user, to authenticate when calling another API.

Steps to obtain an Access token

Step 1: Construct a Basic Authentication header using the following values shared by Worldline team.

Step 2: Construct a valid HTTP Basic Authentication header as follows in pseudo-code.

const consumerKey = "jhfrjh881wtRxgregegegggeg";

const consumerSecret = "wfrregergjbD6rNxregregerg";

const authnValue = "Basic " + base64Encode(consumerKey + ":" + consumerSecret);

request.setHeader("Authorization", authnValue);

Step 3: Call the rest endpoint of Oauth2 client credentials to obtain the access token.

POST oauth/client_credential/accesstoken?grant_type=client_credentials HTTPS/1.1
Accept: application/json
Authorization: Basic jfvwrjfbrkfbrkbrglenglengelgnegnejwvfwejhf==

The call Response contains the Bearer Access token. Use this token to call the Actual resource.

Example POST call response - field access_token

{
    "refresh_token_expires_in": "0",
    "api_product_list": "[coffea]",
    "api_product_list_json": [
        "coffea"
    ],
    "organization_name": "$organization_name",
    "developer.email": "$Developermail",
    "token_type": "BearerToken",
    "issued_at": "1678146804722",
    "client_id": "jhfrjh881wtRxgregegegggeg",
    "access_token": "Knk9uvvoSALfzo3AGDADzGJ0Ayl1",
    "application_name": "4a319510-0793-4332-9627-452ae6a70c1d",
    "scope": "",
    "expires_in": "3599",
    "refresh_count": "0",
    "status": "approved"
}