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

/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_version	Description	Date
~	Added `PN` transaction-type for indicating ACH Pre-Note requests.	2021-07-14
1.3	`x_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

Modifier	Definition
a	Alpha characters [a-z, A-Z]
n	Numeric 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

Field	Required	Description
access_key	Required	Generated API access key
access_key_secret	Required	Key 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

Field	Required	Description
client_id	Required	Generated Client ID
client_secret	Required	Client 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

Field	Required	Description
client_id	Required	Generated Client ID
access_token	Required	User access token

Merchant ID and PIN DEPRECATED

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

~~Field~~	~~Required~~	~~Description~~
~~merchant_id~~	~~Required~~	~~Merchant ID assigned by gotoBilling~~
~~merchant_pin~~	~~Required~~	~~Merchant Pin associated with the Merchant ID. Assigned by gotoBilling~~

Optional Fields

Field	Required	Max Length	Description
x_relay_url	Optional	an. ..	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_type	Optional	a. 7	Indicates 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	Optional	n. 1	When 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_version	Optional	ns 3	DEFAULT: 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

Field	Required	Max Length	Description
x_customer_id	Required	ans 32	A unique customer Identification number set by the merchant.
x_company	Conditional	an 32	The company associated with the billing address. Either first name & last name, or company name must be given.
x_last_name	Conditional	an 32	The last name of the customer associated with the billing address. Either first name & last name, or company name must be given.
x_first_name	Conditional	an 32	The first name of the customer associated with the billing address. Either first name & last name, or company name must be given.
x_address1	Optional	an 32	The address associated with the billing address
x_address2	Optional	an 32	Continuation address associated with the billing address
x_city	Optional	a 40	The city associated with the billing address
x_state	Optional	a 2	The state associated with the billing address. The state is formatted using the two letter post abbreviation. Example: FL
x_zip	Optional	ns 10	The zip code associated with the billing address
x_phone	Optional	n 10	The phone number of the customer associated with the billing address. Does not contain any dashes – ex. 2223334444
x_email	Optional	ans 50	The email of the customer associated with the billing address.

Transaction Information

Field	Required	Max Length	Description
x_transaction_type	Required	2	This 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_id	Required	an 32	Unique 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_amount	Required	n 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_date	Optional	n 8	Date 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_file	Optional		File containing information to be sent to the customer via email when the transaction is processed.
x_payment_token_id	Optional	an 20	1) 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_memo	Optional	ans 255	Description of transaction to be forwarded to the customer.
x_notes	Optional	ans 255	Internal notes to be stored with the transaction.
x_occurrence_type	Optional	an 10	Used for setting up recurring transactions. Available types: • week • biweek • month • bimonth • quarter • semiannual • annual
x_occurrence_number	Optional	n 3	Specify 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_description	Optional	an 20	This 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_description	Optional	an 20	This 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_field	Optional	n 1	Presentment indicator for ACH transactions.
x_po_number	Optional	an 50	PO 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

Field	Required	Max Length	Description
x_ach_payment_type	For ach transactions: Required	a 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_route	Conditional	n 9	Routing 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_account	Conditional	n 20	Account 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_type	Conditional	a 2	Personal 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_serial	Conditional	n 10	Check number of the transaction being submitted. Required for Payment Type ARC, RCK
x_arc_image	Conditional	an 22	TIF image file associated with ARC transactions
x_ach_verification	Conditional	n 1	Set 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

Field	Required	Max Length	Description
x_cc_type	For cc transactions: Optional	a 2	Card Types: VS – Visa MC – MasterCard AX – Amex DC – Discover
x_cc_name	Optional	a 32	Contains the name located on the credit card
x_cc_number	Conditional	n 22	Contains the credit card number. Can send the x_payment_token_id to reference an existing Credit card on file.
x_cc_exp	Conditional	n 4	Contains 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_cvv	Optional	n 4	Three or Four digit validation number for the credit card
x_ticket_id	Conditional	n 32	Ticket ID of a transaction previously approved by the gateway. This is required for the following transaction types: DS (capture), CR (refund), VO (void)
x_authorization	Conditional	n 32	Authorization code of a transaction previously authorized by the gateway. This is required for the following transaction types: OF (offline force)
x_trackdata	Optional	n 4	Combined Track1 and Track2 data from credit card POS device.
x_token	Optional	ans ..	A valid 3DS (3D Secure) payment token, issued by a trusted provider offering payment tokenization, must be presented in this field. The x_token field value must be included along with the other conditionally required fields for Credit Card type transactions (x_cc_number, x_cc_exp and x_cc_cvv).

Example Requests

Credit Card AUTH-CAPTURE

Request

POST /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 /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 /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 /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 /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 /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 name	Description
<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 1 Verification Information

Level 1 ACH verification compares the given account information against a neg file database. Results for accounts that do not contain any negative data will return an AUTH NUM indicating that no negative events have been recorded for the account. Additional info will be passed in the <description> field.

Additional Info

value	description
History of Ineligible	Account does have a reported history and there is known transaction history on the account.
Routing Number is Invalid	Invalid bank routing number
History of Unauthorized	Account does not have a reported history or returns for Account Closed, Invalid Account, No account found, or Unable to locate, the routing number and account format are verified and there is no known transactional history on the account.
Wrong Account Structure	The account identified as suspicious format
Not populated	Account does not have a reported history or returns for Account Closed, Invalid Account, No account found, or Unable to locate, the routing number and account format are verified, and there is known transactional history on the account.

Format Accept

<auth_code>
AUTH NUM
</auth_code>

Example Accept

<auth_code>
AUTH NUM 6847027C
</auth_code>

Format Warning/Reject

<description>
ADDITIONAL INFO
</description>

Example Warning/Reject

<description>
HISTORY OF UNAUTHORIZED
</description>

Debug and Test ACH Information

decision	value	bank name	routing number	account number
ACCEPT	Valid (AUTH NUM)	Bank of America	053200983	11101010
WARNING	History of Ineligible	Bank of America	226078036	13590100098321
WARNING	Routing Number is Invalid	Bank of America	053200983	11101012
DECLINE	History of Unauthorized	Bank of America	226078036	13590100098319
WARNING	Wrong Account Structure	Bank of America	053200983	11101015

Level 2 Verification Information

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

Additional Info

value	description
Non-Participating: Negative Information	This 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 Unavailable	This merchant's bank account is not able to be debited via the ACH system.
Non-Participating: No Info	This 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 Status	The 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 Good	The customer's bank participates in the Bank ACH verification system and is reporting this account as open and in good standing.

Format

<description>
AUTH NUM|ADDITIONAL INFO
</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

amount	code
$5.00	DENY
$5.10	CALL
$5.20	PKUP
$5.30	RETRY
$5.40	SETUP

New amount checks (phard_code)

amount	code	phard code
$6.01	DENY	GENERICFAIL
$6.02	CALL	CALL
$6.03	RETRY	NOREPLY
$6.04	PKUP	PICKUP_NOFRAUD
$6.05	PKUP	PICKUP_FRAUD
$6.06	PKUP	PICKUP_LOST
$6.07	PKUP	PICKUP_STOLEN
$6.08	DENY	ACCTERROR
$6.09	DENY	ALREADY_REVERSED
$6.10	DENY	BAD_PIN
$6.11	DENY	CASHBACK_EXCEEDED
$6.12	DENY	CASHBACK_NOAVAIL
$6.13	DENY	CID_ERROR
$6.14	DENY	DATE_ERROR
$6.15	DENY	DONOTHONOR
$6.16	DENY	INSUFFICIENT_FUNDS
$6.17	DENY	EXCEED_WITHDRAWAL_LIMIT
$6.18	SETUP	INVALID_SERVICE_CODE
$6.19	DENY	EXCEED_ACTIVITY_LIMIT
$6.20	DENY	VIOLATION
$6.21	DENY	ENCRYPTION_ERROR
$6.22	DENY	CARD_EXPIRED
$6.23	DENY	RETRYREENTER
$6.24	DENY	SECURITY_VIOLATION
$6.25	SETUP	NOT_PERMITTED_CARD
$6.26	SETUP	NOT_PERMITTED_TRAN
$6.27	DENY	SYSTEM_ERROR
$6.28	SETUP	BAD_MERCH_ID
$6.29	DENY	DUPLICATE_BATCH
$6.30	DENY	REJECTED_BATCH
$6.31	DENY	ACCOUNT_CLOSED

New amount checks (msoft_code)

amount	code	msoft_code
$6.50	DENY	CONN_TOREVERSAL
$6.51	DENY	CONN_MAXSENDS
$6.52	DENY	CONN_MAXATTEMPTS
$6.53	DENY	DB_FAIL

Visa Cardlevel Results

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

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

Browser not supported