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]
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)
Online (card-not-present): eCommerce, Mail Order/Telephone Order (MOTO), installments, recurring payments, and card-not-present verification using CVV2
In App: processing payments with digital wallets and mobile payment services including ApplePay, GooglePay, and SamsungPay
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
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 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.
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.
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.
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].
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.
Start a Project
API Overview
API Reference