Triggering Specific Transaction Responses

[Michelle]

Using the Sandbox Account Error Generation Guide, developers can trigger specific transaction responses in the sandbox including approvals, declines, errors, as well as AVS and Card Code responses.

Use this thread for discussion: http://community.developer.authorize.net/t5/Integration-and-Testing/Triggering-Specific-Transaction-...

Richard

[tracent]

Thanks! I must have missed the 13 digit requirement.  It's working great now.

[Michelle]

Sweet. :smileyhappy:

[joatmon]

What is the current status of this?  I cannot get any of the zip codes to produce a transaction response. They all generate an error message on the payment form.

[joatmon]

No need to reply to previous post. I have resolved the problem.

[rmiron]

Hi,

Could you please provide a description for field [split_tender_status] returned in AIM response?
It will be of a great help to know its possible values and its position in the AIM response.

This field is mentioned in AIM official documentation (http://developer.authorize.net/guides/AIM/)

in section [Home > Section Two - Submitting Transactions > Partial Authorization Transactions],
but doens't shows up in section [Home > Section Four - Transaction Response > Fields in the Payment Gateway Response] I can't tell if it is present or not in my response.

Basically we need to establish when an order (containing multiple partial payments) is complete.

Here is an example:
HTTP POST Url:
        https://test.authorize.net/gateway/transact.dll?&x_login=8vLAwF38qF&x_tran_key=6sYgn3u3Nx98r5Tb&x_al... 02401&x_zip=46225&x_invoice_num=180870253&x_cust_id=43044&x_test_request=False&x_delim_data=TRUE&x_delim_char=,
HTTP POST Response
        4,1,295,The amount of this request was only partially approved on the given prepaid card. An additional payment is required to fulfill the balance of this transaction.,BKY0YN,Y,2157344524,180870253,,1.23,CC,auth_capture,43044,,,,,,,46225,,,,,,,,,,,,,,,,,,B817C974DBB30368ABF5619EC3ADE699,P,2,,,,,,,,,,,XXXX2222,Visa,102401,1.00,,,,,,,,,,,,,,   

Rares

[Trevor]

First off, that field actually should be removed from the documentation.  It is something that actually isn't returned with AIM or SIM using partial authorization.

As for the specific example that you provided, it is actually an invalid transaction.  The way that these triggers are designed, they will always attempt to provide the specified result, even if it is logically impossible.  You submitted an amount of $1 for your transaction, the 46225 zip code trigger that you used is designed return a partial authorization for $1.23.  The result is an impossible situation where you were partially authorized for more that you initially requested.  You'll want to run the transaction for more than $1.23 to see a reasonable transaction response.

You can determine whether or not the split tender transactions have been captured based upon the basic transaction result.  If you have run the transactions as AUTH_CAPTURE, then they will all be captured whenever a transaction is sucessfully processed (authorized in full) under that split tender ID.  If you have run the transactions as AUTH_ONLY, then they will never capture until you explicitly send the capture request.

[jaredanderton]

Hello,

I am having a hard time triggering the specific responses. I am a vendor doing this work for a client, and so I don't have access to the merchant interface, but I am sending x_allow_partial_auth=TRUE with my parameters. It is my understanding that parameter will enable the partial authorization for the current transaction. Is that accurate?

I am also sending these parameters:

x_card_num=4222222222222

x_amount=295.00

x_zip=46225

I am getting part of the response I am expecting, including the response code, response reason code, However the amount being returned is the amount I sent over, (not the expected 1.23). I am also not getting the new response fields, including the split tender id. An example response is:

4|1|295|(TESTMODE) The amount of this request was only partially approved on the given prepaid card. An additional payment is required to fulfill the balance of this transaction.|000000|P|0|||295.00|CC|auth_only|12|Jared|Anderton||606 West 9320 South|Sandy|UT|46225||||||||||||||||||E6ED01487EB921A0DC69F326E36A3B41|||||||||||||XXXX2222||||||||||||||||||FALSE

Is there something that I am missing?

[Trevor]

You are actually combining two separate ways of generating errors.  The 4222222222222 card number can be used to generate any specific response code in test mode, the zip code triggers are designed to cause specific responses on the the test server but in live mode.  In order for the zip code to cause a partial authorization response, you'll want to run the transaction in live mode with any other card number.

[treii28]

re:

---

@Trevor wrote:

You are actually combining two separate ways of generating errors.  The 4222222222222 card number can be used to generate any specific response code in test mode, the zip code triggers are designed to cause specific responses on the the test server but in live mode.  In order for the zip code to cause a partial authorization response, you'll want to run the transaction in live mode with any other card number.

---

UM, ok - then someone clarify to me please.  Can you 'test' in 'live' mode without generating a 'real' transaction?  And if you have to do it in 'live' mode than what is the purpose of test mode?

[Trevor]

Test mode is primarily for use on a real Authorize.Net account.  The developer test accounts that we provide should be run in live mode to simulate a much wider range of behaviors.  Transactions processed through a developer test account will never result in an actual charge to a credit card.