Change in response from apitest.authorize.net (error E00040), even code has not changed

[SteveW]

Hi folks,

For over a year, my site has been using PHP (on a LAMP stack) to call the CIM API at https://apitest.authorize.net/xml/v1/request.api

It has been working fine until yesterday.

Starting sometime in the hours before 2014-03-05T01:58:20+00:00 (UTC), I started receiving error E00040 ("Customer Profile ID or Customer Payment Profile ID not found.") when submitting customer profile transactions. This is happening even though I have not changed my code.

Here is a sample of the response XML I get from the Authorize.Net host:

<?xml version="1.0" encoding="utf-8"?><createCustomerProfileTransactionResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd"><messages><resultCode>Error</resultCode><message><code>E00040</code><text>Customer Profile ID or Customer Payment Profile ID not found.</text></message></messages></createCustomerProfileTransactionResponse>

The docs at http://developer.authorize.net/tools/cimerrorcodes/ describe the problem as this:

API Error Code: E00040
Error Code Text: The record cannot be found.
Description: The profileID, paymentProfileId, or shippingAddressId for this request is not for this merchant.

Since I haven't changed my code, I'm puzzled why this would be happening. I have tried this with multiple test accounts, which I have because I have separate test accounts for my dev and staging environments. The problem happens with all of my test accounts.

Is anyone else experiencing something like this?

Thank you for any insight you can provide.

[RaynorC1emen7]

Just try it with my test account. it work fine. could be just a temporary problem on the sandbox server.

[SteveW · Accepted solution]

I figured out the problem. In a very regrettable bit of programming in a third-party extension I bought, there was code that made and relied upon assumptions about the character length of the HTTP headers in the responses coming back from the Authorize.Net server. I just had to refactor that code to not make such assumptions. The HTTP headers coming from the sandbox server are currently about 200 characters longer than those coming from the Production server. I'm guessing those HTTP headers in the sandbox grew in length sometime this past Tuesday.