Netbilling Error Codes
Contents |
better help you understand the NETbilling processing gateway. The list is comprised of three sections:Transaction Origins,
Invalid Merchant Id
Transaction Authoriazation Response Code, and Transaction Status Codes, all listed sec violation on credit card machine in detail below. While we try to keep this information up to date and card no error accurate, some information may change from time to time and may not be immediately updated here. Please let us know if you need any
Visa Declined Codes
assistance by emailing: support@netbilling.com or by calling (661)252-2456. Transaction Origins AUTO-REFUND: System initiated refund V-TERM: Virtual Terminal, Manual action by logged in user N2.SIGNUP: Hosted payment form, membership signup N2.PURCHASE: Hosted payment form, one time purchase ND2.TRANS: Direct Mode v2 (signup or one time purchase) ND3.TRANS: Direct Mode v3
Credit Card Processing Error Codes
(one time purchase) ND3.SIGNUP: Direct Mode v3 (membership signup transaction) RAD.TEST: System Generated Test (Only on test account) BA.TRANS: Batch Upload Transactions RETRY: Rare, manual internal retry RECURRING: Rebill initiated by NETbilling automatically Transaction Authoriazation Response Code Authorization Response Codes: DECLINED: This is the most common, generic decline message. It is an actual decline from the issuing bank and details are not provided. AVS/CVV2 Authorization Responses: BAD ADDRESS: The AVS response received was not in the list of acceptable AVS codes. The transaction has been aborted. CVV2 MISMATCH: The CVV2 response received was not in the list of acceptable CVV2 codes. The transaction has been aborted. Fraud Defense Authorization Responses: When Fraud Defense is enabled, transactions that fail a Fraud Defense checkpoint will be rejected prior to an attempt to authorize the transaction. A/DECLINED: The transaction exceeded the traffic limits. B/DECLINED: The transacti
check payment, Credit Card payment, membership signups, and automatic rebillings. Using Direct Mode requires some knowledge of advanced CGI scripting or other programming techniques. Any examples given in this document will be provided in Perl. Additionally, a Perl serv not allowed script for Direct Mode access is available from Netbilling, and may speed your development.
Declined 05
A Java and C Direct Mode client is also available, contact Netbilling support at 888.357.8166 for more information. Of course, developers are welcome decline code 51 to write their own client libraries based on this specification. OVERVIEW The basic transaction in Direct Mode works as follows: The merchant's system makes a standard HTTP connection to the Netbilling server, passing the transaction data https://www.netbilling.com/info/transaction_defs08.html in an HTTP POST operation (with the parameters encoded in the body of the request). The Netbilling system then processes the transaction, and returns either a HTTP 200 (OK) along with the relevant return values, *or* the Netbilling server will return an HTTP 400 (ERROR) and the body of the response will be set to a string indicating the reason for the error. The URL for Direct Mode 2.1 is: https://secure.netbilling.com/gw/native/direct2.1 See the appendices http://secure.netbilling.com/public/docs/merchant/public/directmode/directmode21.html for specific fields to pass. Please contact Netbilling for any additional information. E-mail support@netbilling.com. ADVANCED FEATURES Advanced Procedure The most robust and secure way to issue a transaction via Netbilling's Direct Mode is to first obtain a Transaction ID from the Netbilling servers to assign to the transaction. Then if the transaction fails to return for any reason, it is still possible to track the transaction's status through the online reporting system. To obtain a valid TransID (passing a made-up or invalid TransID can cause serious processing errors) you can query the following URL: https://secure.netbilling.com/gw/native/getid1.0 The ID to use for the next transaction will be returned in the body of the response. It is possible to request multiple IDs simultaneously; simply append a ?x to the query URL, where x is the number of IDs to request. All the IDs will be returned int he body of the response, separated by newlines. Each ID is valid for ONE transaction only. The script must get a new ID for each new transaction. If the transaction should fail to return a proper response code for any reason, the status of the transaction can be gotten by querying the following url: https://secure.netbilling.com/gw/native/poll1.0 Pass the Trans ID of the transaction to poll for in as a trans_id cgi parameter. The script will return the
to completely automate payment processing. The Scriptable Reporting Interface is a Direct Mode style interface allowing merchants to access their transaction and membership data in a machine parsable format through https://secure.netbilling.com/public/docs/agent/public/directmode/repinterface1.4.html an easy-to-use network API. This data can be used for a merchant's own statistical monitoring or in conjunction with third party affiliate management software. All data is stored in the Gateway system and shared according to stringent Visa PCI regulations. 1.1 Overview This interface is intended to be used by merchants to develop their own software for monitoring transaction and membership error codes data or to utilize third party affiliate management software to accomplish these tasks. As outlined below, the Scriptable Reporting Interface is actually divided into two separate interfaces for separately acquiring transaction and membership data. This document outlines the technical specifications needed to take advantage of the Scriptable Reporting Interface and is intended for a technical audience. Knowledge of HTTP standards is netbilling error codes assumed. 1.2 Principles of Operation To make client implementation as simple as possible, the Scriptable Reporting Interface protocol is based on the standard HTTP protocol and SSL (HTTPS) encryption. Most modern languages have built in libraries that can be used to implement HTTP clients with very little effort. A request is initiated by sending an HTTP POST to our host. The host will respond momentarily with the resulting information on the same socket. All attribute-value pairs in the request should be URL encoded, just like a standard