Skip to main content
The Pay API v2 is built to be modular with regards to payment processors (Worldpay, Elavon, Nuvei, Adyen, North to list a few). From an external view, merchants see one cardSale endpoint, one cardRefund endpoint, one transQuery endpoint, and so on. The merchant does not need to know about the different processors working behind the scenes in order to use our Pay API. The request body structure, as well as the structure of the response from these external endpoints does not change between different processors used. From an internal view, each of these endpoints (cardSale, cardRefund, transQuery, etc.) are connected to overarching functions that dynamically choose which payment processor to use based on the merchant’s available processors, as well as other factors. These overarching functions are meant to remain clean and simple, calling upon processor-specific functions to handle the transaction processing. The complexities arise within each processor-specific function (ex: worldpayCardSale, elavonRefund, adyenCardSubscription) as each processor API may have totally different integration requirements, data types, data structures, security measures, account management, etc. Ideally, these complexities are contained within each processor function. The overarching cardSale, cardRefund, transQuery functions are again meant to remain clean and simple. The focus of this New Processor Integration Guide is on how we can build and fit different transaction functions from different payment processors in to our current Pay API. While each payment processor and each transaction function for each payment processor will be different, it is necessary that each function accepts the same data fields in the same structure, as well as returns the same data fields in the same structure. These standards will be outlined within this guide.