Visa Data Only (VDO)

overview the visa data only (vdo) integration grants access to visa's digital commerce authentication program (dcap), allowing eligible merchants to qualify for an interchange discount of up to 5 basis points (0 05%) when rich transaction data is shared with the issuer through the 3ds protocol unlike standard 3ds authentication, the data only flow does not produce a liability shift — liability is retained by the merchant — but a fully frictionless experience is delivered to the cardholder with no challenge step, while additional transaction data is relayed to the issuer with the intention of increasing authorization rates and reducing fraud declines vdo is intended for merchants who are not looking for the issuer to authenticate the transaction (for the purpose of fraud protection and liability shift), and who would benefit from potentially higher bank authorization rates and lower interchange fees (when the transaction is qualified for dcap by visa) eligible transactions dcap applies to card type visa consumer credit, u s domestic (not debit) protocol emv 3ds v2 1 or v2 2+ eci 07 (data only) transaction type card not present, customer initiated issuer must support vdo integration steps confirm prerequisites it must be verified that both forter's and your psp's integration requirements are met before development commences psp support for dcap it should be confirmed with your psp that their authorization api supports the passing of cavv and dstid (directory server transaction id) specifically in the context of dcap (not only for standard 3ds authentication) a specific indicator flag may be required by some psps in order for the interchange discount to be triggered it should also be verified with your psp that dcap is enabled at your specific mid even where psp support exists, the interchange discount is only passed through when explicitly configured acquirer and merchant data it must be confirmed that all the details about the expected authorization process can be passed in the order api acquirer data acquirer name (name of acquirer — e g barclays) acquirer bin (bin assigned to merchant by acq ) acquirer country (country of acquiring bank) merchant data acquirer merchant id (merchant id assigned to merchant by acq ) acquirer merchant name (merchant name assigned to merchant by acq ) merchant category code (mcc assigned to merchant by acq ) merchant country code (country in which the merchant's acq account is set up) note in some cases the gateway, acquirer, and processor services are provided by the same company bin & last 4 it must be verified that the card's bin number and last four digits can be passed in forter's order api request to cover both 6 digit and 8 digit bin scenarios, 8 digits should be provided in the bin field front end integration the instructions for front end integration https //docs forter com/front end integration for fraud management should be followed, including the installation of mobile sdks on your mobile applications the device id (fingerprint) collected here is a mandatory data element for dcap eligibility send order api request as with the checkout integration https //docs forter com/checkout integration for fraud management, the complete order details must be sent to forter in the order api in order for a real time fraud decision to be returned, along with a payment optimization recommendation for the authorization call the request must be sent before the payment gateway is called to authorize funds (pre auth flow) the full request and response data can be found in our order api reference documentation mandatory data for dcap eligibility for a transaction to qualify for the dcap interchange discount, the following data points must be included in the order api request field notes cardholder email required by visa for dcap eligibility billing address required by visa for dcap eligibility ip address required by visa for dcap eligibility device id (fingerprint) collected via forter's front end sdk the full request and response schema is available in the order api v3 reference https //docs forter com/reference/order v3 handle order api response the response will include forter's fraud decision, along with a recommendation regarding whether visa data only or standard 3ds should be executed during the authorization call outcome call to action order response fields forter approved transaction is approved by forter, no data only or 3ds recommended standard authorization "forterdecision" "approve", "verificationmethod" {} forter approved & recommends visa data only transaction is approved by forter and forter recommends that vdo be executed during the authorization call authorize with data only "forterdecision" "approve", "recommendation" "verification required data only" forter declined transaction is declined by forter do not authorize "forterdecision" "decline", "verificationmethod" {} forter did not review transaction was not reviewed for a fraud decision act according to policy prior to forter integration "forterdecision" "not reviewed", "recommendation" "", "verificationmethod" {} request authorization with data only when visa data only is recommended by forter, a request should be passed to the psp for the data only flow to be executed during authorization the integration with the psp should be adjusted so that the data only request flag is included in the psp authorization request the following fields must be relayed by the psp to visa within the authorization payload field value description cavv cryptogram cavv identifying the transaction as data only eci 07 (u s ) signals a data only attempt; eci 05/02 must not be used, as this would signal full authentication dstransid uuid directory server transaction id — links the 3ds data session to the financial authorization threedsversion 2 1 or 2 2 the 3ds protocol version used ⚠️ the use of eci 05 or eci 02 would imply a full authentication, and the transaction would be disqualified from the dcap discount verify data only recommendations with psp it should be confirmed that authorization requests with data only recommendations are being correctly received by the psp on live transactions, and that the dcap interchange discount is being applied visa data only execution the visa data only execution integration is an alternative flow in which the visa data only request is executed by forter on your behalf , and the resulting authentication values are returned for inclusion in your authorization request to your psp this is useful for merchants who do not have a 3ds provider in place or who wish to consolidate 3ds execution with forter forter's standard 3ds execution fee applies to data only requests sent to visa under dcap both standard 3ds and 3ds data only are 3ds requests to the issuer and incur the same fee to forter additional prerequisites for execution in addition to the prerequisites listed above, the following is required for the execution flow full pan it must be verified that the full credit card number can be passed in the order api this information is required for visa dcap execution by forter to be triggered if vaulted cards are in use and the full card number is not exposed on the checkout page, your tokenization vendor should be consulted regarding the availability of a detokenization proxy service (aka forward proxy) this service enables a request to be made to a 3rd party (such as forter order api) with a token included in the request the request is then routed through the proxy, where the token is replaced with the corresponding card data specifying the 3ds execution path the execute3ds field in the order api request ( payment creditcard threedsecure execute3ds ) should be set to indicate whether the data only path or standard 3ds should be followed for the transaction execute3ds value behavior force data only the vdo (data only) flow is executed by forter — no cardholder challenge, no liability shift force 3d standard 3ds is executed by forter — the cardholder may be challenged by the issuer, and liability is shifted on authentication and bank authorization supported in api version 2 18 handle order api response (execution flow) dcap eligibility is determined automatically by forter during 3ds initialization, by checking whether the bank's acs (access control server — issuer side of 3ds) supports the data only flow when eligible, the vdo flow is executed by forter, and the result values are returned in the order api response outcome order response fields data only executed successfully "verificationmethod" {"status" "data only"} , along with cavv , eci (07), dstransid , and threedsversion fields populated bank acs does not support data only "verificationmethod" {} (empty) — data only fields must not be passed to the psp network error during execution "verificationmethod" {"status" "network error"} — data only fields must not be passed to the psp