Hi!
We at MeaWallet are working with close to 50 banks, issuers & fintechs helping them with VTS and mobile/digital payments.
We want to provide a "Token Control" product and I want to understand if we can use the Visa Transaction Control/CustomerRules API for this.
Can we use https://developer.visa.com/capabilities/vctc/reference#vctc__customer_rules__v1__decouple_tokens and then set specific limitations/alerts on a token level?
Example use case(s):
Is this possible or can it only be done on a PAN/card level?
Warm regards,
Thomas
Solved! Go to Solution
Hi @meawallet
As per the new mandate of VTS, CTF (Cloud Token Framework) should be implemented to enable the device binding for those Tokens provisioned from TR / Merchant App.
Using CTF, From Issuer Wallet(Bank) App the user can easily register / delete those tokens used by third party.
Further more, on the spending limit etc are done using the Transaction Control API.
Thank You
Paul
Hey @meawallet,
To follow up, sorry for the delayed response. This is a good use case and, yes, your assumption is correct. We can support your use cases as described. Please let us know if you have other questions and someone will be happy to help.
Thanks Diana! We've started our integration and look forward to start testing together with some of our issuers 🙂
Hi Diana!
It seems that there is a dependency on the processor supporting Visa Transaction Controls. Do you know if this dependency is valid also if we are only using VTC on tokens (i.e. not cards/FPANs)?
Hey @meawallet,
I'll get back to you on this.
Hey @meawallet,
Can you please provide an explanation of what is meant by: “there is a dependency on the processor supporting Visa Transaction Controls”?
In general, VTC can be used in a token-only scenario.
Token Controls (Optional):
VTC can be used to manage Primary Account Numbers (PAN), payment tokens or both. If card controls are set on the:
• PAN, they will also be applied to its token transactions – unless configured otherwise. Token, then they will only apply to that token.
• The PAN and token, then both documents will be reviewed – unless configured otherwise. A single alert is sent if the user has notification rules configured on both.
NOTE: If the PAN is set to “DeclineAll”:true; then any attempt to provision a token will most likely fail. declineAllNonTokenizedTransactions can only be use with the global control.
Decoupling Tokens:
Tokens can have their own VTC rules completely divorced from a PAN’s VTC rules. Using the
“decoupleTokenRequest” a token can be managed independently with its own VTC blocks, thresholds and alert settings. The decoupleTokenRequest can be configured on either a token’s control document (recommended approach) or a PAN’s control document (use-case dependent):
• Set on a token’s control document and populated with the token number, VTC will ignore any other VTC control document rules (PAN). Only the token’s VTC rules will be applied – recommended.
• Set on a PAN’s control document and populated with the token number(s), VTC will ignore all transactions made with these tokens (unless separately enrolled - see prior bullet).
Hi Diana,
Thanks for the reply.
The dependency on the processor seems to be present during the payment transaction flow of a card that is enrolled with VTC. From the copied text below, we understand that the processor must update its system to be able to receive and handle "STIP messages" from Visa whenever a card transaction is declined in VTC.
"Visa sends an Advice msg (120) to the issuer with new STIP Reason Code “9037” identifying the transaction as declined due to VTC settings. The issuer processor will have to update their authorization platform to accept this new value in an existing field." (source: https://developer.visa.com/capabilities/vctc).
Can you confirm if this the above is required, or if we are able to actually enable VTC without involving issuer processor?
Many thanks in advance.
Hey @meawallet,
We'll get back to you soon on this.
Hey @meawallet,
It is NOT required for the Issuer/Processor to make this change to accept the new 9037, STIP REASON code value.
The issuer/processor would already receive the STIP REASON field. The specific field value of 9037, would inform the Issuer/Processor that the transaction was declined as a result of a VTC transaction control.
Let us know if you have other questions, we're happy to help.