1 of 77

Sola

Introduction

No payment integration is too complex.

Sola Payments is a complete payment platform that you can tailor to your ambition. Delivered with step-by-step support to power you forward from day one.

How to Integrate with Sola Payments

iFields &

This integration allows developers to build fully custom payment pages while keeping card data secure. iFields generates single-use tokens (SUT) for each transaction, which is then submitted via the Transaction API for processing.

Key Benefits:

Full control over the user interface and payment experience.
Secure handling of card data, as sensitive information never touches your servers.
Flexible API integration that aligns with your system workflows.

Card-on-File & Recurring Payments

Store in Your System

Sola generates tokenized card representations (xToken) that can be safely stored in your database and used for card-on-file or recurring transactions. Ideal for: Platforms with existing customer records that trigger payments programmatically via API.

Create customers, payment methods, and recurring schedules directly within Sola. Sola returns identifiers for customers, payment methods, and schedules, which can be used for card on file transactions or to set up automated schedules that will run independently in the Sola gateway. Ideal for: Systems without a customer database or when you prefer Sola to run recurring billing logic.

Card Present Payments

CloudIM enables seamless integration with Sola devices via a cloud-based API, eliminating the need for physical connections, drivers, or local SDKs. Once the device is connected to the merchant’s network, you can process transactions using simple REST API calls.

Key Benefits:

No local SDKs, drivers, or complicated setup required.
Works over the cloud, allowing remote device management.
Simplifies card-present transaction handling while maintaining PCI compliance.

Sola

Sola’s PayFac API lets marketplaces and multi-merchant platforms onboard and manage sub-merchants under a single master account. Create sub-merchants programmatically, set account- or transaction-level fees, and automate revenue sharing.

Key Benefits:

API-driven sub-merchant creation and management.
Route fees to your master account per transaction or account.
Full visibility and reporting across all sub-merchants.

Credentials

Across all Sola's products we use a key (xKey) to identify on what account to process a specific transaction. Each Sola product doc will guide you where to set the xKey (for example: in the body of the request along with all other parameters, in the request header as “Authorization”, in the app settings etc.). You will have a unique xKey for and production accounts.

Best practices

Transaction response Transaction responses contain valuable information that you can utilize. The most important one is xResult; this will inform your system if the transaction was approved or declined. xAuthAmount will indicate how much was actually authorized by the bank, so it is a good idea to make sure that it matches the requested amount. By default, transactions will only approve for the full amount. If the full amount is not available, the transaction will be declined. Every transaction will receive a unique xRefnum that is used to identify this unique transaction. It is helpful during troubleshooting and is also used in case of a follow-up transaction (void refund, etc.). It is a good idea to display this xRefNum to the user and add it to receipts. You can find a full list of available response parameters .
Logs

Vendor Settings (optional)

A Vendor ID is a unique identifier associated with your vendor account. This feature is useful when you will be processing payments across multiple Sola accounts. It allows for specific settings to be configured on your vendor account, and these settings will be applied on transactions that include your Vendor ID in the transaction request. When using this feature, It is optimal to include your vendor ID across all transactions that you process on the Sola gateway.

Setup

Our support team can enable your vendor account and provide you with the ID.

Usage

To use Vendor settings, include the xVendorID = {yourvendorid} in the transactions request.

Features/Benefits

iFields key: Use a single iFields key across all your accounts.

Tokenization: Tokens can be used across accounts.

Licenses: Unlimited device licenses

Tokenization

Tokenization is the process of replacing sensitive payment data with a non-sensitive algorithm-generated string called a token (xToken). Each time you send a card or bank account number with a transaction, the response will include a token represented by xToken.

As a merchant’s significantly increases when storing sensitive data, the best practice is to store the token in your database rather than sensitive data. You use the token for follow-up transactions.

With this approach, sensitive data will not be at risk if a data breach occurs on your local system.

Sola references the payment information on our servers associated with the token sent and processes the transaction. A new token will be returned on every new transaction processed.

You can reuse the original token multiple times. However, you should use the new returned token in the following scenarios:

If the card has a new expiration date.
If a response flag indicates, the card was updated/modified.

A token only stores the data sent with a transaction that is necessary to process future transactions. It does not store general customer information such as billing and contact information.

As an example, for a credit card transaction, only the credit card number, expiration date, street address, and zip code (which can be required for Address Verification System (AVS) validation) are stored with the token.

Note: The 3 or 4 digit CVV number is never stored on Sola servers as per PCI regulations, and in extension, is not associated with tokens. CVV data is only used when processing initial transactions where the cardholder is generating the transaction with their physical card in hand.

Tokens can be used only on the account it was generated on unless linked to another account via cross tokenization

You can request account linking for tokenization via .

The best practice is to generate tokens on one account and link all other accounts to your first account instead of generating tokens for each.

To generate a token for a payment method without processing a transaction, use the save command.

For credit card transactions: cc:save.
For check transactions: check:save.

Duplicate Handling

The Sola Gateway automatically blocks a transaction considered a “duplicate” of another transaction based on certain identifying features and if the transactions are within 10 minutes (default timeframe) of each other. The transaction will error with a message of: Duplicate Transaction

Identifying Features:

Key
Credit Card Number
Transaction Amount
Invoice Number

You can allow the transaction to go through by changing any of the above. Alternatively, you can pass through "xAllowDuplicate = True" in the transaction request.

You can set xDuplicateWindow with the number of minutes on a transaction request to override the default 10-minute timeframe of the duplicate checker.

By default, you can set it up to 1440 (24 Hours) max. Your account can be set to allow up to 43200 (30 Days) via .

Batches

Each day, all captured transactions are added to a batch file. Once the batch cutoff time is reached (determined by the processing bank), Sola automatically “batches out”, which sends the related transactions to the bank for settlement. A batch report is available in the Sola portal.

Response Parameters

Transactions that are submitted to the Sola API will return a response with one or more of the fields below. Below are the standard parameters and their values. The field names in parentheses are the fields for the reporting API.

Sandbox Account Testing Info and Triggers

A sandbox account is used to simulate transactions as if it is in production. It is designed to act exactly like a production account. However, there can sometimes be unique account setups where the production account won't match the sandbox account exactly to a T. Therefore, we recommend that you do all your testing in the sandbox account and then doing one final test when going live and swapping out your sandbox key with your production key.

Test Credit Card and Account Numbers

Test credit card and account numbers are available for testing and development. You can use any valid card number to submit transactions while using a sandbox account. The card will not actually be charged as long as you are using your sandbox key. To avoid your system unintentionally going live while still configured with your sandbox credentials, transactions in the sandbox account are limited to $10. You can bypass that limit by using the below numbers.

Card Type

Card Number

Triggers

xAmount

Response

The Sola gateway does not require developers to go through a certification process. We do provide a process to self-certify if developers choose to do so. You can download the Sola.

API

Transaction API

Overview

The Sola API enables developers to process payments using the Sola gateway. Systems integrating with the Sola API can submit API calls using various commands. The API supports many payment methods, including credit cards, ACH, EBT, and gift cards.

To begin building your API integration, create an account for a Sola sandbox — our secure testing environment that mimics the production environment. After signing up, you’ll be able to create user credentials for the Sola Merchant Portal. Once you log in to the Portal, you’ll be able to generate an API key from the Settings menu. Watch our Key Management video or follow the instructions below to obtain a key.

How to Generate Sola Keys

Sign in to the Sola Merchant Portal.
Select "Account Settings" from the navigation bar.
Select "Keys" from the sub-menu.
Click "Create a Key" in the top-right corner.

It is critical to copy your key and save it in a secure location, as you won’t be able to obtain the key again.

iFields and Transaction API

We recommend using iFields in conjunction with the Transaction API for added security. Sola iFields is an iFrames solution that keeps sensitive card data away from merchant servers while granting you complete control over form layout and design. to learn more about iFields.

The Sola iFields solution utilizes iFrames in which the user enters their credit card and/or ACH information and then uses JavaScript to generate SUTs (single-use tokens) for processing. These features allow the website to remain secure and out-of-scope for PCI compliance while allowing the developer to customize the page layout and design fully.

This API has Cross-Origin Resource Sharing (CORS) restrictions in place to enhance security. Requests made directly from a web browser client (e.g., JavaScript running in the browser) will be blocked.

Allowed Origins This API only accepts requests from server-side origins. Ensure that your requests originate from a server to successfully interact with the API.

Endpoints

The endpoint section defines the details for accessing and interacting with the Sola transaction API.

Health Check

Method: Always use GET for health checks. Protocol: Secure communication is enforced using https:// Environment: Specifies the targeted environment for the check, such as x1, x2, or b1. The primary environment is x1, with x2 and b1 available as backups.

Domain: The base URL is always cardknox.com Paths: The endpoint path for health checks is /status

Transactions

Method: Always use POST for transaction requests. Protocol: Secure communication is enforced using https:// Environment: The primary environment is x1, with x2 and b1 available as backups. Domain: The base URL is always cardknox.com Paths/Formats: Various paths are supported based on data format requirements:

/gatewayform for form data
/gatewayjson for JSON data
/gatewayxml for XML data

x1 is the primary environment, with x2 and b1 as backups. The x2 and b1 environments have all resources necessary to operate independently of the other primary location.

Transaction Types

The endpoints can be found in the following child pages by navigating to the appropriate page:

Transactions

Transaction Type

Transaction (Link)

xCommand

Questions

Can't find what you're looking for? Please contact .

Donor-Advised Funds (DAF)

Sola’s payment gateway supports Donor-Advised Fund (DAF) cards, enabling secure and compliant charitable transactions through various DAF programs, including DonorsFund, OJC, Pledger, and others. Donors can use their DAF-linked cards to initiate charitable contributions, while organizations integrating with Sola can benefit from automated routing and handling based on card type. This streamlines the donation process while ensuring alignment with each DAF provider’s policies.

Recommendation

xCommand = grant:Recommendation

The Grant:Recommendation API call is used to initiate a grant request from a donor’s DAF account to a specific charitable organization. Once submitted, Sola automatically determines the appropriate DAF provider based on the card used and forwards the grant recommendation accordingly.

Void

xCommand = grant:Void

The Grant:Void API call is used to cancel a previously submitted grant recommendation. This function is essential for handling donor corrections, duplicate submissions, or other administrative scenarios. Upon invocation, the request is routed to the appropriate DAF program to halt the grant in accordance with that provider's cancellation policies.

3DS

Transactions

3DS Verify

Paths/Formats:

/verify for form data
/verifyjson for JSON data

The Verify path is used after a 3DS Step-Up Authentication. See how to implement 3ds on the client side.

Request Body

Response Example

Fraud

Overview

This page contains the API documentation for Fraud Submit transactions, in conjunction with FraudWatch. For more information regarding account access, navigate to the Transaction API parent page.

Transactions

Fraud Submit

POST fraud:submit

xCommand = fraud:submit

The Submit command is used in conjunction with a valid FraudWatch account to submit e-commerce transactions for a fraud verification check.

Request Body

Name

Type

Description

Account Boarding Swagger UI

For general information about using Swagger UI, refer to .

Swagger URL

SDK

Products

Mobile Wallets

Plugins

Articles

{
  "xResult": "A",
  "xStatus": "Approved",
  "xError": "",
  "xErrorCode": "00000",
  "xRefNum": "10583643601",
  "xRefNumCurrent": "10583264625",
  "xExp": "1234",
  "xAuthCode": "75294A",
  "xBatch": "5128394",
  "xAvsResultCode": "NNN",
  "xAvsResult": "Address: No Match & 5 Digit Zip: No Match",
  "xCvvResultCode": "M",
  "xCvvResult": "Match",
  "xAuthAmount": "7.00",
  "xMaskedCardNumber": "4xxxxxxxxxxx2503",
  "xCardType": "Visa",
  "xName": "John Doe",
  "xToken": "q712m7h271g035n799pn1605q16757m8",
  "xMID": "xxxxxxxxxx9999",
  "xTID": "xxxxx6789",
  "xCurrency": "USD",
  "xDate": "7/11/2025 9:59:11 AM",
  "xEntryMethod": "Keyed",
  "xEnrolled": "Y",
  "xCAVV": "AAIBBYNoEwAAACcKhAJkdQAAAAA=",
  "xEciFlag": "05",
  "x3DSID": "8ebb5b87-4d74-4b56-a0d0-075c6a37ab85",
  "xReviewed": "Y"
}

Transaction API

Overview

How to Generate Sola Keys

Sign in to the Sola Merchant Portal.
Select "Account Settings" from the navigation bar.
Select "Keys" from the sub-menu.
Click "Create a Key" in the top-right corner.

It is critical to copy your key and save it in a secure location, as you won’t be able to obtain the key again.

iFields and Transaction API

Allowed Origins This API only accepts requests from server-side origins. Ensure that your requests originate from a server to successfully interact with the API.

Endpoints

The endpoint section defines the details for accessing and interacting with the Sola transaction API.

Health Check

Domain: The base URL is always cardknox.com Paths: The endpoint path for health checks is /status

Transactions

/gatewayform for form data
/gatewayjson for JSON data
/gatewayxml for XML data

x1 is the primary environment, with x2 and b1 as backups. The x2 and b1 environments have all resources necessary to operate independently of the other primary location.

Transaction Types

The endpoints can be found in the following child pages by navigating to the appropriate page:

Transactions

Transaction Type

Transaction (Link)

xCommand

Questions

Can't find what you're looking for? Please contact .

Introduction

No payment integration is too complex.

Sola Payments is a complete payment platform that you can tailor to your ambition. Delivered with step-by-step support to power you forward from day one.

How to Integrate with Sola Payments

iFields &

Key Benefits:

Full control over the user interface and payment experience.
Secure handling of card data, as sensitive information never touches your servers.
Flexible API integration that aligns with your system workflows.

Card-on-File & Recurring Payments

Store in Your System

Card Present Payments

Key Benefits:

No local SDKs, drivers, or complicated setup required.
Works over the cloud, allowing remote device management.
Simplifies card-present transaction handling while maintaining PCI compliance.

Sola

Key Benefits:

API-driven sub-merchant creation and management.
Route fees to your master account per transaction or account.
Full visibility and reporting across all sub-merchants.

Credentials

Best practices

Transaction response Transaction responses contain valuable information that you can utilize. The most important one is xResult; this will inform your system if the transaction was approved or declined. xAuthAmount will indicate how much was actually authorized by the bank, so it is a good idea to make sure that it matches the requested amount. By default, transactions will only approve for the full amount. If the full amount is not available, the transaction will be declined. Every transaction will receive a unique xRefnum that is used to identify this unique transaction. It is helpful during troubleshooting and is also used in case of a follow-up transaction (void refund, etc.). It is a good idea to display this xRefNum to the user and add it to receipts. You can find a full list of available response parameters .
Logs

Vendor Settings (optional)

Setup

Our support team can enable your vendor account and provide you with the ID.

Usage

To use Vendor settings, include the xVendorID = {yourvendorid} in the transactions request.

Features/Benefits

iFields key: Use a single iFields key across all your accounts.

Tokenization: Tokens can be used across accounts.

Licenses: Unlimited device licenses

Tokenization

With this approach, sensitive data will not be at risk if a data breach occurs on your local system.

Sola references the payment information on our servers associated with the token sent and processes the transaction. A new token will be returned on every new transaction processed.

You can reuse the original token multiple times. However, you should use the new returned token in the following scenarios:

If the card has a new expiration date.
If a response flag indicates, the card was updated/modified.

A token only stores the data sent with a transaction that is necessary to process future transactions. It does not store general customer information such as billing and contact information.

Tokens can be used only on the account it was generated on unless linked to another account via cross tokenization

You can request account linking for tokenization via .

The best practice is to generate tokens on one account and link all other accounts to your first account instead of generating tokens for each.

To generate a token for a payment method without processing a transaction, use the save command.

For credit card transactions: cc:save.
For check transactions: check:save.

Duplicate Handling

Identifying Features:

Key
Credit Card Number
Transaction Amount
Invoice Number

You can allow the transaction to go through by changing any of the above. Alternatively, you can pass through "xAllowDuplicate = True" in the transaction request.

You can set xDuplicateWindow with the number of minutes on a transaction request to override the default 10-minute timeframe of the duplicate checker.

By default, you can set it up to 1440 (24 Hours) max. Your account can be set to allow up to 43200 (30 Days) via .

Batches

Response Parameters

Sandbox Account Testing Info and Triggers

Test Credit Card and Account Numbers

Card Type

Card Number

Triggers

xAmount

Response

The Sola gateway does not require developers to go through a certification process. We do provide a process to self-certify if developers choose to do so. You can download the Sola.

Fraud Submit - Request Payload Example

{ 
    "xCardNum": "4444333322221111", 
    "xKey": "[xkeycredentials]", 
    "xVersion": "4.5.9", 
    "xSoftwareName": "YourSoftwareName", 
    "xSoftwareVersion": "1.0.0", 
    "xCommand": "fraud:submit", 
    "xToken": "61h72mmh68phn9q233634ph3g54p1499m69qhp4816pn528h84", 
    "xCustom01": "Register01", 
    "xExp": "12/25", 
    "xCVV": "945", 
    "xStreet": "123 Any Street Apt 4b Anytown, NY", 
    "xZip": "12345", 
    "xMagstripe": "%B4444333322221111^TEST CARD/VISA^4912101123456789?;4444333322221111=4912101123456789?", 
    "xName": "John Doe", 
    "xAuthCode": "T4321A", 
    "xDUKPT": "%B4444333322221111^TEST CARD/VISA^4912101123456789?;444433", 
    "xTax": "2.00", 
    "xTip": "2.00", 
    "xRefNum": "81234568", 
    "xInvoice": "123456A", 
    "xPONum": "123456B", 
    "xComments": "This is a comment", 
    "xDescription": "This is a description", 
    "xIP": "1.2.3.4", 
    "xEmail": "[email protected]", 
    "xFax": "1234567890", 
    "xBillFirstName": "John", 
    "xBillMiddleName": "Max", 
    "xBillLastName": "Doe", 
    "xBillCompany": "Acme", 
    "xBillStreet": "123 Any Street", 
    "xBillStreet2": "Apt 4b", 
    "xBillCity": "Anytown", 
    "xBillState": "NY", 
    "xBillZip": "12345", 
    "xBillCountry": "USA", 
    "xBillPhone": "8005551212", 
    "xBillMobile": "8005551111", 
    "xShipFirstName": "John", 
    "xShipMiddleName": "Max", 
    "xShipLastName": "Doe", 
    "xShipCompany": "Acme", 
    "xShipStreet": "123 Any Street", 
    "xShipStreet2": "Apt 4b", 
    "xShipCity": "Anytown", 
    "xShipState": "NY", 
    "xShipZip": "12345", 
    "xShipCountry": "USA", 
    "xShipPhone": "8005551212", 
    "xShipMobile": "8005551111", 
    "xMICR": "t021000021t 123456789o _2542", 
    "xRouting": "021202337", 
    "xGatewayRefNum": "852585258", 
    "xGatewayResult": "Approved", 
    "xGatewayError": "845455484", 
    "xGatewayCVV": "M", 
    "xGatewayAVS": "YYY", 
    "xOrderType": "Internet", 
    "xOrderID": "12356", 
    "xExistingCustomer": "TRUE", 
    "xOrderItems": "Sony Digital Camera", 
    "xCustomerComments": "Please ship as soon as possible", 
    "xShipMethod": "UPS Ground", 
    "xShipAmount": "29.99", 
    "xShipEmail": "[email protected]", 
    "xAllowDuplicate": "TRUE" 
}

Check (ACH)

Overview

This page contains all API documentation for Check (ACH), and ACH-Q transactions. For more information regarding account access, navigate to the Transaction API parent page.

Transactions

Sola provides ACH and ACHQ processing for the transactions listed below (with exception of VoidRefund, which there is only ACHQ processing for). For more information regarding ACHQ, refer to the ACHQ or contact Sola support.

Note: The use of check/ACH transactions requires compliance with Nacha regulations, including the requirement to capture a physical or electronic signature from the customer. Please ensure your integration meets these compliance standards.

Sale

POST check:sale

A: There are a few ways to get the status. Via email, webhook, the Sola Portal, or by pulling a report using our reporting API.

Q: What verbiage comes back from the ACH Status?

A: You should get back the following status codes (xStatus) from Sola:

0 (Pending)
20 (Rejected)
5 (Cancelled)
6 (Awaiting Response)

The daily emails may contain more information.

Q: Can we get back a token when using the check MICR?

A: Sola only returns tokens on check transactions that contain the routing and account number. In the event only check images and MICR were submitted, the token is not returned since it can’t be reused on subsequent transactions.

 [
   {
      "relation":[
         "delegate_permission/common.handle_all_urls"
      ],
      "target":{
         "namespace":"android_app",
         "package_name":"com.gateway.cardknox.android",
         "sha256_cert_fingerprints":[
            "6A:2D:20:86:D4:4C:46:33:44:6A:41:35:4D:A4:91:20:82:1A:38:8E:63:05:C5:4F:CC:EC:94:36:3F:F9:35:E3"            
         ]
      }
   }
]

initAP: function() {
  return {
    buttonOptions: this.buttonOptions,
    merchantIdentifier: "<your merchant>",
    ..................................
    requiredFeatures: [APRequiredFeatures.address_validation, APRequiredFeatures.support_recurring],
    ..................................
    requiredBillingContactFields: ['postalAddress', 'name', 'phone', 'email'],
    requiredShippingContactFields: ['postalAddress', 'name', 'phone', 'email'],
  };
}

{
    "applinks": {
        "apps": [],
        "details": [
            {
                "appID": "QCP4TQ46S6.com.gateway.cardknox.iosapp",
                "paths": [ "/transaction/*"]
            }
        ]
    }
}

Sale - Request Payload Example

{
    "xKey": "[xkeycredentials]",
    "xVersion": "4.5.9",
    "xSoftwareName": "YourSoftwareName",
    "xSoftwareVersion": "1.0.0",
    "xCommand": "check:sale",
    "xAmount": "35.00",
    "xToken": "61h72mmh68phn9q233634ph3g54p1499m69qhp4816pn528h84",
    "xCustom01": "Register01",
    "xRouting": "123456789",
    "xAccount": "123456789",
    "xAccountType": "Checking",
    "xName": "John Doe",
    "xTax": "2.00",
    "xTip": "2.00",
    "xInvoice": "123456A",
    "xPONum": "123456B",
    "xComments": "This is a comment",
    "xDescription": "This is a description",
    "xIP": "1.2.3.4",
    "xEmail": "[email protected]",
    "xFax": "1234567890",
    "xBillFirstName": "John",
    "xBillMiddleName": "Max",
    "xBillLastName": "Doe",
    "xBillCompany": "Acme", 
    "xBillStreet": "123 Any Street", 
    "xBillStreet2": "Apt 4b", 
    "xBillCity": "Anytown", 
    "xBillState": "NY", 
    "xBillZip": "12345", 
    "xBillCountry": "USA", 
    "xBillPhone": "8005551212", 
    "xBillMobile": "8005551111", 
    "xShipFirstName": "John", 
    "xShipMiddleName": "Max", 
    "xShipLastName": "Doe", 
    "xShipCompany": "Acme", 
    "xShipStreet": "123 Any Street", 
    "xShipStreet2": "Apt 4b", 
    "xShipCity": "Anytown", 
    "xShipState": "NY", 
    "xShipZip": "11111", 
    "xShipCountry": "USA", 
    "xShipPhone": "8005551212", 
    "xShipMobile": "8005551111", 
    "xMICR": "t021000021t 123456789o _2542",
    "xCheckNum": "999",
    "xCheckImageFront": "data:image/jpeg;base64,/9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAYEBAQFBAYFBQYJBgUGCQsIBgYICwwKCgsKCgwQDAwMDAwMEAwODxAPDgwTExQUExMcGxsbHCAgICAgICAgICD/2wBDAQcHBw0MDRgQEBgaFREVGiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICD/w",
    "xCheckImageRear": "data:image/jpeg;base64,/9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAYEBAQFBAYFBQYJBgUGCQsIBgYICwwKCgsKCgwQDAwMDAwMEAwODxAPDgwTExQUExMcGxsbHCAgICAgICAgICD/2wBDAQcHBw0MDRgQEBgaFREVGiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICD/w",
    "xOrderID": "12356",
    "xExistingCustomer": "TRUE",
    "xAllowDuplicate": "TRUE", 
    "xCustReceipt": "TRUE",
    "xCurrency": "USD",
    "xTimeoutSeconds": "10",
    "xPaymentOrigin": "Internet"
}

Save - Request Payload Example

{
    "xKey": "[xkeycredentials]",
    "xVersion": "4.5.9",
    "xSoftwareName": "YourSoftwareName",
    "xSoftwareVersion": "1.0.0",
    "xCommand": "check.save",
    "xCustom01": "Register01",
    "xRouting": "123456789",
    "xAccount": "123456789",
    "xName": "John Doe",
    "xIP": "1.2.3.4",
    "xMICR": "t021000021t 123456789o _2542",
    "xAllowDuplicate": "TRUE"
}

Adjust - Request Payload

{
    "xKey": "[xkeycredentials]",
    "xVersion": "4.5.9",
    "xSoftwareName": "YourSoftwareName",
    "xSoftwareVersion": "1.0.0",
    "xCommand": "cc:adjust",
    "xAmount": "35.00",
    "xCustom01": "Register01",
    "xCustom02": "Register01",
    "xCustom03": "Register01",
    "xStreet": "123 Main Street",
    "xZip": "12345",
    "xRefNum": "81234568",
    "xName": "John Doe",
    "xDescription": "This is a description",
    "OrderID": "123456",
    "xTip": "1.05",
    "xTax": "1.05",
    "xSignature": "aGVsbG8gaG93IGFyZSB5b3UK",
    "xInvoice": "123456A"
}

200 - Response

{
"xResult": "A",
"xStatus": "Approved",
"xError": "",
"xErrorCode": "00000",
"xRefNum": "10000016879",
"xInvoice": "1234567",
"xRefNumCurrent": "10000016886",
"xDate": "7/11/2022 4:06:11 PM"
}

Void - Request Payload Example

{
    "xKey": "[xkeycredentials]",
    "xVersion": "4.5.9",
    "xSoftwareName": "YourSoftwareName",
    "xSoftwareVersion": "1.0.0",
    "xCommand": "check.void",
    "xCustom01": "Register01",
    "xRefNum": "81726356",
    "xIP": "1.1.1.1"
}

Refund - Request Payload Example

{
    "xKey": "[xkeycredentials]",
    "xVersion": "4.5.9",
    "xSoftwareName": "YourSoftwareName",
    "xSoftwareVersion": "1.0.0",
    "xCommand": "check.refund",
    "xAmount": "9.99",
    "xCustom01": "Register01",
    "xRefNum": "81726356",
    "xIP": "1.1.1.1",
    "xAllowDuplicate": "TRUE",
    "xCustReceipt": "FALSE",
    "xTimeoutSeconds": "10"
}

Click-To-Pay Sample Code

Let's define a helper object with all necessary components:

Let’s enable Click-To-Pay for the website:

document.addEventListener("DOMContentLoaded", function(event) { 
    .....
    ckClick2Pay.enableClickToPay({
      environment: c2pEnvironment.sandbox, 
      externalClientId: "<Your externalClientId>",
      click2payContainer: "click2payContainer", 
      onPaymentPrefill: click2payRequest.paymentPrefill,
      onPaymentSuccess: click2payRequest.paymentSuccess,
      onPaymentError: click2payRequest.paymentCallback,
      onPaymentCancel: click2payRequest.paymentCallback,
      onButtonLoaded: click2payRequest.cpButtonLoaded
  });
.....
}

To see the full solution please click here.

const click2payRequest = {
    paymentPrefill: function(){
        const result = {
            merchantRequestId: "Merchant defined request ID",
            currencyCode: "USD",
            description: "...corp Product",
            orderId: "Merchant defined order ID",
            promoCode: "Merchant defined promo code",
            subtotal: roundTo(getAmount(), 2),
            shippingHandling: "2.00",
            tax: "2.00",
            discount: "1.00",
            giftWrap: "2.00",
            misc: "1.00",
            setTotal:  function() {
                this.total = roundTo(
                    roundToNumber(this.subtotal, 2)
                    + roundToNumber(this.shippingHandling, 2)
                    + roundToNumber(this.tax, 2)
                    + roundToNumber(this.giftWrap, 2)
                    + roundToNumber(this.misc, 2)
                    - roundToNumber(this.discount, 2)
                , 2);
                delete this.setTotal;
                return this;
            },
        }.setTotal();
        logDebug({
            label: "paymentPrefill",
            data: result
        });
        return result;
    },
    authorize: function(payload) {
        return new Promise(function (resolve, reject) {
            var xhr = new XMLHttpRequest();
            xhr.open("POST", "https://<your domain>/<path to handle authorization>");
            xhr.onload = function () {
                if (this.status >= 200 && this.status < 300) {
                    resolve(xhr.response);
                } else {
                    reject({
                        status: this.status,
                        statusText: xhr.statusText
                    });
                }
            };
            xhr.onerror = function () {
                reject({
                    status: this.status,
                    statusText: xhr.statusText
                });
            };
            xhr.setRequestHeader("Content-Type", "application/json");
            xhr.send(JSON.stringify(payload));
        });
    },
    paymentSuccess: async function(clickToPayResponse) {
        return new Promise((resolve, reject) => {
            try {
                const response = await this.authorize(clickToPayResponse);
                console.log(response);
                const resp = JSON.parse(response);
                if (!resp)
                    throw "Invalid response: "+ response;
                if (resp.xError) {
                    throw resp;
                }
                resolve(response);
            } catch (err) {
                console.error("paymentSuccess error.", JSON.stringify(err));
                reject(err);
            }
        });
    },a
    paymentCallback: function (clickToPayResponse) {
        click2payRequest.setPayload(clickToPayResponse);
    },
    cpButtonLoaded: function(resp) {
        if (!resp) return;
        if (resp.status === iStatus.success) {
            showHide("click2payContainer", true);
        } else if (resp.reason) {
            console.log(resp.reason);
        }
    },
    setPayload: function (value) {
        document.getElementById('c2p-payload').value = JSON.stringify(value, null, 2);
        showHide("divC2PPayload", value);
    }
}

Transaction Workflow

Language C#