cancel
Showing results for 
Search instead for 
Did you mean: 

Setting test mode on live account using API

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?

AuthNet603
Member
1 ACCEPTED SOLUTION

Accepted Solutions

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.

View solution in original post

8 REPLIES 8

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

RichardH
Administrator Administrator
Administrator

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.

@AuthNet603 Our API Reference is located at http://developer.authorize.net/api/reference

 

Richard

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.

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.

@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.

@crcarter Credentials refers to the API Login and Transaction Key used to authenticate with the gateway.

 

Richard

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.

 

BryanC
Member