For years I have been using the old "manual" AIM and am attempting to switch over to the newer API. I develop locally and test on a developer account/sandbox until things are working.
I then upload the code to the client's site and set "x_test_request" to true, which allows them to do their own testing and receive the merchant email from their account without the hassle of canceling charges. When we're all satisfied that everything works correctly, I set x_test_request to false.
I don't see a way to do this in the API, something like $request->setTestRequest(true); would be helpful, but it doesn't seem to have that functionality. Is there a way to do this or add the x_test_request parameter another way?
Requiring the client to have her own sandbox account is a no go, and forwarding all the merchant emails from my account isn't very convenient.
Or do I need to go back to the old AIM and ARB?
Solved! Go to Solution.
01-05-2017 12:44 PM
So, in other words, a transaction using "test mode" really isn't any different (to the user) than just echoing "Ok"? (Assuming the credentials are okay.) And I've been using it for almost 10 years! ;-)
I guess I'll fake it with authenticateTestRequest().
Also, it would be helpful if there was full documentation for the API somewhere. It would be far easier than fighting phpdoc or looking through the files.
01-06-2017 11:06 AM
Hello @AuthNet603
Good to hear from a long-time Authorize.Net developer.
First, setting Test Mode either through the API or within the Merchant Interface does one thing: it instructs the gateway to perform a credential check only. If the credentials are valid it returns a success response. If you send a request that would normally generate an transaction error but with valid credentials, it will still be returned as successful.
Bottom line is that setting Test Mode is only useful for validating credentials. It was removed from our API Reference because we offer authenticateTestRequest which performs the same function.
I hope this helps.
Richard
01-05-2017 01:34 PM
So, in other words, a transaction using "test mode" really isn't any different (to the user) than just echoing "Ok"? (Assuming the credentials are okay.) And I've been using it for almost 10 years! ;-)
I guess I'll fake it with authenticateTestRequest().
Also, it would be helpful if there was full documentation for the API somewhere. It would be far easier than fighting phpdoc or looking through the files.
01-06-2017 11:06 AM
01-06-2017 11:28 AM
Yes, but that's awful confusing the way it's set up. Without the sample code, there's no way of knowing that you need to use a method to set the credit-card information. Going by the API page you referenced, it looks like it should be done something like $transactionRequest->setPayment()->setCreditCard()->setCardNumber('4111111111111111'); or maybe $transactionRequestType->setPayment(setCreditCard(setCardNumber('4111111111111111')));
For instance, to figure out how to set the billing address you have look at the code for TransactionRequestType and find the setBillTo() method, which shows you that you need to submit a CustomerAddressType object. So you go to the CustomerAddressType class, see that it extends NameAndAddressType and look at that class to see what the setters are. Not exactly obvious for something that might be often used.
Also, is the name on the credit card no longer required? The API only seems to require a name for a bank account. And is there a way to get the actual string that is sent?
Thanks.
01-06-2017 12:38 PM
What Richard is pointing to is the documentation for the actual API used for communication with our servers to process transactions. That's the API that our SDK uses to communicate with the server. It takes the info that you pass to it, then constructs a request using those specific objects and parameters.
What you're looking for is some better documentation for the actual SDK you're using. I agree that's definitely needed. Like you said, you can follow the code in the SDK and figure out how it all works, but that's still not quite as easy as just having a document saying "add this setting by passing this data to this method like so".
One of my goals in the new year is to make more of these kinds of improvements to make the process easier where we can. In the meantime, feel free to check out the SDK projects on GitHub, and if you have any contributions that can make it better, we're happy to incorporate it. Even something as simple as adding comments to a section of sample code that you thought was confusing could go a long way toward easing the pain of other developers in the future.
With regards to the name, cardholder name is not a required field.
The easiest way to see the string sent is to check the log. The SDK by default creates a phplog file if you haven't already specified some other logging. In that log, you can see the actual API request that the SDK builds and sends.
01-06-2017 02:58 PM
@RichardHcan you clarify what you mean by "credentials" in this message?
Are you referring to the developer credentials (ie, our `login_key` and `transaction_key`) or to the customer credentials (ie, address and card code verification)?
Thank you.
06-13-2017 04:11 AM
@crcarter Credentials refers to the API Login and Transaction Key used to authenticate with the gateway.
Richard
06-13-2017 08:20 AM
Just to second the need for test requests... we have a website platform with around 400 retailers on it. Setting up sandbox accounts for all of these retailers would be out of the question.
There are many times when we need to perform end-to-end testing, where we don't actually want to charge the user's card/account.
Let's say we're implementing a custom coupon solution for a client... We need to test everything from the addition of the coupon to the correct storage of the transaction amount in the database, as well as the emails that get sent afterward with the corect $ amount inside. This could require 10 or more test transactions be made. Without being able to put the account in temporary test mode, this becomes difficult. If we were just returning 'OK' from the authorize.net functions, we'd be fine. However, we return a complex API response object that is populated with the various return values and stored inside a payments table. These results could be faked, but that gets annoying to maintain as the API evolves.
Though this is one small example, I hope it helps shed some light. In our older version of the API, we also set x_test_request to true. Not sure how to handle these now.
10-24-2018 08:53 AM