Authorize.Net request started returning errors after May 28 despite successful transaction approval

[andreeatatar23]

We started experiencing an issue with the payment request payload in the sandbox environment.

Until May 28th, the requests were processed successfully without any validation errors. However, starting after May 28th, the sandbox API began returning an error for a field that was previously accepted without issues:

AuthorizeNet operation failed. Serialized Object {
  "TransactionType":"authOnlyTransaction",
  "Messages":"E00013:The field is invalid.",
  "AvsResultCode":"Y",
  "CavvResultCode":"2",
  "CvvResultCode":"M",
  "TransactionMessages":"1:This transaction has been approved.",
  "Errors":null,
  "ResponseCode":"1",
   .......
}

What is unusual is that the transaction itself still succeeds, and the response explicitly contains: “This transaction has been approved.”
Despite the successful approval, the additional error in the response causes the overall payment flow to fail on our side.

We would like clarification regarding this recent behavior change:

• Was there any update or validation change introduced after May 28th?
• Was support for the client id field removed or modified?
• Why was the request accepted previously and now suddenly triggers an error?

[cpridmoreRemembers]

We are seeing this exact issue with same timeline. Production integration appears unaffected - but our lower environment test suite started reporting this issue within the last few days and we can consistently replicate it. We would like to understand the underlying cause before proceeding with a patch/upgrade. No information found for recent changes that would've caused this.

I believe this is the same issue here: AuthorizeNet/sdk-node#108

[kuldeepsingh0330]

I tried the following patch, and it started working again. Instead of using createTransactionController directly, I created a separate Test class that inherits from createTransactionController and overrides the ValidateRequest() method. In the overridden method, I override the clientId value and set it to an empty string before executing the request.

[andreeatatar23]

I tried the following patch, and it started working again. Instead of using createTransactionController directly, I created a separate Test class that inherits from createTransactionController and overrides the ValidateRequest() method. In the overridden method, I override the clientId value and set it to an empty string before executing the request.

We also identified a workaround by setting this field to null or an empty string. While this approach can be applied in our lower environments, it is not a viable option for Production, as Production is currently not affected and we cannot justify deploying a patch solely for this workaround.

Our main objective is to understand the root cause of this behavior and determine whether it is the result of a recent change, a known issue that will be addressed, or an expected behavior that requires a permanent adjustment on our side.

We need to understand why this started happening and whether there’s a fix coming, because we want to avoid a situation where this eventually hits Production and breaks payments, forcing us into an urgent hotfix

[ChavdarStoenchev]

Already hit the production today. Same fix works in PROD.

[andreeatatar23]

@ChavdarStoenchev, I believe they did a hotfix. I noticed this on their status page: https://status.authorize.net/ , and for us, the E00013 errors stopped after 11:56 UTC AM

[kuldeepsingh0330]

I am still encountering the same error in the Sandbox environment.

[kuldeepsingh0330]

Already hit the production today. Same fix works in PROD.

Someone just reported in the PHP SDK issue section that they are experiencing the same issue in production.
Comment Link

[ZacP]

Thanks @andreeatatar23 . It seems to us that there was a hotfix too. The issue is not occurring for us in sandbox today and was happening every other day this week.

[dosisod]

Kinda stating the obvious, but this was a totally preventable outage. Who at Authorize.NET is watching the SDK git repos? This was reported in multiple places before they updated the live API, and should've been caught before then.

My concern is that this will happen again, especially if there's nobody watching these repos or even testing against these SDKs before going live.