A temporary credit limit, that extends or reduces the Account credit limit could be defined for credit accounts. In this case, the value of the temporary limit overrides the default credit limit for a selected time range.

In our solution each Temporary Credit Limit is identified by a unique temporaryCreditLimitReference

A temporary credit limit can be:

• created using the Create a temporary credit limit API : POST /issuers/{issuerId}/accounts/{accountReference}/temporary-credit-limits
• deleted using the Create a temporary credit limit API : DELETE /issuers/{issuerId}/accounts/{accountReference}/temporary-credit-limits/{temporaryCreditLimitReference}

The time period of two defined Temporary Credit Limit cannot overlap.

For each account it is possible to list temporary limits using the following API : GET /issuers/{issuerId}/accounts/{accountReference}/temporary-credit-limits

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).

In our solution each Authorization Business Case is identified by its unique businessCaseId

The issuer can Retrieve an Authorization Business Case details using the GET /issuers/{issuerId}/accounts/{accountReference}/authorization-business-cases/{businessCaseId} API, by providing the issuerId of the Issuer, the accountReference identifying the Account and the businessCaseId identifying the Authorization Business Case.

In our solution each Authorization is identified by its unique transactionId

Authorization data can be retrieved for a given time period using the API to List authorizations for an account GET /issuers/{issuerId}/accounts/{accountReference}/authorizations by providing the issuerId of the Issuer and accountReference identifying the Account.

The user can also get detailed data for a given authorization by using the API  Retrieve authorization  GET /issuers/{issuerId}/accounts/{accountReference}/authorizations/{transactionId}

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

In our solution each Operation is identified by its unique operationId

An issuer can retrieve the list of operations posted on a given account and  period of time by using the API to List operations for an account : 

GET /issuers/{issuerId}/accounts/{accountReference}/operations providing the issuerId of the Issuer and accountReference identifying the Account

In order to retrieve one operation detail, the following  should be used .GET /issuers/{issuerId}/accounts/{accountReference}/operations/{operationId}

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.

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. Credit risk verifications can be expanded across the hierarchy. Consolidated invoicing and payment management is done on top level account for accounts lower in the hierarchy.

Three types of accounts working modes are being supported; Pay Later, Pay Now, Pay Before.

• Pay Later account working mode is used to implement classical credit card products like charge cards or revolving credits. Pay later accounts are settled by a cyclic closure process and typically produce an invoice (statement) with an amount due which can represent the full or partial statement balance. Credit or debit interest algorithms may apply.
• Pay Now account working mode is used for all types of debit cards. Such accounts are typically settled in short frequencies (e. g. daily) and produce debit orders immediately forwarded to customer’s current accounts. Interest calculation never applies.
• Pay Before account working mode is used for the wide range of prepaid card products. The balance is always positive.

In our solution each Account is identified by a unique accountReference and optionally by a unique issuerAccountExternalReference per Issuer.

It is possible to:

• Retrieve Account general information using : GET /issuers/{issuerId}/accounts/{accountReference}
• Retrieve Account financial information using : GET /issuers/{issuerId}/accounts/{accountReference}/balance

Credit Limit

For each credit account a credit limit is defined. When the account is created the credit limit value is set with the default value inherited from the product configuration; it can be also set during the creation of a contract.

The credit limit amount can be:

• retrieved using the API :  GET /issuers/{issuerId}/accounts/{accountReference}/credit-limit
• updated using the API :  PUT /issuers/{issuerId}/accounts/{accountReference}/credit-limit

Each Credit Limit can be override by a Temporary Credit Limit for a selected time range.

An order refers to card orders or PIN mailer information that are sent to card producer or PIN mailer editors.

An order is linked to a card and is created based on the Product configuration at the same time than the Card is created and depending the type of card (physical card, virtual card) and the distributions choice of that product.

In our solution each Order is identified by a unique orderReference.

An Issuer can retrieve order linked to a card using the API to List orders for a card for a given card : GET /issuers/{issuerId}/cards/{cardReference}/orders by providing the issuerId of the Issuer and cardReference identifying the Card.

One order details can be provided by using the API to Retrieve card order :  GET /issuers/{issuerId}/cards/{cardReference}/orders/{orderReference}

When creating a Card, the issuer may want to perform additional checks on bank side before the order is sent to the card embosser. In this case the order is created in waiting mode, the issuer can use the API to Release a card order : POST /issuers/{issuerId}/cards/{cardReference}/orders/{orderReference}/release

A card is a payment mean that enables a customer to access funds or make purchases against a line of credit.

In our solution each Card is identified by a unique cardReference and optionally by a unique issuerCardExternalReference per Issuer.

The first Card of a Card Contract is created at the same time than the Card Contract.

Card information can be retrieved using the two following endpoints : 

• Retrieve the card information : GET /issuers/{issuerId}/cards/{cardReference}
• Search cards by pan and panSequenceNumber and/or expiryDate : POST /issuers/{issuerId}/cards/{cardReference}/search

Card Lifecycle

The following picture illustrates the card lifecycle and possible card status transition.

The following APIs could be used to manage card lifecycle : 

• Activate a card : POST /issuers/{issuerId}/cards/{cardReference}/activate
• Deactivate a card : POST /issuers/{issuerId}/cards/{cardReference}/deactivate
• Block a card : POST /issuers/{issuerId}/cards/{cardReference}/block
• Unblock a card : POST /issuers/{issuerId}/cards/{cardReference}/unblock

Card Replacement and Renewal

The user can use the API to replace an existing card and create a new one. As input the replacement reason (e.g. old card was lost, stolen, is defective, name change) need to be provided. Both PAN and expiry date of the new card are calculated following the rules defined in the Product configuration for the provided replacement reason.

POST /issuers/{issuerId}/cards/{cardReference}/replace

The renewal of the card can be managed automatically in our solution, an automatic process is triggered when card is close to expire and a new card is created replacing the existing card.

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.

Each Card Contract is identified by a unique cardContractReference and optionally by a unique issuerCardContractExternalReference per Issuer.

The Card Contract information can be managed with the following endpoints:

• Retrieve Card Contract: GET /issuers/{issuerId}/card-contracts/{cardContractReference}
• Retrieve cardholder for a  Card Contract: GET /issuers/{issuerId}/card-contracts/{cardContractReference}/cardholder
• Retrieve contract for a given Card Contract: GET /issuers/{issuerId}/card-contracts/{cardContractReference}/contract
• List cards for a given Card Contract: GET /issuers/{issuerId}/card-contracts/{cardContractReference}/cards

Contract refers to the Customer contracts created in our solution. 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.

Each Contract is identified by a unique contractReference and optionally by a unique issuerContractExternalReference per Issuer.

Contract Creation

In order to create a contract for a customer, the API Create consumer contract is used : POST /issuers/{issuerId}/contracts/create-consumer-contract

As a prerequisite to create a contract and its related Cards and Accounts, the Issuer and Product should be configured and their references known by the Issuer. Cards and Accounts are created according to the product configuration

The request is composed of two parts

• an optional list of customers to be created and that could be used as contractOwner, cardHolder, or accountOwner. By default the contractOwner is the cardHolder and the accountOwner.
• the contract structure referring to the Product via the issuerProductExternalReference and the different Card (cardTemplateReference) and Account (accountTemplateReference) Templates defined for this Product. The attributes of the request could be used to override some of the default behaviors defined at Product level

{
   "customers":[
      {
         "requestCorrelationId":"1",
         "courtesyTitle":"Mrs",
         "lastName":"Lena",
         "firstName":"Broderick",
         "addresses":[
            {
               "addressLabel":"MAIN_POSTAL_ADDRESS",
               "addressType":"POSTAL_MAIL",
               "postalAddress":{
                  "line1":"address_line1_string_1",
                  "country":"country_string_1"
               }
            }
         ]
      }
   ],
   "contract":{
      "issuerProductExternalReference":"issuerProductExternalReference",
      "contractOwnerRequestCorrelationId":"1",
      "accountHierarchy":{
         "accounts":[
            {
               "accountTemplateReference":"RootAccountTemplateReference"
            },
            {
               "accountTemplateReference":"ChildAccountTemplateReference"
            }
         ]
      },
      "cardContracts":[
         {
            "cardTemplateReference":"cardTemplateReference"
         }
      ]
   }
}

As a result the Contract is created for the customer with its Card Contracts and Accounts. 

Adding additional cards and accounts

To add cards and related accounts to an existing contract use the following endpoint  : POST /issuers/{issuerId}/contracts/{contractReference}/add-cards-accounts by providing the issuerId of the Issuer and contractReference identifying the Contract.

Contract Closure

Contracts can be closed either immediately or scheduled using the endpoint POST /issuers/{issuerId}/contracts/{contractReference}/close

Other Contract APIs

Furthermore the contracts can be managed through the following endpoints:

• Retrieve contract data : GET /issuers/{issuerId}/contracts/{contractReference}
• Retrieve contract owner : GET /issuers/{issuerId}/contracts/{contractReference}/contract-owner
• List accounts for a given contract : GET /issuers/{issuerId}/contracts/{contractReference}/accounts
• List card contracts for a given contract : GET /issuers/{issuerId}/contracts/{contractReference}/card-contracts

A Customer address can be of different types as postal address, email address or phone number.

The appropriate address type will be selected depending on the business usage, as example for statement sending or card delivery. 

The customer addresses could be created during the creation of the Contract or when additional Cards and Accounts are created.

A customer should at least have one main address (addressLabel: MAIN_POSTAL_ADDRESS)

Each Address is identified by a unique addressReference and optionally by a unique issuerAddressExternalReference per Issuer.

An Issuer can create additional addresses for a customer using the API Create address for a customer : POST /issuers/{issuerId}/customers/{customerReference}/addresses by providing the issuerId of the Issuer and customerReference identifying the Customer.

Furthermore the addresses could me managed and updated through the following endpoints:

• Retrieve customer address : GET /issuers/{issuerId}/customers/{customerReference}/addresses/{addressReference}
• Update address :  PUT /issuers/{issuerId}/customers/{customerReference}/addresses/{addressReference}
• Deactivate address : POST /issuers/{issuerId}/customers/{customerReference}/addresses/{addressReference}/deactivate
• Activate address :  POST /issuers/{issuerId}/customers/{customerReference}/addresses/{addressReference}/activate