HTTP API

Overview

Purpose

The Gateway Submission API defines the type of information that may be sent to the gateway. When transmitting data to the gateway, information should be posted to

https://secure.gotobilling.com/os/system/gateway/transact.php

GOTOBILLING recognizes and processes both GET and POST methods. The interface between the ISP and GOTOBILLING is the standard HTTP/1.0 (or HTTP/1.1) protocol using Secure Sockets Layer (SSL) encryption.

Transactions are broken up into delimited fields. A transaction is transmitted either in the request header for the GET method or following the request headers for the POST method.

Changelog

x_versionDescriptionDate
~Added PN transaction-type for indicating ACH Pre-Note requests.2021-07-14
1.3x_customer_id now allows for alpha-numeric characters, as well as, the special characters period ., underscore _, and dash -2021-06-15

Notes about the Merchant IDs and PINs

  • Merchant IDs (also called Merchant-IDs) and PINs are issued by gotoBilling upon approval of a merchant's account application. These are sensitive fields that must remain confidential. Under no circumstances should the contents of these fields be available to the shopper, either on-screen or through a browser's View/Source command. Instead, they should be filled in by the merchant's web application prior to forwarding to GOTOBILLING.
  • Merchants must be approved in advance to submit electronic check credit transactions. Once approved, specific conditions apply.

Use of the x_payment_token_id field

The Purpose of the x_payment_token_id field is to allow a “one-time” sending of the Credit Card number or the Route and Account number (for an ACH transaction) and then be able to reference it in the future without needing to send the card number or account number again. This allows an application to be developed where it does not have to store these sensitive numbers but instead, gotoBilling is the only place these numbers are stored securely. A future transaction may be as simple as needing to process a credit card refund or an ACH credit. This can now be accomplished if the associated x_payment_token_id from the original transaction is sent. Therefore, the application must keep a database of x_payment_token_ids for all transactions sent if future transactions using this field are to be performed. The following are the basic points regarding using this feature:

  • Initially, the payment account information (CC Number, ACH Account) can be sent along with the x_payment_token_id.
  • The account can then be accessed in the future by simply passing the x_payment_token_id for the desired account. The individual account information is not needed.
  • If any account information is passed with an existing x_payment_token_id. That account information will be updated to match the information given.
  • The x_payment_token_id should be unique. Technically it only has to be unique per Customer ID (x_customer_id) but it might be easier to design if it is unique across the entire Merchant ID (merchant_id) so there’s no duplication at all. One suggestion would be to have the x_payment_token_id be the x_customer_id+(some value) where the value could be the date in YYYYMMDD format. This would facilitate easier research if needed and would likely be easier to implement than other numbering schemes. Especially since the x_customer_id must be unique across the Merchant ID.

IMPORTANT NOTE: Validation for the uniqueness of this field will be added in the future, however, it is not currently live.

When using the x_payment_token_id to reference an existing credit card on file, the following credit card fields are not needed as they will already be on file in gotobilling when the original transaction was sent:

  • x_cc_type
  • x_cc_name
  • x_cc_number
  • x_cc_exp

For ACH transactions, the following fields will not be needed since they will be on file:

  • x_ach_route
  • x_ach_account
  • x_ach_account_type

Data Type Conventions

ModifierDefinition
aAlpha characters [a-z, A-Z]
nNumeric digits [0-9]
s

Special characters -.@#,

Transaction Fields

Merchant Credentials

Merchant credentials can be submitted in a couple of different ways.  The legacy method of using the six digit merchant ID and gateway pin, or using an API access key pair.  Only one set of credentials are required.  It is recommended to use the API key pair which allows for greater control over the credentials.  You can generate an Access key pair in the OmniFund dashboard by visiting:  Profile > API Access

API Access Key Pair

For more information on obtaining an API access key, see: Managing API Access Keys

FieldRequiredDescription
access_keyRequiredGenerated API access key
access_key_secretRequiredKey secret associated with the given access_key

OAuth2 Client ID & Secret

For more information on obtaining and working with an OAuth2 client, see: Managing OAuth Clients

FieldRequiredDescription
client_idRequiredGenerated Client ID
client_secretRequiredClient secret associated with the given client_id

OAuth2 Client ID & Access Token

For more information on obtaining and working with an OAuth2 client, see: Managing OAuth Clients

FieldRequiredDescription
client_idRequiredGenerated Client ID
access_tokenRequiredUser access token

Merchant ID and PIN (deprecated)

For more information on obtaining your PIN, see: Generating a Merchant Gateway Pin

FieldRequiredDescription
merchant_idRequiredMerchant ID assigned by gotoBilling
merchant_pinRequiredMerchant Pin associated with the Merchant ID. Assigned by gotoBilling

Optional Fields

FieldRequiredMax LengthDescription
x_relay_urlOptionalan. ..Contains the URL to which the gateway will post the response. Include http:// or https://. When set the gateway response will automatically be sent via HTTP POST to this location.
x_relay_typeOptionala. 7Indicates the type of action of the response. When ACTIVE is set the browser will automatically be sent to the location specified with x_relay_url. When PASSIVE is set the browser will not be redirected, but the response will be sent to the location specified with x_relay_url via HTTP POST. This is set to default to PASSIVE

x_debug

Optionaln. 1When set to 1 (numerical one) transactions will be sent in test mode. A response will be given for the transaction, but no processing will occur. Default: 0 (zero).
x_versionOptionalns 3DEFAULT: 1.1  (When this value is set to 1.2, the transaction Gateway Response will be returned in JSON format, rather than XML format)

Customer Fields

FieldRequiredMax LengthDescription
x_customer_idRequiredans 32A unique customer Identification number set by

the merchant.

x_companyConditionalan 32The company associated with the billing address. Either first name & last name, or company name must be given.
x_last_nameConditionalan 32The last name of the customer associated with

the billing address. Either first name & last name, or company name must be given.

x_first_nameConditionalan 32The first name of the customer associated with

the billing address. Either first name & last name, or company name must be given.

x_address1Optionalan 32The address associated with the billing

address

x_address2Optionalan 32Continuation address associated with the

billing address

x_cityOptionala 40The city associated with the billing address
x_stateOptionala 2The state associated with the billing address.

The state is formatted using the two letter post abbreviation. Example: FL

x_zipOptionalns 10The zip code associated with the billing address
x_phoneOptionaln 10The phone number of the customer associated with the billing address. Does not contain any dashes – ex. 2223334444
x_emailOptionalans 50The email of the customer associated with the billing address.

Transaction Information

FieldRequiredMax LengthDescription
x_transaction_typeRequired2This field identifies the type of transaction

being submitted. Valid transaction types are:

Credit Card Type:

  • AS – Authorize Only
  • DS – Capture Only
  • ES – Authorize & Capture
  • CR – Credit/Refund
  • VO – Void
  • AV – AVS Check Only
  • OF – Offline (Force)

ACH Transactions:

  • DH - Electronic Check Debit
  • DC - Electronic Check Credit
  • DV - Electronic Check Verification Only
  • PN - Electronic Check Pre-Note

Transaction Administration:

  • RM - Remove transaction (See x_invoice_id)
x_invoice_idRequiredan 32Unique transaction ID field specified by the merchant. Also used in determining duplicate submissions.

For transaction type ‘RM’ this can be set to a specific id to remove a single transaction, or can be set to ‘ALL’ to remove all transactions currently pending for the given customer id.

x_amountRequiredn 10

Amount to be charged or credited. The amount may be formatted with or without a decimal. If no decimal is given two (2) decimal places are assumed (1.00 = 100).

Note:  Must be zero (0) for PN transaction types.

x_process_dateOptionaln 8Date on which the transaction is to be

processed. If no date is given, the transaction will default to the date it is submitted on. Format: YYYYMMDD

x_invoice_fileOptional

File containing information to be sent to the customer via email when the transaction is processed.

x_payment_token_idOptionalan 201) Initially the payment account information

(CC Number, ACH Account) can be sent along with the x_payment_token_id. 2) The account can then be accessed in the future simply by passing the x_payment_token_id for the desired account. The individual account information is not needed. 3) If any account information is passed with an existing x_payment_token_id. That account information will be updated to match the information given. The x_payment_token_id should be unique. Validation will be added for this, however it is not currently live.

x_memoOptionalans 255Description of transaction to be forwarded to

the customer.

x_notesOptionalans 255Internal notes to be stored with the

transaction.

x_occurrence_typeOptionalan 10Used for setting up recurring transactions.

Available types: • week • biweek • month • bimonth • quarter • semiannual • annual

x_occurrence_numberOptionaln 3Specify the number of occurrences for a

recurring transaction. If no occurrence number is giving, the default will be set to indefinite until deleted manually.

x_source_descriptionOptionalan 20This is to be used by the developer to send

the name and version number of the software that is sending the transactions. It’s a free form description field to tell GTB the source of the transactions.

x_module_descriptionOptionalan 20This field is used by the developer to send

the name and version number of a module or plugin that was built using this API. This allows for proper tracking of plugins or modules that may be built and then used in other software applications. The end software application name and version number would be put into the “source_description” field.

x_custom_fieldOptionaln 1Presentment indicator for ACH transactions.
x_po_numberOptionalan 50PO number associated with the transaction. Unique PO numbers can also be used by allow duplicate transactions if duplicate processing is current disabled.

Transaction Information - ACH

FieldRequiredMax LengthDescription
x_ach_payment_typeFor ach transactions: Requireda 3* PPD (Prearranged Payment and Deposit

Entry). Used to submit prearranged credit and debit transactions such as payroll deposits and periodic bill payments against a consumer's account.

  • WEB (Internet-Initiated Entry). Used to

submit debit entries pursuant to an authorization that has been obtained from the consumer via the Internet.

  • TEL (Telephone-Initiated Entry). Used to

submit transactions pursuant to an oral authorization obtained from the consumer via the telephone. NACHA regulations require that either the session in which the order was taken be recorded, or the consumer be notified in writing prior to initiation.

  • ARC (Accounts Receivable Entry): Used

to submit ACH debits for consumer checks received via the U.S. mail or at a drop-box location for the payment of goods or services. The consumer's source document (e.g. the check) is used to collect the consumer's routing number, account number, check serial number, (in raw MICR format) and the dollar amount for the transaction.

  • RCK (Re-Presentation Check Entry):

Format used to represent a returned check, through the generation of a single entry ACH debit. The RCK SEC allows for a single entry ACH debit transaction to represent a paper check after the paper check has been returned for either insufficient or uncollected funds.

  • ICL (Image Cash Letter): RESERVED-Use

only if directed to do so.

x_ach_routeConditionaln 9Routing number of the bank associated with

the customers bank account. Can send the x_payment_token_id to reference an existing Route and Account.

x_ach_accountConditionaln 20Account number associated with the customer's bank account. Can send the x_payment_token_id to reference an existing Route and Account.
x_ach_account_typeConditionala 2Personal Accounts
  • PC – Personal Checking
  • PS – Personal Savings

Business Accounts (Business designations currently not in use-they would create CCD transactions vs. PPD)

  • BC – Business Checking
  • BS – Business Savings

Not needed if x_payment_token_id is sent to reference an existing account

x_ach_serialConditionaln 10Check number of the transaction being submitted. Required for Payment Type ARC, RCK
x_arc_imageConditionalan 22TIF image file associated with ARC transactions
x_ach_verificationConditionaln 1Set to 1 to enable.. otherwise default is off.

There are two levels of ACH verification but that is set on the Account level at gotoBilling. If an ACH transaction receives an Authorization the status sent back will be R, if it is Declined, the status will be D.

Transaction Information – Credit Card

FieldRequiredMax LengthDescription
x_cc_typeFor cc transactions: Optionala 2Card Types:
  • VS – Visa
  • MC – MasterCard
  • AX – Amex
  • DC – Discover
x_cc_nameOptionala 32Contains the name located on the credit card
x_cc_numberConditionaln 22Contains the credit card number.

Can send the x_payment_token_id to reference an existing Credit card on file.

x_cc_expConditionaln 4Contains the expiration date for the credit

card. Format: MMYY Can send the x_payment_token_id to reference an existing Credit card on file

x_cc_cvvOptionaln 4Three or Four digit validation number for the credit card
x_ticket_idConditionaln 32Ticket ID of a transaction previously approved by the gateway. This is required for the following transaction types: DS (capture), CR (refund), VO (void)
x_authorizationConditionaln 32Authorization code of a transaction previously authorized by the gateway. This is required for the following transaction types: OF (offline force)
x_trackdataOptionaln 4Combined Track1 and Track2 data from credit card POS device.

Example Requests

Credit Card AUTH-CAPTURE

Request

POST https://secure.gotobilling.com/os/system/gateway/transact.php
Content-Type: application/x-www-form-urlencoded

merchant_id = "123456"
merchant_pin' = "gatewayPin"
x_transaction_type = "ES"
x_customer_id = "27500000001"
x_first_name = "Test"
x_last_name = "Account"
x_zip = "55555"
x_amount = "36.00"
x_cc_number = "4111111111111111"
x_cc_name = "Ester Tester"
x_cc_exp = "1215"

Response (Approval)

<ResponseData>
  <status>G</status>
  <order_number>122879-20050804-985829</order_number>
  <term_code>0</term_code>
  <tran_amount>36.00</tran_amount>
  <tran_date>20160804</tran_date>
  <tran_time>091121</tran_time>
<ticket_id>1234</ticket_id> <auth_code>094533</auth_code> <description>APPROVED</description> <avs>GOOD</avs> <cvv>UNKNOWN</cvv>
<type>card</type>
<card>
<network>Visa</network>
<number>4111xxxxxxxx1111</number>
<expiration>1215</expiration>
</card>
</ResponseData>

Credit Card PRE-AUTH, CAPTURE

PRE-AUTH Request

POST https://secure.gotobilling.com/os/system/gateway/transact.php
Content-Type: application/x-www-form-urlencoded

merchant_id = "123456"
merchant_pin' = "gatewayPin"
x_transaction_type = "AS"
x_customer_id = "27500000001"
x_first_name = "Test"
x_last_name = "Account"
x_zip = "55555"
x_amount = "36.00"
x_cc_number = "4111111111111111"
x_cc_name = "Ester Tester"
x_cc_exp = "1215"

Response (Approval)

<ResponseData>
  <status>G</status>
  <order_number>123456-20050804-985829</order_number
  <term_code>0</term_code>
  <tran_amount>36.00</tran_amount>
  <tran_date>20160804</tran_date>
  <tran_time>091121</tran_time>
  <ticket_id>1234</ticket_id>
  <auth_code>094533</auth_code>
  <description>APPROVED</description>
  <avs>GOOD</avs>
  <cvv>UNKNOWN</cvv>
<type>card</type>
<card>
<network>Visa</network>
<number>4111xxxxxxxx1111</number>
<expiration>1215</expiration>
</card> <payment_token_id>tok_194bfc699e124281b87f1ad4266e64be</payment_token_id> </ResponseData>

CAPTURE Request

POST https://secure.gotobilling.com/os/system/gateway/transact.php
Content-Type: application/x-www-form-urlencoded

merchant_id = "123456"
merchant_pin' = "gatewayPin"
x_transaction_type = "DS"
x_customer_id = "27500000001"
x_amount = "36.00"
x_ticket_id = "1234"

Response (Approval)

<ResponseData>
    <status>G</status>
    <order_number>123456-20170509-59120e0c5b178</order_number>
    <term_code>0</term_code>
    <tran_amount>36.00</tran_amount>
    <tran_date>20160804</tran_date>
    <tran_time>091121</tran_time>
    <ticket_id>1234</ticket_id>
    <auth_code>094533</auth_code>
    <description>APPROVED</description>
    <avs>GOOD</avs>
    <cvv>UNKNOWN</cvv>
    <phard_code>SUCCESS</phard_code>
    <payment_token_id>tok_194bfc699e124281b87f1ad4266e64be</payment_token_id>
</ResponseData>

Tokenization

Credit Card Tokenization Request

POST https://secure.gotobilling.com/os/system/gateway/transact.php
Content-Type: application/x-www-form-urlencoded

merchant_id = "123456"
merchant_pin = "gatewayPin"
x_transaction_type = "TK"
x_customer_id = "27500000001"
x_first_name = "Test"
x_last_name = "Account"
x_zip = "55555"
x_cc_number = "4111111111111111"
x_cc_name = "Ester Tester"
x_cc_exp = "1215"

Response

<ResponseData>
  <status>G</status>
  <order_number>123456-20161128-583c83a833fcd</order_number>
  <term_code>0</term_code>
  <tran_amount></tran_amount>
  <tran_date>20161128</tran_date>
  <tran_time>132112</tran_time>
  <invoice_id></invoice_id>
  <transaction_id></transaction_id>
<type>card</type>
<card>
<network>Visa</network>
<number>4111xxxxxxxx1111</number>
<expiration>1215</expiration>
</card> <payment_token_id>tok_9fc0739aa554441e96151bae88943154</payment_token_id> </ResponseData>

Credit Card Tokenization via Initial Sale Request

POST https://secure.gotobilling.com/os/system/gateway/transact.php
Content-Type: application/x-www-form-urlencoded

merchant_id = "123456"
merchant_pin = "gatewayPin"
x_transaction_type = "ES"
x_customer_id = "27500000001"
x_first_name = "Test"
x_last_name = "Account"
x_zip = "55555"
x_amount = "36.00"
x_cc_number = "4111111111111111"
x_cc_name = "Ester Tester"
x_cc_exp = "1215"

Response

<ResponseData>
  <status>G</status>
  <order_number>122879-20050804-985829</order_number
  <term_code>0</term_code>
  <tran_amount>36.00</tran_amount>
  <tran_date>20160804</tran_date>
  <tran_time>091121</tran_time>
  <ticket_id>1234</ticket_id>
  <auth_code>094533</auth_code>
  <description>APPROVED</description>
  <avs>GOOD</avs>
  <cvv>UNKNOWN</cvv>
<type>card</type>
<card>
<network>Visa</network>
<number>4111xxxxxxxx1111</number>
<expiration>1215</expiration>
</card> <payment_token_id>tok_5aeda1a4e5e244cbbb45d6594dbb1ad</payment_token_id> </ResponseData>

Subsequent Requests

All other request may utilize the 'x_payment_token_id' instead of the card data.

POST https://secure.gotobilling.com/os/system/gateway/transact.php
Content-Type: application/x-www-form-urlencoded

merchant_id = "123456"
merchant_pin = "gatewayPin"
x_transaction_type = "ES"
x_customer_id = "27500000001"
x_first_name = "Test"
x_last_name = "Account"
x_zip = "55555"
x_amount = "5.00"
x_payment_token_id = "tok_5aeda1a4e5e244cbbb45d6594dbb1ad"

Gateway Response

The Gateway Response API defines the type of information that will be sent by the gateway once a transaction has been processed. The gateway response type can be changed from the default XML response to a JSON response by passing in x_version=1.2 through incoming parameters, as outlined in the Optional Fields section above.

Non-Rely Response.

Gateway Responses are delimited by the GOTOBILLING tags:

<ResponseData>
</ResponseData>
Tag nameDescription
<status></status>Transaction Status. Values are:
  • G - Approved
  • R - Received
  • D - Declined
  • C - Cancelled
  • T - Timeout waiting for host response
  • E – Invalid debug card number

Response Statuses for Various Transaction Types: Credit Card:

  • AS – Authorize Only (G if approved)
  • DS – Capture Only
  • ES – Authorize & Capture (G if approved)
  • CR – Credit/Refund
  • VO – Void

Future dated transactions always get R on both Credit Card and ACH transactions.

When using the ACH Verification option, if an ACH transaction receives an Authorization the status sent back will be R, if it is Declined, the status will be D. An

<order_number></order_number>A 22-digit code, formatted nnnn-nnnnn-nnnnn, used

by GOTOBILLING to synchronize and track transactions and orders. It is not used or recognized by the GOTOBILLING host computers.

<term_code></term_code>The reason the gotoBilling process

terminated. Values are: 30998 Internal software error. 20999 Missing or invalid Merchant-ID 20998 Could not validate Merchant-ID 20997 Invalid server (potential security violation) 20996 Missing transaction type 20995 Invalid transaction type 20994 Reserved 20993 Reserved 20992 Reserved 20991 Reserved 20990 Reserved 20989 Both Card and Check services are turned off 20988 Merchant is not approved for service 20987 Reserved 20986 Reserved 20985 Reserved 20984 Reserved 20983 Reserved 20982 Reserved 20981 Reserved 20980 Reserved 20979 A required transaction field is missing 20978 A required transaction field is invalid/missing 0 Normal Termination On 20979 and 20978 the <description> field will tell what field it is that is missing or invalid.

<tran_amount></tran_amount>The amount of the transaction. This field should be the

same as the field x_amount in the submitted transaction (see above).

<tran_date></tran_date>Date Stamp of when the transaction was processed.

Format: YYYYMMDD

<tran_time></tran_time>Time Stamp of when the transaction was processed.

Format: HHMMSS

<invoice_id></invoice_id>Echo of merchant submitted Order ID
<ticket_id></ticket_id>For credit card transactions this is the 'x_ticket_id' that is used when performing a void or refund.
<auth_code></auth_code>Reference number identifying the transaction on the gateway
<description></description>Description of any error or decline returned for the

transaction.

<avs></avs>AVS response text
  • BAD – no match on street or zip
  • GOOD – street and zip match
  • STREET – Zip match, street doesn't
  • ZIP – street match, zip doesn't
  • UNKNOWN – AVS info not available, treat as good
<cvv></cvv>CVV response text
  • BAD – CVV code doesn't match
  • GOOD – CVV code match
  • UNKNOWN – CVV data not available, treat as good
<phard_code></phard_code>Text supplied by the card issuer. Generally additional details about a decline
<version></version>

(optional response) Version response text is returned ONLY when x_version is specified in incoming parameters.

  • 1.1 - XML Format returned
  • 1.2 - JSON Format returned
<type></type>

(Conditional response based on type of payment specified) The type of payment received will be indicated by the following values:

  • bank (for transactions with ACH payment information included)
  • card (for transactions with Credit Card payment information included)

The type value returned in this node will indicate what payment type value node to look for in the provided response.

    <card>
        <network></network>
        <number></number>
        <expiration></expiration>
    </card>

(Conditional response provided ONLY for Credit Card payments) Additional information about the credit card payment type will now be included in the card node. Children nodes include:

  • network (card type)
  • number (shows masked card number)
  • expiration (numbers only)
    <bank>
        <account></account>
        <routing></routing>
    </bank>

(Conditional response provided ONLY for ACH payments) Additional information about the ACH payment type will now be included in the bank node. Children nodes include:

  • account (shows masked account number)
  • routing (shows routing number)
<payment_token_id></payment_token_id>Token assigned to the payment account. Can be used in subsequent request instead of providing the actual card or bank details.

Example Non-Relay Response Data

<ResponseData>
  <status>R</status>
  <order_number>122879-20050804-985829</order_number
  <term_code>0</term_code>
  <tran_amount>12.33</tran_amount>
  <tran_date>20050804</tran_date>
  <tran_time>091121</tran_time>
  <invoice_id>123549854</invoice_id>
</ResponseData>

Relayed Response

A relayed response will contain the same information, but will be formatted in a HTTP REQUEST string. Active being POST and Inactive being GET.

Example Relay Response Data

?status=R&order_number=122879-20050804-
985829&term_code=0&tran_amount=12.33&tran_date=20050804&tran_time=091121&invoice_id=123549854

Example Non-Relay Response Data with ACH Verification

Approval

<ResponseData>
<status>R</status>
<order_number>122879-20081217198384</order_number>
<term_code>0</term_code>
<tran_amount>1.01</tran_amount>
<tran_date>20081217</tran_date>
<tran_time>131643</tran_time>
<invoice_id>44444</invoice_id>
<description>AUTH NUM 123-1234</description>
</ResponseData>

Decline

<ResponseData>
<status>D</status>
<order_number>122879-20081217198384</order_number>
<term_code>0</term_code>
<tran_amount>1.01</tran_amount>
<tran_date>20081217</tran_date>
<tran_time>131643</tran_time>
<invoice_id>44444</invoice_id>
<description>CHEXDIRECT|DECLINE CHECK|3 UNPAIDS (ALL)|UNPAID AMT= 35|PHN 800-238-5888|EXPRESS RECOVERY</description>
</ResponseData>


Level 2 Verification Information

Level 2 verification will return some additional information with the verification AUTHNUM. This additional info will be passed with the AUTHHUM in the <description> field with a pip ("|") delimiter.

Additional Info

valuedescription
Non-Participating: Negative InformationThis customer's bank does not participate in the Bank ACH Verification system. However, the normal negative database has negative information (returned checks) that are in the system.
ACH UnavailableThis merchant's bank account is not able to be debited via the ACH system.
Non-Participating: No InfoThis customer's bank does not participate in the Bank ACH Verification system and the customer's bank account has not been seen in the negative database system.
Account Closed or Neg StatusThe customer's bank participates in the Bank ACH Verification system and is reporting this account as Closed or in a state that will result in the ACH transaction being returned.
Account GoodThe customer's bank participates in the Bank ACH verification system and is reporting this account as open and in good standing.

Format

<description>
AUTHNUM|ADDTIONALINFO
</description>

Example

<description>
AUTH NUM 53793041|Non-Participating: No Info
</description>

Debug and Test Card Information

We also have some updated debug methods, which will be in the next version of the documentation. With this, while in debug mode (x_debug=1), you can trigger the gateway to give you an approve, decline or error response based on the reset of the information sent over.

Card #s that will return an approval "G"

  • 370000000000002
  • 6011000000000012
  • 4007000000027
  • 5424000000000015

Card #s that will return a decline "D"

  • 4222222222222

All other Card#s return an error "E"

Loopback Testing Procedures

gotoBilling now provides a built in (offline) processor module called 'Loopback' that can be used for black-box testing.

Overview: The 'Loopback' processor module was designed and implemented to replicate the base functionality of a 'Live' Processor for testing, training and development environments. Currently the Loopback module supports the following transaction types:

  • Credit Cards
  • Debit Cards

Note: The 'Loopback' module was designed for black_box testing against defined transaction amounts (i.e by supplying a certain amount you will force a defined response back from the server). Any amount other than the ones listed below should return a valid Authorization(AUTH). For this module to work you must set debug=0 and be using a valid development account issued by gotoBilling. To test integration with live merchant accounts please use the debug instructions located in the HTTP Integration API Package.

Test Parameters

Valid AVS

Street: 14520 Main Street Zip: 32615

-or-

Street: 2831 NW 41st St STE J Zip: 32606

Valid CV: (This must be supplied or you will always receive a Decline response)

Visa/MC/DISC: 999 Amex: 1234

Old basic amount checks

amountcode
$5.00DENY
$5.10CALL
$5.20PKUP
$5.30RETRY
$5.40SETUP

New amount checks (phard_code)

amountcodephard code
$6.01DENYGENERICFAIL
$6.02CALLCALL
$6.03RETRYNOREPLY
$6.04PKUPPICKUP_NOFRAUD
$6.05PKUPPICKUP_FRAUD
$6.06PKUPPICKUP_LOST
$6.07PKUPPICKUP_STOLEN
$6.08DENYACCTERROR
$6.09DENYALREADY_REVERSED
$6.10DENYBAD_PIN
$6.11DENYCASHBACK_EXCEEDED
$6.12DENYCASHBACK_NOAVAIL
$6.13DENYCID_ERROR
$6.14DENYDATE_ERROR
$6.15DENYDONOTHONOR
$6.16DENYINSUFFICIENT_FUNDS
$6.17DENYEXCEED_WITHDRAWAL_LIMIT
$6.18SETUPINVALID_SERVICE_CODE
$6.19DENYEXCEED_ACTIVITY_LIMIT
$6.20DENYVIOLATION
$6.21DENYENCRYPTION_ERROR
$6.22DENYCARD_EXPIRED
$6.23DENYRETRYREENTER
$6.24DENYSECURITY_VIOLATION
$6.25SETUPNOT_PERMITTED_CARD
$6.26SETUPNOT_PERMITTED_TRAN
$6.27DENYSYSTEM_ERROR
$6.28SETUPBAD_MERCH_ID
$6.29DENYDUPLICATE_BATCH
$6.30DENYREJECTED_BATCH
$6.31DENYACCOUNT_CLOSED

New amount checks (msoft_code)

amountcodemsoft_code
$6.50DENYCONN_TOREVERSAL
$6.51DENYCONN_MAXSENDS
$6.52DENYCONN_MAXATTEMPTS
$6.53DENYDB_FAIL

Visa Cardlevel Results

amountcardlevel
$7.00VISA_TRADITIONAL
$7.01VISA_TRADITIONAL_REWARDS
$7.02VISA_SIGNATURE
$7.03VISA_INFINITE
$7.04RESERVED (E^)
$7.05RESERVED (F^)
$7.06VISA_BUSINESS
$7.07VISA_CHECK
$7.08VISA_COMMERCE
$7.09RESERVED (J^)
$7.10VISA_CORPORATE
$7.11RESERVED (L^)
$7.12MASTERCARD_EUROCARD_DINERS
$7.13RESERVED (N^)
$7.14RESERVED (O^)
$7.15RESERVED (P^)
$7.16PRIVATE_LABEL
$7.17PROPRIETARY
$7.18VISA_PURCHASE_CARD
$7.19INTERLINK
$7.20VISA_TRAVELMONEY
$7.21RESERVED (V^)
$7.22RESERVED (W^)
$7.23RESERVED (X^)
$7.24RESERVED (Y^)
$7.25RESERVED (Z^)
$7.26RESERVED (0^)
$7.27RESERVED (1^)
$7.28RESERVED (2^)
$7.29RESERVED (3^)
$7.30RESERVED (4^)
$7.31RESERVED (5^)
$7.32RESERVED (6^)
$7.33RESERVED (7^)
$7.34RESERVED (8^)
$7.35RESERVED (9^)
$7.36VISA_SIGNATURE_BUSINESS
$7.37VISA_BUSINESS_CHECK
$7.38VISA_GENERAL_PREPAID
$7.39VISA_PREPAID_GIFT
$7.40VISA_PREPAID_HEALTH
$7.41VISA_PREPAID_COMMERCIAL
$7.42VISA_GSA_CORPORATE_TANDE
$7.43PRIVATE_LABEL_PREPAID
$7.44VISA_PURCHASE_FLEET
$7.45VISA_GSA_PURCHASE
$7.46VISA_GSA_PURCHASE_FLEET
$7.47RESERVED (V1)
$7.48AMEX
$7.49DISCOVER

If you have any questions regarding testing with the Loopback module, simply email support@gotobilling.com or visit the support desk at support.gotobilling.com