 |
|
|
 |
|
 |
|
|
|
|
 |
|
|
|
|
 |
|
|
|
|
 |
|
|
|
|
 |
|
|
|
|
 |
Free Bi-Monthly
Marketing Newsletter
|
|
|
|
|
|
 |
Merchants, Click
Below To Login
|
|
|
|
|
|
|
|
The following script represents the latest QuickCommerce interface for developers desiring to submit an "Authorization Request" via http and receive a response that indicates:
1) whether the request was accepted, declined, or invalid, and
2) The supporting data to go with such a response in an easy-to-receive single string format.
|
AuthRequest.asp does NOT return an html page as a response to an incoming http request. Therefore, it is not designed to be used as an immediate recipient to a standard browser form POST or GET. Developers should generate or "imitate" the http request using any number of available techniques for the desired scripting environment. Functions, libraries, plug-ins or code modules that can create such a request will likely be required to create the desired effect for which this API is intended, such as SSLEay and Dev-soft's ICK toolkit. Further, it is the responsibility of the web developer to ensure that the http request is properly encoded using SSL. In short, it is designed to function as a back-end interface for applications desiring a seamless and confidential/hidden link to the QuickCommerce gateway.
|
|
HTTP REQUEST FIELDS
LOGIN
Required for transactions other than test transactions. This is the assigned QuickCommerce login id.
PASSWORD
Required for Credit or Post Authorization transactions. For details on the use of transaction types, see the QuickCommerce User's Guide.
INVOICE
The order/transaction invoice number. It may be required to be unique according to the merchant's configuration. Uniqueness is determined by matching invoice numbers with the current day's existing invoice numbers only)
DESCRIPTION
Order/Transaction Description (This field will be trimmed to the first 80 characters before being stored by QuickCommerce)
AMOUNT
Order/Transaction Amount that authorization is requested for. The amount may only be negative for Credit transactions. A decimal point and 2 digits are required.
CUSTID
Your own assigned customer id the transaction.
METHOD
May be one of: VISA, MASTERCARD, AMEX, DISCOVER, JCB, ACH
TYPE
May be one of:
NA (means Normal Authorization)
AO (means Authorization Only)
CR (means Credit)
PA (means Post Authorization)
CARDNUM
Any valid Credit Card Number (not submitted or left blank for ACH transactions)
EXPDATE
Any valid Credit Card Expiration Date (not submitted or left blank for ACH transactions)
AUTHCODE
Required for PA transaction types. (not submitted or left blank for all other transaction types)
ACCTNO
Checking Account number (numbers only - no spaces or characters. not submitted or left blank for all credit card transactions)
ABACODE
Bank 9 digit ABA Transit and Routing Code (numbers only - no spaces or characters. not submitted or left blank for all credit card transactions)
BANKNAME
Name of bank where checking account exists. (Can be left blank. not submitted or left blank for all credit card transactions)
NAME
Buyer's name (Cardholder's name for credit card transactions, or Accountholder's name for ACH transactions)
ADDRESS
Buyer's address (used for Address Verification Service validation on credit card transactions)
CITY
Buyer's city
STATE
Buyer's state
ZIP
Buyer's ZIP (used for Address Verification Service validation on credit card transactions)
COUNTRY
Buyer's country
PHONE
Buyer's Phone
FAX
Buyer's Fax
EMAIL
Buyer's E-mail
USER1 - USER10
Relevant only to your own programming. These fields are not stored in the merchant's Authorize.Net batch records.
ECHODATA
If this field is not provided with a value of "TRUE", only the first 5 RESPONSE fields (see below) will be returned, otherwise all allowed fields provided in the request will returned in the response.
REJECTAVSMISMATCH
If this field is not provided with a value of "TRUE", the transaction will be accepted if it is authorized by FDC, even if the AVS response is a mismatch. Otherwise, the transaction must pass the "AVS test" with either a matching zip code, address, or both.
TESTREQUEST
If this field is provided with a value of "TRUE" the script will perform all validation functions except actually authorizing the transaction and storing it in the merchant's batch, regardless of whether the merchant's configuration is set to LIVE or TEST mode. In other words, the response would be equivalent to the merchant being in TEST mode
DELIMCHARACTER
If you want the RESPONSE FIELDS delimited by something other than the default (comma), provide the DELIMCHARACTER here.
ENCAPSULATE
If you want the response fields encapsulated in double quotes (ex. "response data"), provide this request field set to "TRUE"; otherwise, the response fields will not be encapsulated.
|
|
|
RESPONSE FIELDS
The following response fields are returned for all requests in a comma delimited format:
example: A,786432,,YYY,123456
example: T,,,,123456,testdrive,,,,,,,,,,,,,,,,,,,,,,,,,, (ECHODATA=TRUE)
1ST FIELD - RESPONSE CODE
May be one of the following:
A - Accepted/Authorized
P - Pending (treated as Accepted/Authorized; applies to ACH or Post Auth transactions)
D - Declined
R - Referral/Call Voice Center (treat as decline)
E - Error
T - TEST MODE
2ND FIELD - AUTHORIZATION CODE
This field will contain the authorization code returned from FDC. Or in the case of a PA transaction type (Post Auth), it will contain the authorization code provided in the REQUEST field AUTHCODE.
3RD FIELD - RESPONSE TEXT
This field will be blank for an accepted or TEST transaction response code (A,P or T); otherwise it will contain the reason for the response code.
4TH FIELD - AVS CODE
This field will contain a 3 character string if an AVS response is available for the transaction. Each character represents a match/mismatch. The first character is the Address match code, the 2nd character is the Zip code match code, and the 3rd character is a combined code. Possible AVS codes are: A, Y, N, Z, X. A match response would be a "Y". In the event that the REQUEST field REJECTAVSMISMATCH is set to TRUE, at least one of the 3 characters of the AVS response must be a Y for the transaction to be accepted.
5TH FIELD - INTERNAL ID
This field is the internal ID for the transaction. It is to be used for voiding and capturing transactions (when those features are available). A "capture" is only necessary for an AO transaction type.
All remaining RESPONSE fields are echoed from the original REQUEST fields, in this order:
( when ECHODATA = "TRUE" )
LOGIN
INVOICE
AMOUNT
METHOD
TYPE
DESCRIPTION
CUSTID
NAME
ADDRESS
CITY
STATE
ZIP
COUNTRY
PHONE
FAX
EMAIL
USER1
USER2
USER3
USER4
USER5
USER6
USER7
USER8
USER9
USER10
|
|
|
|
