How to Use Visa Payments Processing

Processing an Online Payment Transaction

The VPP APIs offer a direct access to the Visa payment processing systems, such as authorization and clearing. The VPP APIs enable Visa clients, such as acquirers, acquirer processors, approved merchants and payment facilitators to process payment transactions directly with VisaNet.

Online payment transaction diagram

Note: Cients responsible for Internet access.

The following table outlines examples of processing scenarios and features that can be used in new payment projects.

Card Not Present API
Brands Verification* Auth** Sale* Refund* Void* Capture*
Visa X X X X X X
Non-Visa *** X          
Processing Scenarios
Ecommerce - Single Shipment   X   X X  
Ecommerce - Digital Goods     X X X  
Ecommerce - Recurring Transactions     X X X  
Ecommerce - In-App     X X X  
Ecommerce - Acquirers / Processors X X X X X X

*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.

Using RESTful API Concepts

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 Links (HATEOAS)

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.

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.

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.

Using correlatnId in Voids without resource id

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.

Service Activation Requirements

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].

Best Practices and Tips

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.