Request Handling
Payment networks and third-party wallets may imply the additional requirements for issuer that require to keep the trace of incoming requests and handle them accordingly or trigger specific events.
Abandoned provisioning
Third-party wallets may have the requirements to handle the abandoned provisioning accordingly, e.g. notify and remind customer that he started provisioning but didn’t finished it within 24 hours or to delete the token if provisioning is abandoned for more than 30 days.
Issuer must handle and store the incoming requests from Pre-Digization API accordingly to implement the requirements for abandoned provisioning. Stored incoming requests must have the timestamp that defines when they were received.
Provisioning can be considered as a completed when “Notify Service Activated” request is received from MeaWallet Pre-Digization API.
To determine the abandoned provisioning issuer must define when it was started. This can be done basing on the “Authorize Service” request with the issuer response in decision attribute as REQUIRE_ADDITIONAL_AUTHENTICATION.
Until the “Notify Service Activated” request that belongs to the same provisioning attempt received process can be considered as incomplete. Issuer must base on the value of attribute correlationId in order to link requests related for the same provisioning attempt.
Succesful provisioning
Issuer must automatically notify cardholders about the succesful provisioning into the third-party wallet. This requirement only applies to the third-party wallets and must not be implemented for STATIC token types as Card-On-File or E-commerce purpose tokens. STATIC token types must be ignored because token provisioning may be requested in the background without cardholder notice, e.g. over night PCI card-on-file tokens conversion to the network card/token-on-file tokens by merchant or payment service provider.
"Notify Service Activated" request received by the issuer is the foreseen trigger action for cardholder notification about the succesful token provisioning.
This is recommended to separate tenured communication channels with cardholder and on the succesful provisioning through tenured channel that was not used during the identification & verification.
Token details storage
Issuer may decide to accumulate the received token details for history, browsing and reporting purposes. Notify Service Activated and Notify Token Updated requests contains the available token details that issuer may structure and store.