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
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.
03-20-2012 02:08 PM
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
03-20-2012 02:51 PM - edited 03-20-2012 02:51 PM
It is what it is, sorry. :/
03-20-2012 03:02 PM
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.
06-07-2012 12:00 PM
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.
06-11-2012 04:22 PM
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
10-17-2012 09:09 AM
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.
10-17-2012 10:54 AM
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
10-17-2012 04:37 PM
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.
11-08-2012 02:26 PM
At the bottom of the page.
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.
11-08-2012 04:00 PM