A default Authorization Restriction could be overwritten by Authorization Restriction Override.

The Authorization Restriction Override can also be done for a specific period using the attributes activationStartTime and activationEndTime

In order to Create authorization restriction override, the API POST /issuers/{issuerId}/accounts/{accountReference}/authorization-restrictions/{authorizationRestrictionReference}/authorization-restriction-overrides should be used. The overrides is created based on an existing Authorization Restriction which authorizationRestrictionReference needs to be provided.

To block or unblock transactions – in other words to switch on/off a restriction – the attribute conditionCheck is taken into account.

In our solution each Authorization Restriction Override is identified by an authorizationRestrictionOverrideReference

It is possible to use this reference in order to 

• Retrieve authorization restriction override using the API GET /issuers/{issuerId}/accounts/{accountReference}/authorization-restrictions/{authorizationRestrictionReference}/authorization-restriction-overrides/{authorizationRestrictionOverrideReference}
• Update authorization restriction override using the API PUT /issuers/{issuerId}/accounts/{accountReference}/authorization-restrictions/{authorizationRestrictionReference}/authorization-restriction-overrides/{authorizationRestrictionOverrideReference} 
• Delete authorization restriction override using the API DELETE /issuers/{issuerId}/accounts/{accountReference}/authorization-restrictions/{authorizationRestrictionReference}/authorization-restriction-overrides/{authorizationRestrictionOverrideReference}

All the Authorization Restriction Overrides which are applied on an Authorization Restriction can be retrieved by the API that List authorization restriction overrides for authorization restriction GET /issuers/{issuerId}/accounts/{accountReference}/authorization-restrictions/{authorizationRestrictionReference}/authorization-restriction-overrides/

Blocking countries

Card Control allows to block/unblock a single country or a list of countries.

The user needs to overwrite the existing default Authorization Restriction and use the conditionCheck attribute in combination with the conditionParameters attribute the country codes of the countries to be blocked.

For example, for an Authorization Restriction Override created with "conditionCheck":true, "conditionParameters":["004","008", "012"], authorizations from the countries Afghanistan (004), Albania (008) and Algeria (012) are declined.

Geo blocking

Geo Blocking is a functionality that allows the user to control for each Account whether a transaction from a region should be approved and processed or not.

The definition of the regions are part of customer Product setup and by default the following are setup :

• Europe
• North America
• South America
• Africa
• Asia
• Oceania
• Antarctica 
• European Economic Area

The user needs to override the existing default Authorization Restriction associated to one region and use the conditionCheck attribute in order to switch on/off the usage of the card in this region.

Blocking MCC

Merchant Category Code (MCC) Blocking is a functionality that allows to block a single MCC or a list of MCC.

The user needs to override the existing default Authorization Restriction and use the conditionCheck attribute in combination with the conditionParameters attribute the country codes of the countries to be blocked.

For example, for an Authorization Restriction Override created with "conditionCheck":true, "conditionParameters":["7995","7996"], authorizations from the following MCC are declined.

• 7995 Betting (including Lottery Tickets, Casino Gaming Chips, Off - track Betting and Wagers)
• 7996 Amusement Parks, Carnivals, Circuses, Fortune Tellers

The purpose of an Authorization Restriction is to allow or refuse a transaction on an Account based on given rules.

These rules are implemented with an initial customer specific Product setup and are set per default set as blocked or unblocked

The standard Authorization Restrictions are permanent and can be changed by creating some Authorization Restriction Overrides.

The standard Authorization Restrictions for Card Control are to block or unblock of :

• Channels like
  • ATM / cash
  • Card present (POS)
  • Card not present (eCommerce, telephone)
  • Card not present recurring
  • Contactless online (NFC online)
  • Magstripe
• Single country, a list of single countries
• Regions (Geo Blocking)
• Merchant category codes (MCC Blocking)

When an account is created, the default Authorization Restrictions defined on Product level are applied

In order to List authorization restrictions for account, the API GET /issuers/{issuerId}/accounts/{accountReference}/authorization-restrictions should be used by providing the issuerId of the Issuer and accountReference identifying the Account

Each Authorization Restriction is identified by an authorizationRestrictionReference and it's possible to Retrieve authorization restriction using GET /issuers/{issuerId}/accounts/{accountReference}/authorization-restrictions/{authorizationRestrictionReference} API

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