cancel
Showing results forย 
Search instead forย 
Did you mean:ย 

How can I guarantee Card Not Present output?

I am software developer, and the company I work for supports both card-present and card-not-present account types.  The user supplies the account credentials.

 

(1) I am running an AUTH_CAPTURE test transaction against a card-not-present sandbox account. 

The response looks like this:

"1|1|1|This transaction has been approved.|..."

 

The first value is the success code 1.  As expected, the output is in the format described in the Card Not Present implementation guide.

(2) If I use the same code, and put in a card-present account, the response looks like this:

"1.0|3|87|Transactions of this market type cannot be processed on this system.|..."

Even though my input code was from the Card Not Present guide, the output now follows the format described in the Card Present guide.  My code incorrectly interprets the "1.0" in the first position as a success code. 

(Q) How can I cope with this if the format of the output depends on the input?

aps
Member
3 REPLIES 3

Here is the input message, with the sandbox account details removed:

 

"x_login=**********&x_tran_key=****************&x_delim_data=TRUE&x_delim_char=|&x_relay_response=FALSE&x_type=AUTH_CAPTURE&x_method=CC&x_card_num=371449635398431&x_exp_date=1219&x_version=3.1&x_amount=810.88&x_invoice_num=&x_description=&x_card_code=123&x_address=&x_city=&x_state=&x_zip=&x_country=&x_first_name=JOHN&x_last_name=DOE&x_allow_partial_auth=false"

aps
Member

From the AIM doc

http://www.authorize.net/support/AIM_guide_XML.pdf

 

marketType

0 for ecommerce
1 for moto
2 for retail

The default for Card Present
accounts is 2 and only 2 can be used.
For blended accounts, the default is 0
and marketType can be overridden

 

look to be, the blended account are for CNP only, so your CP account will always output as CP.

Thanks, that is helpful.

You are using the XML format, and I am using a property/value format.
http://www.authorize.net/support/AIM_guide_XML.pdf
http://www.authorize.net/support/AIM_guide.pdf

It's nice to know that they have an XML format because that would completely eliminate the problems of misinterpreting a pipe-delimited response.

I checked the property/value manual, and it has a field x_market_type similar to what you described.  The manual says it was added recently, in February 2014.  I should definitely start using that.

* When adding a required field, it would be nice if they would increment the version number and validate that the required fields are present.  This will help those of us who are working with legacy code and want to make sure everything is up to date.