cancel
Showing results for 
Search instead for 
Did you mean: 

CIM Rejecting Random Create Profile Requests

Okay, I am having an issue with CIM right now that is perplexing me. Here's the response we got from Authorize.net:

 

(CreateCustomerProfileResponseType){
   resultCode = "Error"
   messages = 
      (ArrayOfMessagesTypeMessage){
         MessagesTypeMessage[] = 
            (MessagesTypeMessage){
               code = "E00027"
               text = "This transaction has been declined."
            },
      }
   customerProfileId = 0
   customerPaymentProfileIdList = ""
   customerShippingAddressIdList = ""
   validationDirectResponseList = 
      (ArrayOfString){
         string[] = 
            "2,1,2,This transaction has been declined.,,P,38NUMBERS83,none,Test transaction for ValidateCustomerPaymentProfile.,0.00,CC,auth_only,,Glenda, Person,,123 Any Street Box 2482,Bridgewater,NY,13313,,,,,none,none,none,none,none,none,none,none,0.00,0.00,0.00,FALSE,none,E4510NUMBERSLETTERS120085EFD,,,,,,,,,,,,,XXXX1234,Visa,,,,,,,,,,,,,,,,",
      }
 }

 

Everything I am reading is saying that this is an issuer decline. Fine... but then our customer is saying that Authorize.net told them that this is a problem with our software. Our customer then manually made the payment via the Authorize.net website and it went through with no problems.

 

Any idea of what the issue could be? It seems like the CIM is randomly rejecting people for no reason right now if that's the case.

 

We have not changed our integration at all and other clients don't seem to be affected even though they are on the same code base.

 

Our application is running on Python 2.7 and we are using SOAP requests.

 

Our Transaction Version is 3.1

 

I am sorry if I left out relevant information. Please ask for anything you might need to help me with this issue.

 

Thank you!

 

Scott

IWS_Scott
Member
1 ACCEPTED SOLUTION

Accepted Solutions

It looks like it might be related to this oldLiveMode issue here: http://community.developer.authorize.net/t5/Integration-and-Testing/CIM-validationMode-problem-oldLi...

 

It irks me that I had to spelunk for this information. Why doesn't Authorize.net's API auto-adjust for RBS Worldpay? Why isn't this documented in BIG RED FLASHING LETTERS?

 

Can your API not just accept the non-deprecated liveMode and switch in the background for processors that don't support it?

View solution in original post

IWS_Scott
Member
3 REPLIES 3

It looks like it might be related to this oldLiveMode issue here: http://community.developer.authorize.net/t5/Integration-and-Testing/CIM-validationMode-problem-oldLi...

 

It irks me that I had to spelunk for this information. Why doesn't Authorize.net's API auto-adjust for RBS Worldpay? Why isn't this documented in BIG RED FLASHING LETTERS?

 

Can your API not just accept the non-deprecated liveMode and switch in the background for processors that don't support it?

IWS_Scott
Member

Despite the content of the referenced thread, liveMode validation should work for all processors and card types.  The Authorize.Net system automatically decides whether to do a $0 or 1¢ based upon the card type and the processor that you are using. The reason that oldLiveMode was introduced as an option was not due to liveMode not functioning, but because the introduction of $0 authorizations increase the minimum data requirements for processing a transaction.

 

For a 1¢ authorization, only the card number and expiration date are required.  For a $0 authorization, the customers address and zip code must also be included. The oldLiveMode option was introduced so that a small segment of developers not already collecting the address information could use it while they updated their systems to collect this new data.

 

If you are including the cusotmer address and still seeing cards decline when using liveMode that approve using oldLiveMode, then it is something that we should look into for you. If you have specific examples of this occurring, please reach out to developer@authorize.net with some transaction IDs and we will look into it further.

That is precisely the scenario that is playing out. We are including a valid customer address and the exact same transactions are being declined when using liveMode vs. oldLiveMode. Literally that is the only thing we change and it magically starts working again.