Getting Started With Visa Checkout

Checking out and paying with Visa Checkout begins when your customer clicks on the Visa Checkout button that has been placed on your shopping cart and/or payment page. The pages on which you place a Visa Checkout button must load the Visa Checkout JavaScript library so that Visa Checkout can send an initialization event when the page is loaded. Your application responds to this initialization event by setting characteristics that will define the way you want the lightbox to appear and operate and how you want payment requests to be handled.

When your customer clicks the Visa Checkout button, the Visa Checkout lightbox appears, allowing the consumer to sign in and make a payment or first create a new account and then make a payment. After signing in to Visa Checkout, the consumer can change the payment method and, if enabled to do so, change the shipping address. When the consumer finishes and the lightbox closes (or an error occurs), Visa Checkout will send your application a payment event that includes status information and a call ID that you can use to identify the payment request.

Visa Checkout offers several options for handling the consumer payment information returned by the payment event and for updating Visa Checkout with the payment processing results. You can:

Of the options available, the simplest approach to integrating Visa Checkout takes three steps and can be done entirely from within your web page (except decrypting the consumer information payload on a secure server).

Getting Started

  1. Place a Visa Checkout button on your web page and include the necessary JavaScript to handle events associated with the button.
  2. Handle the payment event returned by Visa Checkout by decrypting the consumer information payload.
  3. Update Visa Checkout with the final payment information after the payment has been processed.

All integration options require that you perform step 1. There are several approaches to performing steps 2 and 3 and each is described in other sections.

Adding Visa Checkout to Your Web Page

The first piece of any integration effort is placing a Visa Checkout button on your shopping cart and/or payment pages. Note: the page to which you are adding a Visa Checkout button must be hosted on a web server for the lightbox and JavaScript library to perform as expected.

Step One: Add the onVisaCheckoutReady JavaScript function to the <head> and include the V.init event handler with your API key. The V.init event handler lets you specify initialization values that control the appearance and behavior of the lightbox and the contents of the payment request that will be presented to the consumer:

<head>
  <script type="text/javascript">
    function onVisaCheckoutReady (){
    V.init({ apikey: "7O07VN664O10JW6A9ESS113p8sf9JeGzr6_2haC9F9m_ANtLM"});
    }
  </script>
</head>

You can go back later and specify your logo and other settings to customize the appearance of the Visa Checkout lightbox. (Learn more about that in the section on Submitting the Consumer Payment Request.)

Step Two: Inside V.init, you also specify the amount and currency of the consumer’s payment request in the paymentRequest properties:

paymentRequest:{
     currencyCode: "USD",
     total: "11.00"
     }

This is the simplest payment request you can implement. Using other paymentRequest properties, you can also specify amounts for tax, discounts, shipping, and such that will be shown to the consumer in the lightbox or, if you don’t have all that information in advance, you can include these amounts in the payment update after the lightbox closes. (Learn more about that in the section on Submitting the Consumer Payment Request.)

Step Three: Add V.on event handlers, one for each of the three possible payment events: payment.success (the consumer agreed to the payment request), payment.cancel (the consumer cancelled the payment request), or payment.error (an error occurred).

V.on("payment.success", function(payment) {alert(JSON.stringify(payment)); });
V.on("payment.cancel", function(payment) {alert(JSON.stringify(payment)); });
V.on("payment.error", function(payment,error) {alert(JSON.stringify(error));});

In addition to the Visa Checkout payment request ID (callId), Visa Checkout optionally returns the encrypted payload. (Learn more about handling payment events and an encrypted payload in the section on Handling Payment Events.)

Step Four: Place one or more Visa Checkout buttons in the body of the page:

<body>
  <img alt="Visa Checkout" class="v-button" role="button"
   src="https://sandbox.secure.checkout.visa.com/wallet-services-web/xo/button.png"/>
...

You can define additional properties for the button (such as size, color, or card brands accepted), some of which may override those set in the V.init handler. (Learn more about that in the section on Customizing the Button.)

Step Five: At the end of the body, load the Visa Checkout JavaScript library sdk.js:

<script type="text/javascript"
src="https://sandbox-assets.secure.checkout.visa.com/
checkout-widget/resources/js/integration/v1/sdk.js">
</script>
</body>

After completing these steps, you should have a web page whose source looks like this:

<html>
<head>
 <script type="text/javascript">
  function onVisaCheckoutReady(){
  V.init( {
  apikey: "7O07VN664O10JW6A9ESS113p8sf9JeGzr6_2haC9F9m_ANtLM",
   paymentRequest:{
    currencyCode: "USD",
    total: "10.00"
  }
  });
V.on("payment.success", function(payment)
  {alert(JSON.stringify(payment)); });
V.on("payment.cancel", function(payment)
  {alert(JSON.stringify(payment)); });
V.on("payment.error", function(payment, error)
  {alert(JSON.stringify(error)); });
}
</script>
</head>

<body>
<img alt="Visa Checkout" class="v-button" role="button"
src="https://sandbox.secure.checkout.visa.com/wallet-services-web/xo/button.png"/>
<script type="text/javascript"
src="https://sandbox-assets.secure.checkout.visa.com/
checkout-widget/resources/js/integration/v1/sdk.js">
</script>
</body>
</html>

When you are ready to begin testing your integration, you will need to create Visa Checkout consumer test accounts in the sandbox and add at least one payment method to them. You can start by creating your own test consumers through the New User link when the Visa Checkout lightbox is opened. You will be shown an Add a New Payment Method screen in which you must enter a card number.

You can enter any values on this screen that make sense to you, except that you must use one of the following card numbers. The name on card, expiration date, and security code are not validated in the sandbox, so you can enter any valid value. Because card numbers are validated by Visa Checkout on entry, you should only use these numbers for sandbox testing.

Visa: 4005520201264821 (without card art)

Visa: 4242424242424242 (with card art)

Visa: 4622943125902958 (with token info)

MasterCard: 5500005555555559

American Express: 340353278080900

Discover: 6011003179988686

Customizing the Button

If you want to specify the look and behavior of the Visa Checkout button, you can use the v-button img class to change its default valuesCustomized buttons must follow the guidelines defined in the User Interface Guidelines section.

v-button Parameters Description
size Optional. Selects a standard width of the button in pixels. You can use size to select one of three standard button sizes or you can useheight and width instead to specify a custom size. If you do not specify size, the button will default to 213 pixels. If you specify height or width, any value of size is ignored.

Format: Either 154 (small), 213 (medium), or 425 (high resolution or large).
height Optional. Specifies the height of the button, in pixels, for a custom size button. You must specify height if you specify width. The value you choose for height determines the allowable range of values for width.

Format: Either 34, 47, or 94.
width Optional. Specifies the width of the button, in pixels, for a custom size button. You must specify width if you specify height.

Format: If height is 34, width must be less than 477 or it defaults to 154. If height is 47, width must be between 212 and 659 or it defaults to 213. If height is 94, width must be between 424 and 1317 or it defaults to 425.
locale Optional. By default, Visa Checkout determines the locale of the transaction from the consumer’s browser settings (the Accepted-Language value in the HTTPS header). This property allows you to override that. Do not use locale unless explicit control over the button is required.

Format: One of the following values:
• es_AR - Argentina, Spanish
• en_AU - Australia, English
• pt_BR - Brazil, Portuguese
• en_CA - Canada, English
• fr_CA - Canada, French
• en_CN - China, English
• zh_CN - China, Simplified Chinese
Note: –For display purposes only; input is in English.
• es_CL - Chile, Spanish
• es_CO - Colombia, Spanish
• zh_HK - Hong Kong, Chinese
Note: –For display purposes only; input is in English.
• en_HK - Hong Kong, English
• en_MY - Malaysia, English
• es_MX - Mexico, Spanish
• es_PE - Peru, Spanish
• en_NZ - New Zealand English
• en_SG - Singapore, English
• en_ZA - South Africa, English
• en_AE - United Arab Emirates, English
• en_US - United States, English
color Optional. The color of the Visa Checkout button.

Format: Either standard or neutral. Any other value will default to standard.
cardBrands Optional. Override value for brands associated with the card art to be displayed on the button. If a brand matching the consumer’s preferred card is specified, the card art is displayed on the button; otherwise, a generic button is shown.

Format: a comma-separated list that includes one or more of VISA, MASTERCARD, AMEX,DISCOVER, ELECTRON (Brazil only), or ELO (Brazil only).
acceptCanadianVisaDebit Specifies if a Canadian merchant accepts Visa Canada debit cards. A value is required for Canadian merchants and is ignored for all others. If true, Visa must be specified as an allowable card brand in cardBrands.

Format: Either true (accepts) or false (does not accept).

You should also include a Tell Me More link on your web page that a consumer can click to learn more about Visa Checkout. (See the examples in the section in User Interface Guidelines for more details.)

Use the v-learn <a> (hyperlink) class to provide a link that the consumer can click. The class causes a pop-up window to appear. By default, the text will be shown in English (data-locale="en_US") unless you specify a different value for data-locale. The v-learn class does not include styling. To provide default styling, also include the v-learn-default class. The Visa Checkout button and the Tell Me More link must be wrapped inside a parent <div> whose width is the same as the width of the button. Here is an example with default styling:

<div class="v-checkout-wrapper">
  <img
     class="v-button" role="button" alt="Visa Checkout"
     src="https://sandbox.secure.checkout.visa.com/wallet-services-web/xo/button.png">
  <a class="v-learn v-learn-default" href="#" data-locale="en_US">Tell Me More</a>
</div>

Submitting the Consumer Payment Request

An earlier article explained how to create the simplest possible consumer payment request. Visa Checkout has many more options for creating and initializing payment requests. The V.init event handler offers many optional properties that you can use to enable more complex payment requests. The V.init event handler requires your API Key (apikey) and, if applicable, the unique ID that identifies you as a Visa Checkout client (externalClientId). You can get a Test API key and Client ID for sandbox testing online through the Application Console. Production API keys and a Client ID will be given to you as part of the production on-boarding process. You can specify values for the properties described below:

V.init Properties Description
apikey Required. The sandbox or production API key (as applicable) issued to you by Visa.

Format: Alphanumeric maximum 100 characters
referenceCallID Optional. This is a Visa Checkout transaction ID that can be used in conjunction with the Preselected Checkout feature.

Format: Alphanumeric maximum 48 characters.
externalProfileId Optional. Profile ID and profile name that is created externally by a merchant or partner and is used to populate settings such as accepted card brands and shipping regions. If included it will override any properties set in the merchant’s current profile.

Format: Alphanumeric maximum 50 characters.
externalClientID Not required for merchants. For partners, it is the unique ID associated with a partner's client, such as the ID of a merchant onboarded by the partner. Typically, the external client ID is assigned by a partner; however, Visa Checkout assigns a value if one is not specified.

Note: Some integration strategies, such as that for a hosted order solution, may require specific values to be set; contact your Visa Checkout representative for more information.

Format: Alphabetic, numeric, hyphens ( - ), and underscores (_ ), e.g. spaces are not allowed; maximum 100 characters

Format: Alphanumeric maximum 100 characters
settings Optional. One or more name-value pairs that can be used to configure the payment request. (See the settings table for details.)
paymentRequest Optional. One or more name-value pairs that define the payment request to be presented to the consumer for confirmation in the lightbox. (See the paymentRequest table for details.)

 

Settings Properties Description
locale Optional. By default, Visa Checkout determines the locale of the payment from the consumer’s browser settings (the Accepted-Language value in the HTTPS header). This property allows you to override that. Do not use locale unless explicit control over the lightbox display is required. The value of locale must be compatible with the value of countryCode.

Format: One of the following values:
• es_AR - Argentina, Spanish
• en_AU - Australia, English
• pt_BR - Brazil, Portuguese
• en_CA - Canada, English
• fr_CA - Canada, French
• en_CN - China, English
• zh_CN - China, Simplified Chinese
Note: For display purposes only; input is in English.
• es_CL - Chile, Spanish
• es_CO - Colombia, Spanish
• zh_HK - Hong Kong, Chinese
Note: For display purposes only; input is in English.
• en_HK - Hong Kong, English
• en_MY - Malaysia, English
• es_MX - Mexico, Spanish
• es_PE - Peru, Spanish
• en_NZ - New Zealand English
• en_SG - Singapore, English
• en_ZA - South Africa, English
• en_AE - United Arab Emirates, English
• en_US - United States, English
countryCode Optional. By default, Visa Checkout determines the country code from the consumer’s IP address. This property allows you to override that. Do not use countryCode unless explicit control over the lightbox display is required. The value of countryCode must be compatible with the value of locale.
Format: One of the following ISO-3166-1 alpha-2 standard
codes:
• AR - Argentina
• AU - Australia
• BR - Brazil
• CA - Canada
• CN - China
• CL - Chile
• CO - Colombia
• HK - Hong Kong
• MY - Malaysia
• MX - Mexico
• PE - Peru
• NZ - New Zealand
• SG - Singapore
• ZA - South Africa
• AE - United Arab Emirates
• US - United States
logoUrl Optional. By default, the Visa Checkout logo appears. This property allows you to specify an HTTPS URL path to a different logo that you want to show. Your image must conform to the User Interface guidelines.

Format: HTTPS URL, maximum 256 characters
displayName Optional. The merchant’s name as it will appear on the Review panel of the lightbox; typically, it would be the name of your company.

Format: Either alphabetic, numeric, spaces, or the following characters: ! @ # $ % ^ & * -' ? and period ( . ). Maximum 100 characters
websiteUrl Optional. The complete URL of your website.

Format: Valid HTTP URL, maximum 256 characters
customerSupportUrl Optional: Your customer service or support URL

Format: Valid HTTP URL, maximum 256 characters.
shipping Optional. One or more name-value pairs that can be used to configure the shipping information in the lightbox. (See the shipping table for details.)
review Optional. One or more name-value pairs that can be used to configure the review properties of the lightbox. (See the review table for details.)
payment Optional. One or more name-value pairs that can be used to configure the allowable payment methods in the lightbox. See the payment table for details.
threeDSSetup Optional. One or more name-value pairs that can be used to set up Verified by Visa for use in your Visa Checkout experience.
dataLevel Optional. The level of consumer and payment information that the payment.success event should include. To receive full information, you must have permission from Visa to do so; otherwise, you will receive only summary information regardless of this setting.

Format: Either SUMMARY, FULL, or NONE.
welcomeTitleMessage Optional. Custom-branded lightbox welcome title. For details, contact your Visa Checkout representative.
welcomeContentMessage Optional. Custom-branded lightbox welcome message, which is displayed to consumers during the initial sign-in. For details, contact your Visa Checkout representative.
returningMessage Optional. Custom-branded lightbox welcome message, which is displayed to consumers during subsequent sign-ins. For details, contact your Visa Checkout representative.
backgroundImageId Optional. ID representing a Custom-branded lightbox background image. For details, contact your Visa Checkout representative.

 

Shipping Properties Description
acceptedRegions Optional. List of country codes that override the values for shipping region country codes from the merchant’s standard profile (which limit the consumer’s selection of eligible ship-to addresses). If not set in the profile or overridden here, ship-to addresses will be allowed for any non-restricted country.

Format: One of the following ISO-3166-1 alpha-2 standard
codes:
• AR - Argentina
• AU - Australia
• BR - Brazil
• CA - Canada
• CN - China
• CL - Chile
• CO - Colombia
• HK - Hong Kong
• MY - Malaysia
• MX - Mexico
• PE - Peru
• NZ - New Zealand
• SG - Singapore
• ZA - South Africa
• US - United States
collectShipping Optional. Determines whether to obtain a shipping address from the consumer.

Format: Either true (obtain, the default) or false (not required).

 

Review Properties Description
message Optional. Your message to display on the lightbox Review page. You are responsible for translating the message.

Format: Alphabetic, numeric, spaces, or the following characters: ! @ # $ % ^ & * - ' ? and period ( . ). Alphanumeric, Mmaximum 120 100 characters.
buttonAction Optional. The label to be used for the button that closes the Visa Checkout lightbox.

Format: Either Continue (the default) or Pay. The Pay label requires a value for total and is not available for all currencies.

 

Payment Properties Description
cardBrands Optional. Defines the card brands that are accepted.

Format: Array containing one or more of VISA, MASTERCARD, AMEX, DISCOVER, ELECTRON (Brazil only), or ELO (Brazil only).
acceptCanadianVisaDebit Optional. Override of whether a Canadian merchant accepts Visa Canada debit cards. If true, Visa must be specified as an allowable card brand. Ignored for non-Canadian merchants.

Format: Either true (accepts) or false (does not accept).
billingCountries Optional. Overrides the values for billing country codes from the merchant’s standard profile (which limits the selection of eligible cards from the consumer’s account). If not set in the profile or overridden here, payments from all billing countries are accepted.

Format: One of the following ISO-3166-1 alpha-2 standard
codes:
• AR - Argentina
• AU - Australia
• BR - Brazil
• CA - Canada
• CN - China
• CL - Chile
• CO - Colombia
• HK - Hong Kong
• MY - Malaysia
• MX - Mexico
• PE - Peru
• NZ - New Zealand
• SG - Singapore
• ZA - South Africa
• US - United States

 

Verified by Visa Setup Properties Description
threeDSActive Optional. Whether Verified by Visa (VbV) is active for this transaction. If Verified by Visa is configured, you can use threeDSActive to deactivate it for the transaction; otherwise, VbV will be active if it has been configured.

Format: False - Do not use Verified by Visa for this transaction.
threeDSSuppressChallenge Optional. The label to be used for the button that closes the Visa Checkout lightbox.Optional. Whether a Verified by Visa (VbV) consumer authentication prompt is suppressed for this transaction. If true, VbV authentication is performed only when it is possible to do so without the consumer prompt.

Format: True or False

 

PaymentRequest Properties Description
merchantRequestId Optional. Merchant’s ID associated with the request. Visa Checkout stores this value as a convenience for your use.

Format: Alphanumeric, maximum 100 characters
currencyCode Required. The currency in which to process the transaction.

Format: It is one of the following ISO 4217 standard alpha-3
code values:
• ARS - Argentine Peso
• AUD - Australian Dollar
• BRL - Brazilian Real
• CAD - Canadian Dollar
• CNY - Yuan Renminbi
• CLP - Chilean Peso
• COP - Colombian Peso
• HKD - Hong Kong Dollar
• MYR - Malaysian Ringgit
• MXN - Mexican Peso
• NZD - New Zealand Dollar
• PEN - Nuevo Sol - Peru
• SGD - Singapore Dollar
• ZAR - Rand
• AED - UAE Dirham
• USD - US Dollar
subtotal Required. Subtotal of the payment amount.

Format: Numeric, maximum 9 digits with optional decimal point and 2 decimal digits.
shippingHandling Optional. The total of shipping and handling charges in the payment amount.

Format: Numeric, maximum 9 digits with optional decimal point and 2 decimal digits.
tax Optional. The total of tax-related charges in the payment amount.

Format: Numeric, maximum 9 digits with optional decimal point and 2 decimal digits.
discount Optional. The total of any discounts applied in the payment amount. If provided, it is a positive value that represents the amount to be deducted from the total.

Format: Numeric, maximum 9 digits with optional decimal point and 2 decimal digits.
giftWrap Optional. The total of any gift-wrapping charges in the payment amount.

Format: Numeric, maximum 9 digits with optional decimal point and 2 decimal digits.
misc Optional. The total of any uncategorized charges in the payment amount.

Format: Numeric, maximum 9 digits with optional decimal point and 2 decimal digits.
total Optional. The total of the payment, including all amounts.

Format: Numeric, maximum 9 digits with optional decimal point and 2 decimal digits.
orderId Optional. The merchant’s order ID associated with the payment.

Format: Alphanumeric, maximum 100 characters.
description Optional. A description associated with the payment.

Format: Alphabetic characters, digits, spaces ( ), periods (.), underscores (_), and hyphens (-);, maximum 100 characters.
promoCode Optional. A list of promotion codes associated with the payment. Multiple promotion codes are separated by a period (.).

Format: Alphabetic characters, digits, spaces ( ), underscores (_), and hyphens (-).maximum 100 characters total
customData Optional. Merchant supplied custom data, provided as name-value pairs.

Format: Alphanumeric, maximum 1024 characters.

Visa Checkout is optimized for mobile browsers even if your website's checkout flow is not. Support is available for iOS and for Android devices. In order to allow an optimized Visa Checkout experience from a mobile web browser, add the following <meta> tag to your HTML <head> block.

<html>
<head>
. . .
<meta name="viewport"
content="width=device-width, initial-scale=1.0, maximum-scale=1.0,
user-scalable=no" />
. . .
</head>

Handling Payment Events

A payment event occurs when the consumer completes the payment request (payment.success), the consumer closes the lightbox before confirming the payment request (payment.cancel), or an error occurs while the lightbox is open (payment.error). A successful payment event returns encrypted consumer payment information in the payload that includes card verification, authentication, and risk information, and may include the consumer’s primary account number (PAN) if your Visa Checkout agreement with Visa permits it.

What you do with the consumer's payment information from a successful payment event depends on what information you need and how you plan to complete the payment. You have three choices for handling the event:

The response associated with the payment.success event returns the following information, described below:

Success Event Properties Description
callId The Visa Checkout transaction ID associated with a payment request. By default the callId does not expire. You can request an expiration for a specified number of days, but it should be greater than the merchant session timeout.

Format: Alphanumeric, maximum 48 characters
responseStatus Status of the response.

Format: The responseStatus structure contains four properties:
status (numeric HTTPS response status)
code (numeric internal subcode)
severity (either ERROR or WARNING)
message (alphanumeric description of the error)
encKey Encrypted dynamic key to be used to decrypt encPaymentData. You will use your API shared secret to decrypt this key.

Format: Alphanumeric, maximum 128 characters
encPaymentData Encrypted consumer and payment data that can be used to process the transaction. You decrypt this by first decrypting the encKey value, then using that key to decrypt this one. The tables below provide information about the specific data fields provided in the payload.

Format: Alphanumeric, maximum 1024 characters
externalClientID Merchant ID of the merchant receiving the payment

Format: Alphanumeric, maximum 100 characters
partialShippingAddress Partial shipping address of the consumer.

Format: This structure contains two properties:
countryCode (2-character code for ship-to country)
postalCode (max 128-character ship-to postal code)

A payment.cancel event will return only a callId. A payment.error event will return only a responseStatus.

Before you can use the consumer's payment information, you will need to decrypt it. First, you must decrypt the dynamic key (encKey), then use the decrypted dynamic key value to decrypt the payment data payload (encPaymentData). Follow these four steps to decrypt the encKey:

  1. Base64-decode the encKey.
  2. Remove the first 32 bytes of the decoded value. This is the HMAC (Hash Message Authentication Code). Calculate a SHA-256 HMAC of the rest of the decoded data using your API Shared Secret and compare it to the HMAC from the first 32 bytes.
  3. The next 16 bytes should be removed and used as the IV (Initialization Vector) for the decryption algorithm.
  4. Decrypt the remaining data using AES-256-CBC, the IV from step 3, and the SHA-256 hash of your API Shared Secret.

Follow these four steps to decrypt the encPaymentData using the decrypted encKey:

  1. Base64-decode the encPaymentData.
  2. Remove the first 32 bytes of the decoded value. This is the HMAC. Calculate a SHA-256 HMAC of the rest of the decoded data using the decrypted encKey and compare it with the HMAC from the first 32 bytes.
  3. The next 16 bytes should be removed and used as the IV for the decryption algorithm.
  4. Decrypt the rest of the encPaymentData payload using AES-256-CBC, the IV from step 3, and the SHA256-hash of the decrypted encKey.

The following Java code provides an example of decrypting the payload (using the Bouncy Castle API and bcprov-jdk15on-149.jar). Encryption in Java requires the Java Cryptography Extension (JCE) Unlimited Strength Policy files.

   private static final String CIPHER_ALGORITHM = "AES/CBC/PKCS5Padding";
   private static final String HASH_ALGORITHM = "SHA-256";
   private static final String HMAC_ALGORITHM = "HmacSHA256";
   private static final int IV_LENGTH = 16, HMAC_LENGTH = 32;
   private static final Charset utf8 = Charset.forName("UTF-8");
   private static final Provider bcProvider;
   static {
    bcProvider = new BouncyCastleProvider();
    if (Security.getProvider(BouncyCastleProvider.PROVIDER_NAME) == null) {
     Security.addProvider(bcProvider);
    }
   }

private static byte[] decrypt(byte[] key, byte[] data) throws GeneralSecurityException {
     byte[] decodedData = Base64.decode(data);
     if (decodedData == null || decodedData.length <= IV_LENGTH) {
      throw new RuntimeException("Bad input data.");
      }
     byte[] hmac = new byte[HMAC_LENGTH];
     System.arraycopy(decodedData, 0, hmac, 0, HMAC_LENGTH);
     if (!Arrays.equals(hmac,
      hmac(key, decodedData, HMAC_LENGTH, decodedData.length – HMAC_LENGTH))) {
    throw new RuntimeException("HMAC validation failed.");
     }
     byte[] iv = new byte[IV_LENGTH];
     System.arraycopy(decodedData, HMAC_LENGTH, iv, 0, IV_LENGTH);
     Cipher cipher = Cipher.getInstance(CIPHER_ALGORITHM, bcProvider);
     cipher.init(Cipher.DECRYPT_MODE, new SecretKeySpec(hash(key), "AES"),
      new IvParameterSpec(iv));
     return cipher.doFinal(decodedData, HMAC_LENGTH + IV_LENGTH,
      decodedData.length – HMAC_LENGTH – IV_LENGTH);
     }

private static byte[] hash(byte[] key) throws NoSuchAlgorithmException {
     MessageDigest md = MessageDigest.getInstance(HASH_ALGORITHM);
     md.update(key);
     return md.digest();
     }

private static byte[] hmac(byte[] key, byte[] data, int offset, int length)
      throws GeneralSecurityException {
     Mac mac = Mac.getInstance(HMAC_ALGORITHM, bcProvider);
     mac.init(new SecretKeySpec(key, HMAC_ALGORITHM));
     mac.update(data, offset, length);
     return mac.doFinal();
     }

Preselected Checkout Feature

The preselected checkout feature allows you to set the initial values for the consumer's card, shipping address, and billing address, based on those used in a previous payment request, identified by a call ID. This feature enables you to offer the consumer a way to change the card or address before confirming a payment. If you retain call IDs, you can also use this feature in other ways; for example, to establish a card on file for a future payment request. To preselect the consumer's card, shipping address, and billing address for a payment:

  1. Specify the call ID of a previous request in the referenceCallID attribute of the V.init structure.
  2. Invoke your onVisaCheckoutReady function to set these values and invoke the Visa Checkout lightbox.

Note: Each payment.success event generates a new call ID.

Extracting Consumer Data

The encPaymentData property contains the consumer and payment information available to you from the consumer’s Visa Checkout Account. The same information is provided in the response to a Get Payment Data API call. Depending on your permissions and the information that the consumer has loaded into their Visa Checkout account, the information returned to you may include such things as user name, email address, mobile phone number, the selected payment instrument and its attributes, ship-to address, card art, and risk-related data.

Consumer information is returned in JSON format. You must not assume that the position of structures or fields within the payload are fixed or that all the fields will exist, since some may be present or absent based on the context of the payment request. The following consumer information is available as encrypted information in a successful payment event payload or in the response to a Get Payment Data API call. Note: If you need the full primary account number, you must establish the necessary permissions during the production on-boarding process and you must explicitly request that full information be included in the payload. By default, Visa Checkout only provides summary information

Consumer Information Properties Description
userData Information about the consumer.

Format: (See the User Data table for details)
paymentRequest The payment request information from the Visa Checkout library initialization. (See the Payment Request Properties table in the Submitting the Consumer Payment Request article for details.)
creationTimeStamp Payment creation timestamp.

Format: UNIX Epoch timestamp.
paymentInstrument The consumer’s account information. The contents will vary depending on whether full or summary data is returned.

Format: (See Payment Instrument Properties table for details.)
shippingAddress The consumer’s ship-to address information.

Format: See Address Properties table for details.
riskData Risk information.
threeDS Verified by Visa (3D Secure) information.
responseStatus Status of the response.
partialShippingAddress Partial shipping address.

 

User Data Properties Description
userFirstName Consumer’s given (first) name.

Format: May include spaces, single quotes (‘), back ticks (`), tildes (~), double quotes ("), periods (.), and hyphens (-), maximum 256 characters.
userLastName Consumer’s surname (last name).

Format: May include spaces, single quotes (‘), back ticks (`), tildes (~), double quotes ("), periods (.), and hyphens (-), maximum 256 characters.
userFullName Concatenation of the consumer’s first and last names.

Format: May include spaces, single quotes (‘), back ticks (`), tildes (~), double quotes ("), periods (.), and hyphens (-), maximum 256 characters.
userName The consumer’s Visa Checkout user name

Format: Alphanumeric valid email address, maximum 256 characters.
encUserId Encoded user ID.

Format: Alphanumeric, maximum 100 characters.
userEmail Valid email address for the consumer making the payment.

Format: Alphanumeric valid email address, maximum 256 characters.
userMobile Valid mobile phone number for the consumer making the payment.

Format: Numeric or hyphens, parentheses, period, or plus signs as are valid for the country, maximum 30 characters.
UserPersonalID Personal ID (Brazil only); it is the CPF (Cadastrado de Pessoas Físicas) tax registration number. It is only available if the merchant is configured by Visa Checkout to receive full information,

Format: Numeric; maximum 11 digits

 

Payment Instrument Properties Description
id A unique internal ID associated with the payment instrument

Format: Alphanumeric
lastFourDigits The last four digits of the payment instrument.

Format: Numeric, maximum 4 characters.
tokenInfo Token information; only available for token-enabled payment instruments.

Format: tokenInfo
cryptogramInfo Cryptogram information associated with the token; only available for tokenized payment instruments.

Format: cryptogramInfo
binSixDigits The first six digits of the payment instrument.

Format: Numeric, maximum 6 characters.
paymentType The kind of payment instrument.

Format: Complex structure consisting of two properties as follows:
cardBrand – one of the following VISA, MASTERCARD, AMEX, or DISCOVER.
cardType – one of the following CREDIT, DEBIT, CHARGE, PREPAID, DEFERRED_DEBIT, or NONE.
accountNumber The account number associated with the payment instrument. (Only available by permission)

Format: Numeric, maximum 19 characters.
billingAddress The billing address associated with the payment instrument

Format: See the Address Properties table for details.
verificationStatus The Visa Checkout verification status for the payment instrument.

Format: One of the following VERIFIED, NOT_VERIFIED, or CONSUMER_OVERRIDE.
expired Whether or not the card has expired.

Format: One of either true (expired) or false (not expired).
cardArts Card art information.

Format: (See Card Art Properties table for details.)
issuerBid The issuer BID of the payment instrument.

Format: Alphanumeric, maximum 100 characters.
nickName The consumer’s nickname for the payment instrument.

Format: Alphanumeric, maximum 140 characters.
nameOnCard The name of the consumer as embossed on the card.

Format: May include spaces, single quotes (‘), back ticks (`), tildes (~), double quotes ("), periods (.), and hyphens (-), maximum 256 characters.
cardFirstName The consumer’s first name as it appears on the card.

Format: Alphanumeric, maximum 256 characters.
cardLastName The consumer’s last name as it appears on the card.

Format: Alphanumeric, maximum 256 characters.
expirationDate The expiration date of the payment instrument.

Format: This is a complex object containing two properties:
month – in the format MM with leading zero if needed
year – in the format YYYY
riskData The risk information related to the transaction, if available.

Format: (See the Risk Data Properties table for details.)

 

Token Info Properties Description
token The token value associated with the payment instrument. It is only available to merchants with permission to request full information, e.g. onboarded with PAN access; not present in summary information.

Format: Numeric; maximum 16 digits
tokenRange First 9 digits of the token.

Format: Numeric; maximum 9 digits.
Last4 Last 4 digits of the token.

Format: Numeric; maximum 4 digits.
expirationDate Token's expiration date.

Format: expirationDate

Note: Token information is only available for token-enabled payment instruments. You must be configured by Visa Checkout to receive this information.

Cryptogram Info Properties Description
cryptogram Current cryptogram associated with the token, which is Base64 encoded.

Format: Alphanumeric
eci An e-commerce indicator (ECI); for example, a successful authentication of a Visa token returns 07 for eci.

Format: 07

Note: Cryptogram information is only available for token-enabled payment instruments. You must be configured by Visa Checkout to receive this information.

Payment Type Properties Description
CardBrand Brand of payment instrument.

Format: VISA, MASTERCARD, AMEX, DISCOVER, ELECTRON (BRAZIL only) or ELO (Brazil only)
cardType Kind of card.

Format: CREDIT, DEBIT, CHARGE, PREPAID, DEFERRED_DEBIT, NONE

 

Address Properties Description
id A unique internal ID associated with the an address

Format: Alphanumeric
verificationStatus Visa Checkout verification status of the address

Format: one of the following values VERIFIED, NOT_VERIFIED, or CONSUMER_OVERRIDE
personName The addressee’s complete name.

Format: Alphanumeric, maximum 256 characters.
firstName The addressee’s first name.

Format: Alphanumeric, maximum 256 characters.
lastName The addressee’s last name.

Format: Alphanumeric, maximum 256 characters.
line1 The first line of the address.

Format: Alphanumeric, maximum 140 characters
streetNumber Street number in the first line of the address, if it exists. Brazil only.
Format: Alphanumeric; maximum 140 characters.
streetName Street name in the first line of the address, if it exists. Brazil only.
Format: Alphanumeric; maximum 140 characters.
additionalLocation Additional location information in the first line of the address, if it exists.
Format: Alphanumeric; maximum 140 characters.
line2 The second line of the address.

Format: Alphanumeric, maximum 140 characters
line3 The third line of the address.

Format: Alphanumeric, maximum 140 characters
city The city of the address

Format: Alphanumeric, maximum 100 characters
stateProvinceCode The state or province code of the address

Format: Must be a valid 2-character code for US and Canada and a valid 3-character code for Australia
postalCode The postal code of the address (such as a ZIP code)

Format: Must be valid for the applicable country, such as US (5 digits), Canada (6 characters separated by a space or a hyphen), Australia (4 digits), New Zealand (4 digits). If other postal codes exist, they must be valid for their respective countries.
countryCode The country code of the address.

Format: Must be a valid ISO alphanumeric country code, maximum 2 characters.
phone The phone number associated with the address.

Format: Numeric or hyphens, parentheses, period, or plus sign, as is valid for the country, maximum 30 characters.
default Whether this is the default address.
Format: True or False

 

Card Art Properties Description
baseImageFileName The URL used to acquire the card art. The URL is provided for the sole purpose of displaying the card with the Visa Checkout button; it cannot be used for any other purpose.

Format: valid URL, maximum 100 characters
height The height of the art in pixels.

Format: Numeric, value between 1 and 4096.
width The width of the art in pixels

Format: Numeric, value between 1 and 4096.

Note: there may or may not be card art available for the particular payment instrument involved.

Expiration Date Description
month Expiration month of the payment instrument.
Format: The month in MM format, including leading 0 if necessary; from 01 to 12, inclusive.
year Expiration year of the payment instrument.
Format: The year in YYYY format.

 

Risk Data Properties Description
advice Not currently available. Risk advice for use with your fraud model. The returned value indicates a category of risk and is strictly advisory. Its value should only be used in conjunction with your own experience, models, and risk tolerance.

Format: one of the following values LOW, MEDIUM, HIGH, or UNAVAILABLE
score Not currently available. Risk score. The higher the score, the higher the potential risk. The returned value indicates a relative value of risk and is strictly advisory. Its value should only be used in conjunction with your own experience, models, and risk tolerance.

Format: Numeric, whole value between 0 and 99.
avsResponseCode The response code from the Address Verification service

Format: Alphanumeric (See the Request and Response Codes Reference for a list of valid values.)
cvvResponseCode The response code from the Card Verification Value 2 validation service.

Format: Alphanumeric (See the Request and Response Codes Reference for a list of valid values.)
ageOfAccount The number of days since the Visa Checkout consumer account was created. You can use it only for fraud evaluation, except as permitted by your Visa Checkout services agreement or with consumer consent.

Format: Numeric

Verified by Visa (3-D Secure) Authentication Data Fields

Fields are returned in a threeDS structure, which is only available when the merchant has been configured to use Verified by Visa. If any field is returned, all fields are returned; however, any field can be empty.

Important: You must provide some or all of these fields in the authentication message to your processor. Consult with your processor about the field values to include in the authentication message to use Verified by Visa.

Verified by Visa (3-D Secure) Authentication Data Fields Description
eciRaw A brand-specific e-commerce indicator (ECI); for example, a successful authentication of a Visa card returns 05 for eciRaw.
Format: 05, 06, 07
cavv Encoded Cardholder Authentication Verification Value or Authentication Verification Value (AVV); returned only for Verified by Visa transactions. This value will be encoded according to the merchant's configuration using either Base64 or Hex encoding. It should be included in the payment authentication request.
Format: Alphanumeric; maximum 48 characters
veresEnrolled Whether the card holder is enrolled in Verified by Visa and the card issuing bank is participating in Verified by Visa. Only a value of Y indicates authentication eligibility.
Format: It is one of the following values:
• Y - Enrolled
• N - Not enrolled
• B - Authentication bypassed
• U - Authentication unavailable
veresTimestamp VERes response timestamp in Coordinated Universal Time (UTC), also known as Zulu time.
Format: ISO 8601 standard in the form of yyyy-mm-ddThh:mm:ss:mmmZ.
paresStatus Whether the transaction was successfully authenticated.
Format: It is one of the following values:
• Y - Authenticated
• N - Not authenticated
• U - Authentication could not be completed
• A - Successful attempts transaction
paresTimestamp PARes response timestamp in Coordinated Universal Time (UTC), also known as Zulu time.
Format: ISO 8601 standard in the form of yyyy-mm-ddThh:mm:ss:mmmZ.
signatureVerification Whether the PARes has been validated successfully.
Format: It is one of the following values:
• Y - Indicates that the signature of the PARes has been validated successfully.
• N - Indicates that the PARes could not be validated.
xID Gateway or processor's authentication transaction ID, if available. This value will be encoded according to the merchant's configuration using either Base64 or Hex encoding. It should be included in the payment authorization request.
Format: Alphanumeric; maximum 40 characters

Updating Payment Information Using Pixel Image

Depending on your configuration, you will process the actual payment through your own system, a payment processor, or an e-commerce partner as you normally do. After you finish, you must update the payment information in Visa Checkout if your payment processor or e-commerce partner has not already done so. The simplest way to update Visa Checkout is to update it directly from your web page by including parameters when you load a one-pixel image provided by Visa Checkout on to your web page. Here is an example:

<a img=
"https://sandbox.secure.checkout.visa.com/wallet-services-web/payment/
updatepaymentinfo.gif?
apikey=…&callId=...&currencyCode=…&total=…&subtotal=…" />

You pass your public API key (apikey), the Call Id (callId) of the transaction you are confirming, and the applicable payment properties from the payment request (such as currency code, total, or subtotal), an eventType (Create, Confirm, Cancel, Fraud, Other), and an optional descriptive reason (alphanumeric, maximum 255 characters).

As a best practice, you should load the .gif when the consumer confirms the order on your Thank You or Order Confirmation page. A successful update shows the one-pixel image. An unsuccessful update contains the v-message header that you can use to determine the error. Typically, you would use debugging tools built into the browser to view this message.

Using the Visa Checkout APIs

Visa Checkout offers two APIs that you can use to get consumer payment information after a successful lightbox session and to update Visa Checkout with the status of the transaction after the payment has been processed. These APIs provide an alternative to using the Visa Checkout JavaScript library to perform those same functions from your web pages.

Get Payment Data

The Get Payment Data API gets the consumer payment information for the payment request associated with the callId returned by a payment success event. The API response includes the same information as if you had used the encrypted payload provided by Visa Checkout JavaScript library in the payment.success event. The API requires a valid and unexpired callId in the request. You may also optionally include a dataLevel parameter to specify that you want either full (including the PAN) or summary data to be returned.

The contents of the response will depend on whether full or summary information was requested and whether you are permitted to receive full information. If full information is permitted and requested, you will receive a response that includes encrypted payment information, which you must decrypt before using. The full information response is encrypted because it includes the consumer’s primary account number. If you receive only summary information, it will not be encrypted. (You can find complete specifications for the request and response messages on the Documentation tab.)

Update Payment Information

The Update Payment Information API provides Visa Checkout with the status of the transaction and the final amounts associated with the callId in the payment request. The final amount included in the actual processed payment may differ from the amount confirmed by the consumer in the Visa Checkout lightbox if, for example, discounts were applied or shipping amounts calculated after the lightbox closed. This API provides an alternative to using the Update Payment Information Pixel Image on your web pages. (You can find complete specifications for the request message on the Documentation tab.)

Clickjacking Prevention

To prevent clickjacking of your pages, each page must contain JavaScript to verify that there are no transparent layers, such as might be the case if your page was loaded as an iFrame of a page containing malicious code, and that only your site can load your pages.

Checking for Hidden Layers

Pages that prevent clickjacking contain JavaScript, such as the following, to verify that there are no transparent layers in which malicious code could reside:

<head>
. . .
<style  id =”antiClickjack”>body{display:none;} </style>
<script type =”text/javascript”> 
if (self === top) { 
var antiClickjack = document.getElementById (“antiClickjack”); 
antiClickjack.parentNode.removeChild (antiClickjack); 
} else { 
top.location = self.location; 
} 
</script>
. . .
</head>

Using the X-Options Header

Messages directed at your pages must include an X-FRAME-OPTIONS header to verify that the response is known to be from your web application:

prevents anything from framing your page.

prevents anything except your application from framing your page.

Working with a Processor or PSP

If you are using an acquirer processor or a payment service provider to process your payments, your integration with Visa Checkout will depend on the requirements of your processor. Generally, your processor will want you to provide either the decrypted values from the consumer information payload or will accept the entire encrypted or decrypted payload. You must update Visa Checkout with the transaction processing status provided by your processor unless your processor does it for you.

Adding Visa Checkout to a Mobile App

The Visa Checkout Mobile SDKs allow merchants to quickly build and implement a native in-application checkout for iOS and Android-enabled devices. Visa Checkout enabled within a mobile application allows consumers to complete purchases on the go in a fast, simple, and secure checkout on their iPhones or Android phones.

In addition to offering consumers Visa Checkout within a mobile application, the Mobile SDKs have features that take advantage of device functionality, including:

The Visa Checkout Mobile SDK files and related documentation can be downloaded using the links below. Commercial use of the Visa Checkout Mobile SDKs is currently limited to participating merchants in the U.S., Canada, and Australia. While each SDK provides the same kind of tools, the actual integration methodology depends on the platform. (See the respective SDKs for detailed information.)

Title Description Version Uploaded
Visa Checkout SDK for iOS Programmer's guide, libraries and sample application for Visa Checkout Mobile SDK for iOS 4.3.4 Novemeber, 2016
Visa Checkout SDK for Android Programmer's guide, libraries and sample application for Visa Checkout Mobile SDK for Android 4.3.1 November, 2016

User Interface Guidelines

Your implementation of Visa Checkout must meet the Visa Checkout branding requirements, which address the appearance and placement of the Visa Checkout button, the appearance and placement of the Visa Checkout Acceptance Mark, and the Tell Me More Link. You are required to implement the Visa Checkout branding requirements on all pages where you are displaying Visa Checkout digital assets: either the Visa Checkout Button or the Visa Checkout Acceptance Mark.

Use the Visa Checkout Acceptance Mark to let your consumers know that you accept Visa Checkout. Place it on pages such as your shopping cart page, login page, product page, and/or payment page. Place the Visa Checkout button on any page or in any flow on your web site or mobile application where a consumer is asked to type in their billing and payment information. Common examples include shopping cart pages, payment pages, card-on-file management pages, or immediately before a flow wherein a consumer is prompted for the type of personal information that could be obtained from a Visa Checkout account.

These rules apply to the Visa Checkout Button and Acceptance Mark:

Visa Checkout Buttons

There are three styles of Visa Checkout buttons that you can choose from. Ways to specify the style can be found in Customizing the Button. You should use the standard button unless the background colors on your site are dark. In that case, can consider using the neutral button to provide greater contrast.

Checkout Button Standard

Standard button without card art

Checkout Button Neutral

Neutral button without card art

Checkout Button Standard with Card Art

Standard button with card art.

You can use either a horizontal or stacked implementation of the Visa Checkout button, placing an "or" in between the payment options to emphasize that consumers are making a decision, such as in the following example.

Checkout Button Placement

If you offer guest checkout, a best practice is to prefill any account creation form you may have with the consumer information provided by Visa Checkout after the lightbox closes. If you require the consumer to sign in to your site, another best practice is to link the consumer’s Visa Checkout account to the consumer’s account on your site, so that the consumer does not have to login multiple times to check out. By linking accounts, you can recognize the consumer’s account on your site based on the consumer’s successful sign in to Visa Checkout.

Visa Checkout Acceptance Marks

ADD IMAGE 1

ADD IMAGE 1

General Visa Checkout Button Placement and Flow Requirements

You are required to implement the Visa Checkout branding requirements on all pages where the consumer is presented payment method options, such as Visa Checkout or another payment method. Common examples include shopping cart page, login page, product page, and payment page. Your actual implementation depends on your specific flow.

You can use Visa Checkout on any page or in any flow on your site or app where a consumer is asked to type in their billing and payment information. Common examples include cart pages (both full and mini) pages, payment pages, card-on-file management pages, or immediately before a flow where a consumer is prompted for personal information, which may be available, at least partially, within Visa Checkout.

Because Visa Checkout already has consumer shipping information and payment options, giving consumers the opportunity to specify choices at the beginning of the checkout process may enable them to complete the transaction with less effort that might otherwise be required. The following diagram show how placing Visa Checkout buttons on the shopping cart page and your log in page might work:

ADD IMAGE 1

Some consumers may not click the Visa Checkout button initially, in which case you should also offer Visa Checkout to consumers when they choose a payment method, which still enables them to use Visa Checkout for payment:

ADD IMAGE 1

The implementation shown above shows a radio button with a Visa acceptance mark. When the consumer chooses the Visa Checkout radio button, the Visa Checkout button appears, which enables the consumer to log into Visa Checkout to choose the card and continue to your payment page.

Visa Checkout Acceptance Mark Requirements

Use the Visa Checkout acceptance mark to let consumers know you accept Visa Checkout on your pages, such as on your payment pages and other pages that display a payment method. Visa Checkout provides 4 sizes of marks, which are identified in the table below. You can choose the size, color, and background based on the needs of your site; however, you must link to the mark.

Do not create your own acceptance marks; only use them by the associated URL, which is provided by Visa Checkout. The base URL is https://assets.secure.checkout.visa.com/VmeCardArts/partner/. It is followed by the .png graphic; for example, POS_horizontal_99x34_wht01.png. Thus, the complete URL is https://assets.secure.checkout.visa.com/VmeCardArts/partner/graphic.png.

Acceptance Mark Size File Names
99x34 pixels:
ADD IMAGE 1
49x31 pixels:
ADD IMAGE 1
40x30 pixels:
ADD IMAGE 1
28x21 pixels:
ADD IMAGE 1

After you choose the size, you generally, next choose from the following marks, based on the filename suffix:

In addition, there are 2 styles of acceptance mark that are available for you to use when Visa Checkout is not a checkout option:

The following rules are specific to the Visa Checkout acceptance mark:

Tell Me More Link

You should include the Tell Me More link along with a Visa Checkout button, such as in the example below.

Tell Me More Link

When the consumer clicks the link, a popup window that looks like this appears to explain the use and benefits of the Visa Checkout button. (Note: the Tell Me More link does not appear on mobile devices.)

Tell Me More Popup

Security and Authentication Requirements

The Visa Checkout APIs require an API Key and a Shared Secret for authentication (sometimes referred to as an “x-pay-token” header). Test credentials can be obtain online in the Application Console for sandbox testing. Production credentials will be supplied to you as part of the production on-boarding process. (See Getting Started With Visa Developers to get detailed instructions for obtaining and using an x-pay-token.)

Service Activation Requirements

You can get a test Client ID and test data from the Application Console for testing your integration with Visa Checkout in the sandbox. To use Visa Checkout in production, you must apply and be approved for a Visa Checkout Merchant Services account. (Contact developer@visa.com for more information or to begin the production on-boarding process.)

Best Practices and Tips for Using Visa Checkout

Visa Checkout uses a combination of proprietary and third-party technologies to implement fraud checks while processing transactions on your behalf. These checks are performed on all Visa Checkout accounts when the account is created or accessed; when a consumer logs in to their Visa Checkout account; and when a card is added to a Visa Checkout account, updated, or used in a transaction.

For every card added to a Visa Checkout account (regardless of card brand), Visa Checkout performs a validation before passing the card information to a merchant. This validation includes an Address Verification (AVS) check and a security code validation. A full or partial match is required for Address Verification and a match or unsupported response is required for the security code. The validation check response codes are provided to you in the Consumer Information payload.

Visa Checkout performs a validation of the Card Security Code (CVV2, CVN, CVC2, CID, or other such codes as defined by each card brand) for each card used in a Visa Checkout transaction or passed to a merchant for processing. As a result, you should never collect a Card Security Code from a consumer in your checkout flow separate and apart from Visa’s collection of same (unless you have Visa’s consent to do so). Because the Card Security Code has been validated for the Visa Checkout payment method being used, you should assume a historical “match” response. You must never store Card Security Codes.

You are encouraged to implement best practices for risk management for Visa Checkout transactions, just as you would for any other e-commerce transaction. Although Visa Checkout performs an array of proprietary fraud checks while interacting with consumers, it never declines a transaction except in extreme circumstances (such as when an account has been disabled by the issuer due to suspicious activity or a match on a government sanctions list). Visa Checkout fraud checks should never be used to replace or supplant your own fraud and risk management techniques. They should supplement your existing controls, models, processes, and procedures. You know your customers and their behavior best and are in the best position to assess your own risk tolerance for a given transaction.