cancel
Showing results for 
Search instead for 
Did you mean: 

E00027 error in payment responses for production transactions by profiles

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?

Andrui
Member
12 REPLIES 12

Hello everyone,

 

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

 

Richard

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!

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