topic Re: E00027 error in payment responses for production transactions by profiles in Integration and Testing

E00027 error in payment responses for production transactions by profiles

Andrui — Fri, 08 May 2015 10:17:28 GMT

I have a sandbox account. There is a customer profile with payment profile assigned in CIM.

I send request to URL https://apitest.authorize.net/xml/v1/request.api

<?xml version="1.0" encoding="utf-8"?>
<createTransactionRequest xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd">
    <merchantAuthentication>
        <name>...</name>
        <transactionKey>...</transactionKey>
    </merchantAuthentication>
    <transactionRequest>
        <transactionType>authCaptureTransaction</transactionType>
        <amount>3.00</amount>
        <profile>
            <customerProfileId>33328253</customerProfileId>
            <paymentProfile>
                <paymentProfileId>29941781</paymentProfileId>
            </paymentProfile>
        </profile>
    </transactionRequest>
</createTransactionRequest>

And receive response:

<?xml version="1.0" encoding="utf-8"?>
<createTransactionResponse xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <messages>
        <resultCode>Ok</resultCode>
        <message>
            <code>I00001</code>
            <text>Successful.</text>
        </message>
    </messages>
    <transactionResponse>
        <responseCode>1</responseCode>
        <authCode>M2539Z</authCode>
        <avsResultCode>Y</avsResultCode>
        <cvvResultCode/>
        <cavvResultCode>2</cavvResultCode>
        <transId>2233251497</transId>
        <refTransID/>
        <transHash>E261C989841E209F899F7E82B4C6747C</transHash>
        <testRequest>0</testRequest>
        <accountNumber>XXXX0027</accountNumber>
        <accountType>Visa</accountType>
        <messages>
            <message>
                <code>1</code>
                <description>This transaction has been approved.</description>
            </message>
        </messages>
    </transactionResponse>
</createTransactionResponse>

And this is ok. But after subsequent request with the same profiles within e.g. 10 seconds I receive response:

<?xml version="1.0" encoding="utf-8"?>
<createTransactionResponse xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <messages>
        <resultCode>Error</resultCode>
        <message>
            <code>E00027</code>
        </message>
    </messages>
    <transactionResponse/>
</createTransactionResponse>

Ok. I can guess that this is some kind of fraud/overdraft protection, but I have another big problem. There is another production account with multiple customer profiles (which have payment profiles assigned with real credit cards). But for every post on production URL with production merchantAuthentication I receive response with error E00027 without any error description. I other words payments by profiles in production mode don't work for me at all. BTW, these rejected transactions are not present in reposrts/transactions history.

Is there any possibility to get the real reason of this issue?

Re: E00027 error in payment responses for production transactions by profiles

RichardH — Thu, 14 May 2015 19:53:31 GMT

Hello @Andrui

I've reported your issue to the product team for analysis.

I'd recommend subscribing to this topic so that you'll be alerted via email if there are updates. To subscribe, click Topic Options at the top of this thread and then select Subscribe. You'll then receive an email once anyone replies to your post.

Thanks,

Richard

Re: E00027 error in payment responses for production transactions by profiles

Andrui — Fri, 15 May 2015 06:57:37 GMT

Hi @RichardH

Thank you for this. I will be waiting for the information from you and product team because this issue is very important.

BTW, I have tried to search information/solution for similar issues but without success.

Re: E00027 error in payment responses for production transactions by profiles

Andrui — Fri, 29 May 2015 08:20:50 GMT

Hi @RichardH

Is there any news from product team?

Thank you in advance.

Re: E00027 error in payment responses for production transactions by profiles

MuthuUVA — Tue, 23 Jun 2015 18:42:42 GMT

I am also having the same issue with my own card and address on card is right. The CIM/[Charge] allows you to [Charge] the profile. When you use the API to charge the 'same' profile, I receive E00027.

The behavior is the seen in bth Sandbox and in Production environment,

Appreciate your help to resolve this issue E00027 with Charging a Profile in CIM.

Re: E00027 error in payment responses for production transactions by profiles

Andrui — Fri, 03 Jul 2015 11:19:19 GMT

Hi @MuthuUVA

Just in order to exclude the variant of issue dependency on API client, can you please share the information, what client have you used (and from what OS) for sending XML request to Authorize.Net API?

e.g. I was using LWP::UserAgent module for perl.

Thank you in advance!

Re: E00027 error in payment responses for production transactions by profiles

MuthuUVA — Sat, 04 Jul 2015 02:40:29 GMT

I used SOAPUI as the Client from Windows to eliminate any user related coding errors.

BTW I sort of figured out the issue. In Payment Form, we made certain fields manadatory and the CIM API doesn't have any elements that would allow to send those fields. (ex) one such field is Invoice No. Once I made the Invoice No as optional in Payment Form, the call went through fine. Call was executed with error E00027 as the mandatory fields were not passed in the API Call.

Apparently, Authorize.Net was not returning any direct response in the above case. If I had received any direct response, it would have made it easier to troubleshoot.

Note: Payment Form is located in Autorize.Net Portal and one can configure mandatory fields in that form.

Check the mandatory fields in Payment form and make sure you indeed pass those mandatory fields in the CIM call. If you are not able to pass those manadtory fields, make it optional in Payment Form and give it a try. It should fo through without any issues.

Hoep it helps.

Re: E00027 error in payment responses for production transactions by profiles

Andrui — Mon, 06 Jul 2015 06:20:39 GMT

Hi @MuthuUVA

Many thanks. I am going to try your solution.

Re: E00027 error in payment responses for production transactions by profiles

Andrui — Wed, 22 Jul 2015 08:41:04 GMT

Hi, @MuthuUVA

I have checked, but I don't have fields marked as 'Required'. So, this seems is not my case :(

Re: E00027 error in payment responses for production transactions by profiles

Andrui — Wed, 22 Jul 2015 08:44:50 GMT

Hi @RichardH

Is there any news from the product team?
Does authorize.net have possibility to gather low-level debug in order to detect the root of the issue?

Thank you.

Re: E00027 error in payment responses for production transactions by profiles

RichardH — Thu, 23 Jul 2015 16:24:21 GMT

Hello everyone,

The problem you reported should now be corrected. Please confirm that it is working for you.

Richard

Re: E00027 error in payment responses for production transactions by profiles

willief — Mon, 27 Jul 2015 15:19:46 GMT

Richard,

I am not a developer but work for a reseller that has many merchants w/ auth.net. One in particular emailed me this morning and they're receiving this 00027 error code. It started up recently, that they're aware of, and it definitely happened a few times on Friday, 7/24 (the day after your post).

Is this an authorize.net issue that has hopefully been fixed? I'm trying to get confirmation on whether this is still occurring for them. They run a lot of transactions per day but have only received the message a fairly small amount of times, so it is very intermittent. They have been using auth.net for 3 months or so w/o this issue, but it is recent, which makes me think it isn't on their end.

Any help is appreciated!

Re: E00027 error in payment responses for production transactions by profiles

RichardH — Mon, 27 Jul 2015 18:27:40 GMT

Hello @willief

Yes, the problem originally reported should be corrected. If your merchants continue to see problems, I would suggest opening up a new thread with details on how to duplicate the problem. We would be happy to look into the issue for you.

Richard