Skip to main content

Provisioning Decision

MeaWallet is the main authority in the provisioning request decision making. MeaWallet has implemented advanced logic on the decision making process based on Issuer needs and best practice suggestions. MeaWallet’s rule engine comply with requirements from token requester such as:

  1. Apple Pay
  2. Google Pay
  3. Samsung Pay
  4. MDES Token Connect
  5. Visa Card Enrollment Hub

Decisions made by MeaWallet regarding provisioning can in certain cases be overwritten by the payment network due to the specific requirements, e.g. request yellow flow for the third-party wallets manual provisioning.

Check card eligibility API (Issuer responsibility)​

Issuers first involvement in the provisioning decision is when receiving the Check Card Eligibility request. It is the Issuers responsibility to check whether a card is eligible for provisioning. Issuer bases this on a simple check to verify that the card exists and is in an active state. It is the issuers responsibility to review if there are any additional checks that are required. Section Security checks on this page outline some practices the Issuer may or must use depending on the context while implementing the check card eligibility logic.

After the Issuer has checked the eligibility of the card, the information must be forwarded to MeaWallet in the Check Card Eligibility response. This will continue the provisioning process and start the decision making process.

Decision in provisioning process​ (MeaWallet responsibility)​

Every provisioning request will trigger a decision made by MeaWallet. Token provisioning widely uses the terms for green, yellow and red path in terms of decision making. Different color of decisions can be interpreted as following:

  • Green as APPROVED – Approval without additional identification and verification of consumer;

  • Yellow as REQUIRE_ADDITIONAL_AUTHENTICATION – Request additional identification and verification of consumer;

  • Red as DECLINED – Decline the provisioning request, e.g. card is expired, fraud suspected etc.

Payment networks and third-party wallets may imply their own recommendations or requirements on the provisioning decisions. Additionally, the MeaWallet may conditionally receive and use the third-party wallet and payment scheme captured and generated security data that is intended to help make more advanced decisions on token provisioning requests.

Green path​

Green path as approve means that no additional identification and verification of cardholder is necessary. This usually applies to the following type of requests:

  • Push Provisioning;
  • Merchant tokens as Card-On-File or E-commerce token types.

Yellow path​

Yellow path stands for the requirement of a consumer additional identification and verification. Depending on the context it may be referred to with the different terms as ID&V, Step-Up(Visa context), Cardholder Authentication or Activation Methods(Mastercard context) etc. This guide is intended to keep all the definitions inline, but it may refer to the specific term for familiarity of context.

note

Apple’s orange path. Apple has also an Orange path which is reserved for those provisioning attempts which poses a high risk. The only step up authentication that is accepted in that case is a call center with fraud trained agents.

Red path​

General decline of the token provisioning request. The decision making entity is not limited to any requirements in the declines on token provisioning decisions. Section Security checks on this page outline some common practices that may or must be used depending on the context while implementing the decision making logic.

Security checks​

Security checks can happen at different periods during the provisioning process. However, most of them are centered around the beginning when the Issuer has received the Check Card Eligibility request. The following checks are often done when receiving Check Card Eligibility request:

  1. Basic checks
  2. CVC verification
  3. AVS Check
  4. Velocity check - optionally

If the Issuer decides to implement Velocity check themselves this could be done when receiving the Check Card Eligibility request. Otherwise the Velocity check can be implemented at different steps of the provisioning process depending on scheme & wallet context.

Basic checks​

Issuer basic card checks that a card exists and is in an active state that is subject to digitization. Issuer is responsible to review if any additional checks are required.

CVC verification​

Some payment networks may support the CVC(CVV2) verification on-behalf of what is defined during the digitization project certification scope. However not all payment networks provide such service. Issuers must handle the CVC and validate it if it is received in the Check Card Eligibility request. CVC is optionally provided in the cardInfo.encryptedData.securityCode attribute. There are certain circumstances when CVC is absent, they are described below. CVC validation results must be provided by the issuer in the Check Card Eligibility response attribute securityCodeResult.

There are certain circumstances when CVC can be absent in the Check Card Eligibility

  • Push Provisioning;
  • Merchant or E-commerce token types;
  • CVC is already validated by the payment network as on-behalf service.

Issuers must not treat the absence of CVC as a subject for the provisioning request decline. However failure of validation for provided CVC is an eligible reason for the provisioning decline.

Velocity check​

Velocity check must be implemented to handle high frequency of incorrect data entries. This must lead to the automatic decline of provisioning requests. Velocity check is a mandatory requirement for specific third-party wallets and is highly recommended against brute force attacks.

Some payment networks offer velocity checks as on-behalf service. MTP I-TSP also optionally supports velocity checks on-behalf of the issuer. Issuers can also decide to implement their own Velocity Check if they wish based on Check Card Eligibility request.

AVS check​

Address Validation Service is mandatory in the specific regions. Issuers must perform the AVS checks if such regional requirements are applicable to the entity. AVS is required in the following regions:

  • USA
  • Canada
  • United Kingdom

AVS check must be performed against the cardholder billing address provided in the Check Card Eligibility request cardInfo.encryptedData.billingAddress object. AVS check results must be populated in attribute avsResult of the response.

AVS check failure may be subject to the provisioning request decline.