Visa Payments Processing

*Requires approval from Visa. 

**Available to all registered developers in the sandbox.

***Non-Visa brands include all payment networks supported by the Visa Authorization Gateway Service.

The Visa Payments Processing 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. VPP 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 VPP 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.

VPP 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, VPP 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.

VPP 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 VPP APIs. Clients and their development partners will be required to complete testing and certification of the VPP APIs before activation in production.

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

You must sign up for the VPP 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 VPP APIs and required onboarding forms.

For further information, contact [email protected].

The VPP 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 VPP APIs (please note that CAVV validation checks are not supported for the Verifcation API).

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 VPP APIs, just as you would for any e-commerce transaction. The validation checks performed via VPP 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.