Customer Management

Never Use Real API Keys

Never use real API Keys when testing. The gateway allows Partners to create Test Merchant Accounts. Testing should always use keys from the Test Accounts and never keys from a Standard Account.

Methodology

Steps:

  1. The customer sends their payment information to the merchant's web site.
  2. The merchant web site posts the payment data to the Payment Gateway.
  3. The Payment Gateway responds immediately with the results of the transactions.
  4. The merchant web site displays the appropriate message to the customer.

The communication method used to send messages to the Payment Gateway's server is the standard HTTP protocol over an SSL connection.

In the Payment API method, the communications with the cardholder (Steps 1 and 4) are developed completely by the merchant and therefore are not defined by the Payment Gateway. Step 1 should simply collect the payment data from the cardholder and Step 4 should display the appropriate transaction receipt or declined message.

In Step 2, transaction details should be delivered to the Payment Gateway using the POST method with the appropriate variables defined below posted along with the request.

In Step 3, the transaction responses are returned in the body of the HTTP response in a query string name/value format delimited by ampersands. For example: variable1=value1&variable2=value2&variable3=value3

Customer Vault

The Customer Vault was designed specifically for businesses of any size to address concerns about handling customer payment information. Visa and MasterCard have instituted the Payment Card Industry (PCI) Data Security to protect cardholder data, wherever it resides, ensuring that members, merchants, and service providers maintain the highest information security standards.

These associations have also deemed that merchants will be held liable for any breach of cardholder data. This has become a major concern for merchants who handle credit card or electronic check payments. The Customer Vault is designed for these merchants who desire to avoid the tremendous costs and resources involved in becoming PCI compliant under these circumstances.

The Customer Vault does this by allowing merchants to transmit their payment information through a Secure Sockets Layer (SSL) connection for storage in our Level 1 PCI certified data facility. Once the customer record has been securely transmitted to the Customer Vault, the merchant can then initiate transactions remotely without having to access cardholder information directly. This process is accomplished without the merchant storing the customer's payment information in their local database or payment application.

Response Code Table
CodeDescription
100Transaction was approved.
200Transaction was declined by processor.
201Do not honor.
202Insufficient funds.
203Over limit.
204Transaction not allowed.
220Incorrect payment information.
221No such card issuer.
222No card number on file with issuer.
223Expired card.
224Invalid expiration date.
225Invalid card security code.
226Invalid PIN.
240Call issuer for further information.
250Pick up card.
251Lost card.
252Stolen card.
253Fraudulent card.
260Declined with further instructions available. (See response text)
261Declined-Stop all recurring payments.
262Declined-Stop this recurring program.
263Declined-Update cardholder data available.
264Declined-Retry in a few days.
300Transaction was rejected by gateway.
400Transaction error returned by processor.
410Invalid merchant configuration.
411Merchant account is inactive.
420Communication error.
421Communication error with issuer.
430Duplicate transaction at processor.
440Processor format error.
441Invalid transaction information.
460Processor feature not available.
461Unsupported card type.
Recent Requests
Log in to see full request history
TimeStatusUser Agent
Retrieving recent requests…
LoadingLoading…
Form Data
string
required

API Security Key assigned to a merchant account. New keys can be generated from the merchant control panel in Settings > Security Keys

string
enum
required

Create a secure Customer Vault record.

Allowed:
string

Specifies a Customer Vault id. If not set, the payment gateway will randomly generate a Customer Vault id.

string

Billing id to be assigned or updated. If none is provided, one will be created or the billing id with priority '1' will be updated.

string

The tokenized version of the customer's card or check information. This will be generated by Collect.js and is usable only once.

string

The encrypted token created when integration directly to the Google Pay SDK.

string

Set transaction currency.

string
enum

Set payment type to ACH or credit card.

Allowed:
string

Shipping entry id. If none is provided, one will be created or the billing id with priority '1' will be updated.

string

Specifies a payment gateway transaction id in order to associate payment information with a Customer Vault record.

string
enum

If set to true, credit card will be evaluated and sent based upon Automatic Card Updater settings. If set to false, credit card will not be submitted for updates when Automatic Card Updater runs. Default: 'true'

Allowed:
string
enum
required

Credit card number.

Allowed Card Numbers:
Card TypeTest Card Number
Visa4111111111111111
MasterCard5431111111111111
Discover6011000991300009
American Express341111111111111
Diner's Club30205252489926
JCB3541963594572595
Maestro6799990100000000019
Allowed:
string

Credit card expiration date.

Format: MMYY

string

The name on the customer's ACH account.

string
length between 9 and 9

The customer's bank routing number.

string

The customer's bank account number.

string
enum

The type of ACH account the customer has.

Allowed:
string
enum

The type of ACH account the customer has.

Allowed:
string
enum

The Standard Entry Class code of the ACH transaction.

Allowed:
string

Order id

string

Order Description.

string

Cardholder's first name.

string

Cardholder's last name.

string

Card billing address.

string

Card billing city

string

Card billing state.

Format: CC

string

Card billing postal code.

string

Card billing country code. Country codes are as shown in ISO 3166-1 alpha-2.

Format: CC

string

Billing phone number.

string

Billing email address.

string

Cardholder's company.

string

Card billing address, line 2.

string

Billing fax number.

string

Shipping first name

string

Shipping last name

string

Shipping company

string

Shipping address

string

Shipping address, line 2

string

Shipping city

string

Shipping state.

Format: CC

string

Shipping zip code

string

Shipping country. Country codes are as shown in ISO 3166-1 alpha-2.

Format: CC

string

Shipping email address

string

Shipping phone number.

string

Shipping fax number.

string

Merchant defined field. You can pass custom information in up to 20 fields.

Format: merchant_defined_field_1=Value1, merchant_defined_field_2=Value2, etc...

Response

Language
LoadingLoading…
Response
Click Try It! to start a request and see the response here! Or choose an example:
application/x-www-form-urlencoded