How to Use VisaNet Connect - Acceptance

The following is a list of services and use cases supported by the VisaNet Connect - Acceptance APIs. Visit our Use Case page for more details. If you need additional information, contact the product office at [email protected]

Supported Use Cases

mobile dollar sign icon

In store (card-present): a broad range of point-of-sale payment methods including magnetic stripe ("swipe"), EMV1 ("dip"), and NFC2 ("tap") - both with or without PIN (Personal Identification Number)

mobile dollar sign icon

Online (card-not-present): eCommerce, Mail Order/Telephone Order (MOTO), installments, recurring payments, and card-not-present verification using CVV2

mobile dollar sign icon

In App: processing payments with digital wallets and mobile payment services including ApplePay, GooglePay, and SamsungPay 

Key Features and Merchant Segments

Tokenized payments: a cardholder's primary account number is replaced with a unique digital identifier that reduces risk of fraud while maintaining the same seamless consumer experience

EU PSD2: support for PSD2 requirements including Strong Customer Authentication, Delegated Authentication Service, and SCA exemptions 

Card and cardholder authentication: support for card and cardholder verification methods including Card Verification Value (CVV), Card Verification Value 2 (CVV2), Cardholder Authentication Verification Value (CAVV), and Address Verification Service (AVS)

Authorization Gateway Services: support for authorization of non-Visa branded payments

Automated Fuel Dispenser/Electric Vehicle Charging: support for additional data required to process AFD/EVC payments, both consumer and Fleet (Level 2)

Visa Installment Service: installment payment plans that allow consumers to divide a purchase over time into smaller equal payments

Merchant profile and attributes: manage merchant profiles with Merchant Verification Value, Payment Facilitator IDs, and other merchant-specific data

Additional Visa Value-Add Services: including Real Time Visa Account Updater, Visa Transaction Advisor - eCommerce, Account Name Inquiry, and HSM-as-a-Service

1 EMV (Europay, Mastercard, and Visa) - a technical standard for smart payment cards and payment terminals

2 NFC - near-field communication 

Using RESTful API Concepts

The VisaNet Connect - Acceptance APIs use the following RESTful API concepts:

Resources. Each payment function is accessed with a “resource”, such as authorizations, verifications, sales, captures, refunds and voids. 

HTTP Verbs and Status. HTTP POST verb is used to submit requests. The HTTP status code 200 is returned for a successful API call. Other HTTP status codes, such as 400 and 500, are returned for unsuccessful calls. See the Error Code and Exception Handling section for more details.

Hypermedia links for follow-on actions. The VisaNet Connect - Acceptance APIs use JSON Hypertext Application Language (HAL) to identify the follow-on actions that can be performed on a resource. For example, a payment capture can be performed on a successful payment authorization.

Hypermedia Links (HATEOAS)

Hypermedia as The Engine of Application State or HATEOAS is a constraint of the REST application architecture.

The APIs use JSON Hypertext Application Language (HAL) to inform the follow-on actions that can be performed on a resource. For example, a capture can be performed on a successful authorization. Hypermedia links are returned for the Authorizations, Captures, Sales and Refunds resources. The HTTP Accept header should support the value of “application/hal+json” for these resources. POST is the only action currently supported for the hypermedia links.

Using correlatnId in API Messages

Using correlatnId in Authorization, Capture, Sale, Refund, Verification API messages

correlatnId is a unique ID that you as a client create for each API request call. This is a different parameter than the requestId that is created by Visa.

VisaNet Connect APIs support idempotency for safely retrying requests without accidentally performing the same operation twice. For example, if an authorization request fails due to a network connection error, you can retry the request with the same idempotency key to guarantee that only a single authorization request is processed. 

To perform an idempotent request, submit a POST request using a unique value in the correlatnId field. If the transaction is submitted with the same correlatnId value and request fields, the APIs will set the duplicateResp field to true and return the results of the original transaction.

The correlatnId field for Authorization should be unique for a period of 180 days. The correlantnId for the rest of the resources should be unique for a period of 48 hours.

Using correlatnId in Voids without resource id

VisaNet Connect - Acceptance APIs support submitting a Void request prior to receiving the resource id of primary request (Authorization, Capture, Sale and Refund) in case of time-outs. When submitting such Voids, the correlatnId field should contain the value used in the primary request. Otherwise, the void will be rejected.

Service Activation Requirements

Sandbox testing and certification are required for using the VisaNet Connect - Acceptance. Clients and their development partners will be required to complete testing and certification before activation in production.

You can get a test Client ID and test data from the Project Console for testing your integration in sandbox. For certification, you must use client credentials and test data provided by your acquirer. To use the APIs in production, you must be approved by your acquirer and Visa.

You must sign up for the  APIs by signing a Visa Developer Program API Agreement. After signing an agreement, Visa will assign an Implementation Manager who will be your main point of contact at Visa during implementation. The Implementation Manager will provide you with a project plan for implementing the APIs and required onboarding forms.

For further information, contact [email protected].

Best Practices and Tips

The VisaNet Connect APIs support a combination of cardholder and card account validation checks while processing payment transactions. These checks such as Account Verification (AV), Address Verification (AVS), Card Verification Value 2 (CVV2), and Cardholder Authentication Verification Value (CAVV) can be performed with all APIs.

Note: You should never store cardholder and card account security information collected from consumers.

You are encouraged to implement risk management best practices for payment transactions processed via the APIs, just as you would for any e-commerce transaction. The validation checks performed via the APIs are not intended to replace or supplant your own fraud and risk management techniques. They should only supplement your existing controls, models, processes and procedures.