Hi everyone,
I'm integrating Authorize.net into my PHP application using the official Authorize.net PHP SDK (https://github.com/AuthorizeNet/sdk-php) and I'm running into the following error only on the Production environment:
E00007 - User authentication failed due to invalid authentication values.
The confusing part is that everything works perfectly in the Sandbox environment - transactions go through without any issues using my Sandbox API Login ID and Transaction Key against https://apitest.authorize.net/xml/v1/request.api. The moment I switch to my Production credentials and point to the Production endpoint, I get E00007.
I have already confirmed that:
- My Production API Login ID and Production Transaction Key are correctly copied from the Authorize.net Merchant Interface - no typos, no extra spaces, no hidden characters.
- I am pointing to the correct Production endpoint: https://api.authorize.net/xml/v1/request.api
- The same code structure that works in Sandbox is being used for Production, with only the credentials and endpoint swapped.
Here is the relevant portion of my PHP code:
$merchantAuthentication = new MerchantAuthenticationType();
$merchantAuthentication->setName('7h******N6s');
$merchantAuthentication->setTransactionKey('4L3******Pk6');
$refId = 'ref' . time();
$creditCard = new CreditCardType();
$creditCard->setCardNumber("4111111111111111");
$creditCard->setExpirationDate("2038-12");
$creditCard->setCardCode("123");
$paymentOne = new PaymentType();
$paymentOne->setCreditCard($creditCard);
$order = new OrderType();
$order->setInvoiceNumber("10101");
$order->setDescription("Golf Shirts");
$customerAddress = new CustomerAddressType();
$customerAddress->setFirstName("Ellen");
$customerAddress->setLastName("Johnson");
$customerAddress->setCompany("Souveniropolis");
$customerAddress->setAddress("14 Main Street");
$customerAddress->setCity("Pecan Springs");
$customerAddress->setState("TX");
$customerAddress->setZip("44628");
$customerAddress->setCountry("USA");
$customerData = new CustomerDataType();
$customerData->setType("individual");
$customerData->setId("99999456654");
$customerData->setEmail("EllenJohnson@example.com");
$duplicateWindowSetting = new SettingType();
$duplicateWindowSetting->setSettingName("duplicateWindow");
$duplicateWindowSetting->setSettingValue("60");
$merchantDefinedField1 = new UserFieldType();
$merchantDefinedField1->setName("customerLoyaltyNum");
$merchantDefinedField1->setValue("1128836273");
$merchantDefinedField2 = new UserFieldType();
$merchantDefinedField2->setName("favoriteColor");
$merchantDefinedField2->setValue("blue");
$transactionRequestType = new TransactionRequestType();
$transactionRequestType->setTransactionType("authCaptureTransaction");
$transactionRequestType->setAmount(20.00);
$transactionRequestType->setOrder($order);
$transactionRequestType->setPayment($paymentOne);
$transactionRequestType->setBillTo($customerAddress);
$transactionRequestType->setCustomer($customerData);
$transactionRequestType->addToTransactionSettings($duplicateWindowSetting);
$transactionRequestType->addToUserFields($merchantDefinedField1);
$transactionRequestType->addToUserFields($merchantDefinedField2);
$request = new CreateTransactionRequest();
$request->setMerchantAuthentication($merchantAuthentication);
$request->setRefId($refId);
$request->setTransactionRequest($transactionRequestType);
$controller = new CreateTransactionController($request);
$response = $controller->executeWithApiResponse('https://api.authorize.net/xml/v1/request.api');
if ($response != null) {
if ($response->getMessages()->getResultCode() == "Ok") {
$tresponse = $response->getTransactionResponse();
if ($tresponse != null && $tresponse->getMessages() != null) {
echo " Successfully created transaction with Transaction ID: " . $tresponse->getTransId() . "\n";
echo " Transaction Response Code: " . $tresponse->getResponseCode() . "\n";
echo " Message Code: " . $tresponse->getMessages()[0]->getCode() . "\n";
echo " Auth Code: " . $tresponse->getAuthCode() . "\n";
echo " Description: " . $tresponse->getMessages()[0]->getDescription() . "\n";
} else {
echo "Transaction Failed \n";
if ($tresponse->getErrors() != null) {
echo " Error Code : " . $tresponse->getErrors()[0]->getErrorCode() . "\n";
echo " Error Message : " . $tresponse->getErrors()[0]->getErrorText() . "\n";
}
}
} else {
echo "Transaction Failed \n";
$tresponse = $response->getTransactionResponse();
if ($tresponse != null && $tresponse->getErrors() != null) {
echo " Error Code : " . $tresponse->getErrors()[0]->getErrorCode() . "\n";
echo " Error Message : " . $tresponse->getErrors()[0]->getErrorText() . "\n";
} else {
echo " Error Code : " . $response->getMessages()->getMessage()[0]->getCode() . "\n";
echo " Error Message : " . $response->getMessages()->getMessage()[0]->getText() . "\n";
}
}
} else {
echo "No response returned \n";
}
What I have already verified:
- Sandbox integration is fully working with Sandbox credentials on https://apitest.authorize.net/xml/v1/request.api
- Production API Login ID and Transaction Key are correctly copied from the Merchant Interface (Production account)
- The endpoint is explicitly set to https://api.authorize.net/xml/v1/request.api (Production)
- Regenerated the Production Transaction Key from the dashboard to rule out an expired or revoked key
- No extra whitespace or hidden characters in the credentials
- The code logic is identical between Sandbox and Production - only the credentials and endpoint differ
My questions:
1. Since Sandbox works fine, what specifically about the Production account could still cause E00007?
2. Could account-level restrictions such as IP whitelisting, account not fully activated, or account status issues trigger this error even with correct credentials?
3. Is there anything special that needs to be enabled or confirmed on the Production account before API access is allowed?
Any guidance would be greatly appreciated. Thank you!
05-07-2026 01:51 PM
E00007 in Production almost always means the Production API credentials are not being accepted by the live gateway, even if Sandbox works. The most common causes are: using Sandbox credentials on the Production endpoint the Production account not being fully activated live yet, the Transaction Key being invalid after regeneration, or the account being in Test Mode under review. IP restrictions can also cause this if enabled in the merchant account. One important thing with the official PHP SDK, you should normally use the SDK environment constant instead of manually passing the URL. Also verify that your Production account can actually process live transactions and that API access is enabled in the merchant interface.
05-23-2026 01:52 PM
Since your Sandbox integration works and you've already regenerated the Production Transaction Key, the issue is likely account-related rather than code-related.
A few things to check:
Verify the Production account is fully activated
A Production merchant account that is pending activation, underwriting review, or otherwise restricted can return E00007 even with correct credentials.
Confirm you're using Production credentials
Double-check that the API Login ID and Transaction Key both come from the same Production account. Mixing a Production Login ID with a Sandbox Transaction Key (or vice versa) will trigger E00007.
Test with an API call that doesn't process a transaction
For example, an authentication-only request such as getMerchantDetails can help determine whether the problem is authentication or transaction processing.
Check for account restrictions
IP filtering, fraud settings, suspended accounts, or merchant account status issues can sometimes prevent API access.
Verify the account type
If the merchant account was recently created, ensure it is not still in test mode or awaiting final approval.
Contact Authorize.net Support
Since authentication is failing before transaction processing, support can quickly verify whether the login ID, transaction key, and account status are valid from their side.
One thing that stands out: E00007 is typically generated before any of the transaction details are evaluated. That means the card number, order data, customer data, and transaction type are unlikely to be the cause. I'd focus on merchant account status, credential pairing, and Production account configuration rather than the transaction request itself.
06-14-2026 10:29 PM