Authorize.net PHP API E00013 The field is invalid

[KT1984]

Yesterday transactions started failing while using authorize.net php API.  But after looking at the logs, the transactions weren't failing at all. In fact, I get response code 1: {"code":"1","description":"This transaction has been approved."}. However, I also get: {"code":"E00013","text":"The field is invalid."} at the same time, which was triggering my fail logic. I changed my fail logic so the transaction goes through on my site but would like to know what is causing the error E00013. It gives no reference. I did a basic test that uses only a card and amount, and the error still comes through in the response. I literally checked each field and then did nothing but test card data and amount. I have no idea what to do now?? Any help would be appreciated. 

[kishanpatel]

I'm also facing the same issue on the Authorize.net Sandbox environment:

Error:
E00013 - The field is invalid.

As a temporary workaround, I commented out the following line:

$this->apiRequest->setClientId("sdk-php-" . \net\authorize\api\constants\ANetEnvironment::VERSION);

File:

vendor/authorizenet/authorizenet/lib/net/authorize/api/controller/base/ApiOperationBase.php

After commenting out this line, the requests started working again in the Sandbox environment.

However, I'm not sure whether the same issue exists in the Production environment. If anyone has already verified this, please let me know.

Also, I'm looking for a proper solution instead of modifying files under the vendor directory.

Current package version:

"authorizenet/authorizenet": "~1.9.6"

Has anyone encountered this issue recently, or found a recommended fix/updated package version from Authorize.net?

[pamahesh]

Hi — this was due to a temporary platform issue, not your integration.

You were correctly seeing:

• response code 1 → transaction approved
• E00013 → incorrectly returned alongside it

The issue has now been resolved by the Authorize.Net team.

View incident details

[muhammadammar23]

If you're receiving Response Code 1 ("This transaction has been approved"), then the payment itself is succeeding. The E00013 ("The field is invalid") message is likely coming from another part of the API request or response processing.

A few things to check:

Make sure you're using the latest Authorize.net PHP SDK.
Review the full API response, especially the messages and errors sections, to identify which field is triggering E00013.
Check whether any optional fields (customer profile, line items, invoice number, merchant-defined fields, etc.) are being sent automatically by your code.
Verify that you're not sending empty strings or invalid values in optional fields.
If this started suddenly, check whether Authorize.net recently changed validation rules or if a specific API endpoint is affected.
Since even your minimal test (card + amount) returns E00013, it may be worth comparing the raw request/response payloads with a known-working transaction or contacting Authorize.net support with the transaction ID and full response details. The approval code suggests the transaction is processing correctly, but some non-critical field is failing validation.

[hunzafatimaa]

If the transaction returns Response Code 1 (Approved), the payment is successful. E00013 usually means an invalid or unsupported field elsewhere in the request. Check your full API request/response, update the PHP SDK, and review any optional fields being sent. If the issue started recently, it may be related to an API validation change.

[muhammadammar23]

If you're receiving Response Code 1 ("This transaction has been approved") along with E00013 ("The field is invalid"), the transaction itself is succeeding, but Authorize.net is detecting an invalid field elsewhere in the request or response processing.

A few things to check:

Make sure you're using the latest version of the Authorize.net PHP SDK.
Review any optional fields being sent automatically by your application, even if you're only setting card data and amount.
Log and inspect the full API request and response payloads to identify which field is triggering the validation warning.
Verify that no empty strings, null values, or improperly formatted fields are being included.
Check whether Authorize.net recently changed validation requirements for any fields your integration sends by default.
Since the issue started suddenly and persists even with a minimal transaction request, it may also be worth checking the Authorize.net system status or contacting support with the full API response. The key point is that E00013 is usually tied to a specific field, but sometimes the SDK or error handling obscures which one, making detailed request/response logging essential.