Skip to main content

Provisioning Decision

Issuer is the main authority in the provisioning request decision making. This put the responsibility to the issuer to implement the advanced logic on the decision making. Despite the circumstances that in certain cases issuer decision may be overwritten by the payment network due to the specific requirements, e.g. request yellow flow for the third-party wallets manual provisioning.

Issuer decision in provisioning process​

Every provisioning request require decision from the issuer. Token provisioning widely use the terms for green, yellow and red path in term of decision making. Token Service Provider receive the issuer decision in the response to the Authorize Service request. 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 issuer may conditonally receive the third-party wallet and payment scheme captured and generated security data that is intended to help issuers in making more advanced decision 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 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.

Red path​

General decline of the token provisioning request by issuer. Issuer is not limited to any requirements in the declines on token provisioning decision. Section Security checks on this page outline some practices issuer may or must base depending on the context while implementing the decision making logic.

Manual and Push Provisioning​

Push provisioning is initiated from the issuer mobile app when it is considered that cardholder is already securely authenticated. Issuer must be able to distingush the provisioning type and this can be done basing on the source of card information. Authorize Service request attribute cardInfo.encryptedData.source define the source of card information.

This will be always CARD_ADDED_MANUALLY for the manual provisioning from third-party wallet and CARD_ADDED_VIA_APPLICATION for the push provisioning initiated from issuer mobile app.

Card-On-File and E-commerce tokens​

Merchant or e-commerce provider token types usually does not require and may even not support the additional ID&V of cardholder. Issuer must handle it accordingly. Decision making logic must be based on distingushing the token type with the use of Authorize Service request attribute tokenType.

tokenType attribute value STATIC always stands for the Card-On-File or E-commerce(if applicable for payment network) token types.

Security checks​

Basic checks​

Issuer basic card checks thata card exists and is in 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 what is defined during the digitization project certification scope. However not all payment networks provides such service. Issuer must handle the CVC and validate it if it is received in the Authorize Service request. CVC is optionally provided in the cardInfo.encryptedData.securityCode attribute. CVC validation results must be provided by issuer in the Authorize Service response attribute cvcResponse.

There are certain circumstances when CVC can be absent in the Authorize Service request:

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

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

note

Mea Token Platform I-TSP optionally support CVC validation on-behalf of the issuer.

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 requirements for specific third-party wallets and is highly recommended against brute force attacks.

Some payment networks offer velocity check as on-behalf service. MTP I-TSP also optionally support velocity checks on-behalf of issuer.

AVS check​

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

AVS check is must be performed against the cardholder billing address provided in the Authorize Service request cardInfo.encryptedData.billingAddress object. AVS check results must be populated in attribute avsResponse of the response.

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

Third-party decision recommendations​

Authorize Service request optionally contains the data gathered and generated by token service providers and third-party wallets that is intended to guide issuers with the more advanced provisioning decision making. This data may contain the decision recommendation, reasons and risk information, e.g. device scoring. Decision recommendations are present in the walletProviderDecisioningInfo and tspDecisioningInfo objects.

note

Specific third-party wallet may imply their own rules how to handle the provided recommendations. Issuer may review this in third-party wallet specification documentation.