Sending clientId causes E00013 "The field is invalid."

[WillCodeForCats]

I was suddenly getting an E00013 error response when it worked normally before. After some digging I figured out this problem appears to be caused by the PHP SDK sending a clientId in the request.

sdk-php/lib/net/authorize/api/controller/base/ApiOperationBase.php

Line 112 in 0c48e24

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

I noticed this after comparing what the PHP SDK was generating for requests compared to the API documentation, and clientId is not listed anywhere in the API request field description. I cannot find any changelogs for the API that say this was a field that was removed, but clearly it doesn't like seeing it now and it wasn't a problem before. This line makes setClientId() method useless anyway since this overrides it if you try to set it to null when setting up AnetAPI\CreateTransactionRequest().

So if you're here because you're having this problem, delete (or comment out) this line in the execute() method of lib/net/authorize/api/controller/base/ApiOperationBase.php and see if that fixes the problem.

API fields ref: https://developer.authorize.net/api/reference/index.html#payment-transactions-charge-a-credit-card

[hxdev]

This seems to be a bug of the sandbox API, if you debug to the $response->getTransactionResponse(), you will see that the API returned: This transaction has been approved.

[WillCodeForCats]

If I try adding clientId in the "live API" thing it returns the following:

{
    "messages": {
        "resultCode": "Error",
        "message": [
            {
                "code": "E00003",
                "text": "The element 'createTransactionRequest' in namespace 'AnetApi/xml/v1/schema/AnetApiSchema.xsd' has invalid child element 'clientId' in namespace 'AnetApi/xml/v1/schema/AnetApiSchema.xsd'. List of possible elements expected: 'transactionRequest, transactionRequestEnc' in namespace 'AnetApi/xml/v1/schema/AnetApiSchema.xsd'."
            }
        ]
    }
}

But yes I did notice it wraps an approved transaction message in an API error. Since clientId isn't documented anywhere I can find I'm not sure why it's forced into the request. I'm handling removing it locally with a composer patch plugin.

[awGreY]

Got the same error. Any request containing clientId: "sdk-php-2.0.2" is rejected with E00013. Removing the field
makes the identical request succeed.

[wilau2]

@awGreY did you test without clientId in both sandbox and production environment ?

[akronberger]

I am also suddenly encountering this error on my C#/.NET application today, out-of-the-blue. Looks like it likely started happening between 5/28 and 6/1.

Authorize.net SDK 2.0.5. Google brought me here 😄 I will open an issue there shortly if appropriate, but just wanted to chime in as well.
If there was a production issue I definitely would have heard about it!

[WillCodeForCats]

I am also suddenly encountering this error on my C#/.NET application today, out-of-the-blue. Looks like it likely started happening between 5/28 and 6/1.

Authorize.net SDK 2.0.5. Google brought me here 😄 I will open an issue there shortly if appropriate, but just wanted to chime in as well. If there was a production issue I definitely would have heard about it!

Looks like clientId is here for sdk-dotnet and then called on line 177:

https://github.com/AuthorizeNet/sdk-dotnet/blob/f9f674a22ff1940424da8d61d06150f7d03a2913/Authorize.NET/Api/Controllers/Bases/ApiOperationBase.cs#L220

[awGreY]

@awGreY did you test without clientId in both sandbox and production environment ?

@wilau2 As for now, I have tested on the sandbox only. Don't have a live account to check, but no user reports so far.

[hxdev]

While I believe that this should be fixed on the API side instead of from the SDK, I suggest this fix approach from the app side instead of directly changing code in the vendor:

1. Create our own AuthorizeNetGateway, reimplementing the executeWithApiResponse from the SDK:

<?php

namespace App\Services\AuthorizeNet;

use net\authorize\api\constants\ANetEnvironment;
use net\authorize\util\HttpClient;
use net\authorize\util\Mapper;

class AuthorizeNetGateway
{
    /**
     * Execute an Authorize.Net request without injecting the SDK's undocumented
     * clientId field, which the API now rejects with E00013 "The field is invalid."
     * (see https://github.com/AuthorizeNet/sdk-php/issues/474).
     *
     * This is a minimal reimplementation of
     * net\authorize\api\controller\base\ApiOperationBase::executeWithApiResponse()
     * with one difference: it never calls $request->setClientId(...), so the field
     * stays null and each request type's jsonSerialize() drops it (array_filter on
     * non-null values). Omitting the field is valid for both sandbox and production.
     *
     * We must NOT "try with clientId, then retry without": the opaque-data nonce
     * (OTS token) used by the charge/hosted flows is single-use, and Authorize.Net
     * consumes it on the first attempt even when that attempt is rejected with
     * E00013 — a retry then fails with E00114 "Invalid OTS Token." Stripping
     * clientId up front keeps it to a single attempt that uses the token once.
     *
     * We deliberately keep using the original SDK request classes so that
     * Mapper::getXmlName() can resolve the request root element by its exact class
     * name (it has no parent-class fallback).
     *
     * @param object $request      An SDK request object (e.g. CreateTransactionRequest)
     * @param string $responseType FQCN of the SDK response type
     * @param bool   $sandbox      Use the sandbox endpoint when true
     * @return object|null         Parsed SDK response object, or null on transport failure
     */
    public static function execute($request, string $responseType, bool $sandbox)
    {
        $endpoint = $sandbox ? ANetEnvironment::SANDBOX : ANetEnvironment::PRODUCTION;

        $root = Mapper::Instance()->getXmlName(get_class($request));
        $payload = json_encode([$root => $request]);

        $http = new HttpClient();
        $http->setPostUrl($endpoint);
        $raw = $http->_sendRequest($payload);

        if ($raw == null) {
            return null;
        }

        // Strip UTF-8 BOM, mirroring ApiOperationBase::execute()
        $bom = pack("CCC", 0xef, 0xbb, 0xbf);
        if (strncmp(substr($raw, 0, 3), $bom, 3) === 0) {
            $raw = substr($raw, 3);
        }

        $decoded = json_decode($raw, true);
        $response = new $responseType();
        $response->set($decoded);

        return $response;
    }
}

2. Replace the usage of executeWithApiResponse with the new one:

From

$controller = new \net\authorize\api\controller\CreateTransactionController($request);
$response = $controller->executeWithApiResponse(\net\authorize\api\constants\ANetEnvironment::SANDBOX);

To

$response = \App\Services\AuthorizeNet\AuthorizeNetGateway::execute(
            $request,
            \net\authorize\api\contract\v1\CreateTransactionResponse::class,
            self::isSandboxEnabled()
        );

Tested and it works.

[WillCodeForCats]

Another alternative for composer is to have composer patch it. I ended up using the vaimo/composer-patches plugin to simply patch out the line that injects the undocumented clientId attribute. I agree it should be fixed in the API so that sandbox and production behave the same (otherwise what's the point of a sandbox if it has different behaviors you have to account for) but who knows when or if that would happen and I could do this immediately to get back to work. Sure, it changes code in the vendor directory, but in a more maintainable way than just directly editing the file.

For a patching approach in composer.json you need to add config and extra for patches:

  "config": {
    "allow-plugins": {
      "vaimo/composer-patches": true
    }
  }

  "extra": {
    "patches": {
      "authorizenet/authorizenet": {
        "Remove setClientId causing E00013 errors on authCaptureTransaction": "patches/authorizenet-remove-clientid.patch"
      }
    }
  }

In file patches/authorizenet-remove-clientid.patch

--- a/lib/net/authorize/api/controller/base/ApiOperationBase.php
+++ b/lib/net/authorize/api/controller/base/ApiOperationBase.php
@@ -108,8 +108,6 @@
     public function execute($endPoint = \net\authorize\api\constants\ANetEnvironment::CUSTOM)
     {
         $this->beforeExecute();

-    $this->apiRequest->setClientId("sdk-php-" . \net\authorize\api\constants\ANetEnvironment::VERSION);
-
         $this->logger->info("Request Creation Begin");
         $this->logger->debug($this->apiRequest);

[curotec-ajay]

Today, we encountered the same error in the production environment while processing a refund transaction.