Billing Information 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 billing record for the given Customer Vault record.

Allowed:
string
required

Specifies a Customer Vault id.

string

Specifies a billing id.

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

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.

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