cancel
Showing results for 
Search instead for 
Did you mean: 

Triggering Specific Transaction Responses

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

Michelle
All Star
53 REPLIES 53

testMode only does surface validation, it doesn't check the content of the values to see if they match what's on file for the credit card. So yes, you'd need liveMode. I'm not familiar with oldLive, can't comment on that, except that it's generally safest to use the most recent solution.

 

Regarding foreign cards - charges are in USD, so depending on the currency, $0.01 may convert to fractions of a cent of their currency and be rejected by their bank. Also, AVS is often somewhat unreliable when it comes to foreign cards. My advice would be to have your system ask if they're outside the US, and if so, authorize for a couple dollars rather than $0.01. Also set your AVS to "Allow, report triggered filters", so you don't automatically reject foreign transactions that fail.

My advice would be to have your system ask if they're outside the US, and if so, authorize for a couple dollars rather than $0.01.

We're stuck using the validation modes because we need CVV to be verified. In CIM, I can't find any way to ensure that the CVV is passed along and verified unless we're using one of the associated validations modes and createCustomerProfileRequest/validate/update/etc.

 

We won't be using AVS against the transactions - we'll log the responses but aren't going to use it as a criteria for rejection due to problems we've heard about international AVS.

 

I guess I'll just have to implement the liveMode/oldLiveMode and see what the decline rates look like overseas - pretty disappointed in that as a solution though. If you can think of anythign else, I'd be very appreciative. :)

 

thanks,
Rob 

It is what it is, sorry. :/

Most of the transactions go through as approved with these different zip codes.

Are these tests not valid anymore ?

The response text from authorize.net says that the transaction was approved.

kjaworski
Contributor

These triggers are still fully functional.  You will want to make sure that you are running these tests in live mode on a sandbox account.

As a newcomer to Authorize.net and CC processing in general, it would seem to me beneficial to have testing or simulations reflect "real world" processing with 100% of the requirements for both.  In other words, except for CC numbers, exp dates, and CCV codes, make the testing EXACTLY the same as live accounts. If not possible for

completely live accounts, then at least "test mode" for live accounts.

 

Is there a reason this is not implemented, other than to simplify testing?  It's highly annoying to work through testing requirements, satisfy those, then find other issues once a site goes live.

 

Any feedback is appreciated!

 

Thanks!

 

Rick

what kind of test are you looking for, they do have test account for the test server which you can use to test your logic. The trigger here is for getting error since the test server don't really process the credit card info.

Not looking for any info in particular, I was just responding to the discussion. Test accounts should have as many of the requirements of a real account as possible. That was the point I was trying to make.

 

Rick

I'd appreciate some assistance in how to generate a specific response/response reason code, e.g., 2, 27

 

Tried using my developer account in 'live' mode with a good and valid cc except for the address on file with the card issuer. 

 

The transaction produced a 1,1 instead of that for which I was looking.

At the bottom of the page.

http://developer.authorize.net/guides/AIM/wwhelp/wwhimpl/js/html/wwhelp.htm#href=5_TestTrans.html#10...

 

Also, you don't need a valid cc for testing on the test account as it does not actually process the transaction to the processor, just simulating a transaction.