Paya Connect Recommended Path of Integration
Overview
This page will walk through the Paya recommended path for integration. This path will provide the easiest deployment of the Paya Connect APIs and should reduce the scope for PCI-DSS for most integrators that follow this method.
Require Credentials
Intended For | Field Name | Purpose |
---|---|---|
Developer |
developer_id |
Used to identify the developer/solution making the request. |
Location/Merchant |
location_id |
Container for the merchant account(s). |
Location/Merchant |
product_transaction_id |
Container for the deposit account. A single location_id may contain many product_transaction_ids. |
Integration User |
user_id |
Used to identify the user making the Direct API (RESTful) request or initiating a PayForm & AccountForm. |
Integration User |
user_api_key |
Used like a password with Direct API (RESTful) requests. This should be protected and not shared with anyone. |
Integration User |
user_hash_key |
Used when implementing PayForm & AccountForm to build the hash_key. This should be protected and not shared with anyone. |
Obtaining Location Details
A solution may require the merchant to obtain their account details and credentials directly from Paya and enter them into the solution manually. However, an integrator may want to automate some of this process. Using a simple GET request, the integrated solution may only require the user_id, user_api_key, and user_hash_key. The first two will allow them to submit a GET request against our Location Info Endpoint which will return details such as the location_id and the various product_transaction_ids associated with their account.
View Record List
GET /v2/locationinfos
Note: Empty Request Body.
Direct API - Contact
Our Contacts Endpoint allows an integrator to build a container for customer information, vaulted data, and transaction history. A contact may be an individual, family, business, or any other entity you may give a name to. Once you build a contact record you can add that contact_id to any additional API requests such as Create Record (Account Vault), Perform a Sale (Transactions), Create Quick Invoice, and more.
Create Contact
POST /v2/contacts
Reduce PCI-DSS Scope with PayForm/AccountForm and Vaulted transactions
Paya Connect offers hosted forms to reduce PCI-DSS scope. Use these forms to collect PCI-sensitive data for one-time payments, recurring, or even store the data for future payments. We return values like the transaction_id and account_vault_id that will let you store a token in place of PCI-sensitive data for future transactions.
PayForm
The PayForm widget can be used for running sale, authonly, avsonly, or debit (ach). For more information about the PayForm, please see the following resources.
Notes on additional action that can be used inside Payform Use “action”: “avsonly” and “save_account”: 1 with PayForm to validate and store accountholder data.
AccountForm
The AccountForm widget is used strictly to generate an account vault token. For more information about AccountForm, please see the following resources.
Direct API - CC
Once you have obtained an account_vault_id or account_vault_api_id you can use our RESTful Direct API Endpoints to process additional requests without falling into scope for PCI-DSS.
Sale Request
POST /v2/transactions
Auth Only Request
POST /v2/transactions
Important Note: All authonly requests need to be either captured (action = authcomplete) or voided (action = void). Please do not allow authonly requests to remain on the gateway incomplete.
Capture or Completion Request
This request uses the transaction_id returned from the authonly request.
POST /v2/transactions
Void Request
This is similar in design to the capture request above. This allows you to reverse an authorization hold on the funds rather than waiting the time it takes for the funds to be released by the issuing bank. A void must be performed prior to batch settlement which usually takes place at the end of the day but will vary from merchant to merchant.
POST /v2/transactions
Refund from a previous transaction
This request uses the transaction_id from a previous transaction. It is passed within the previous_transaction_id field. A refund should be utilized after a transaction is settled. This is usually the next day after settlement occurs or later.
POST /v2/transactions
Direct API - ACH
Once you have obtained an account_vault_id or account_vault_api_id you can use our RESTful Direct API Endpoints to process additional requests.
WEB Debit Request from an Account Vault
This is the main request for processing customer-initiated payments using a web interface.
POST /v2/transactions
WEB Refund using Previous Transaction data
This use a transaction_id from a previous WEB debit refund to perform a full refund (action = refund). Note that any partial refund cannot be run on a WEB ach_sec_code; for partial refunds, please review the next section on Credit Request (Refund) using Previous Transaction data.
POST /v2/transactions
Credit Request (Refund) using Previous Transaction data
This uses a transaction_id from a previous debit request to perform the refund (action = credit). Note that an ACH Credit will need to be performed against the ach_sec_code “CCD” using a product_transaction_id from a CCD service within Paya Connect.
POST /v2/transactions
Summary
While the examples provided are available to get you started with your integration. Please keep in mind that this is a basic method of integration to be used as a guide. Should you have any questions relating to your integration, please reach out to the SDK Team at sdksupport@nuvei.com.