cancel
Showing results for 
Search instead for 
Did you mean: 

Authorize.Net Customer Information Manager validationMode liveMode no test transactions.

When calling the CIM functions CreateCustomerPaymentProfile and UpdateCustomerPaymentProfile on a live account with validationMode set to liveMode CIM profiles are still accepted (no error returned) when Expiration Date, CCV, and/or BillingAddress are incorrect.

From the CIM_XML documentation it states that test transaction will be submitted to the merchant account when the validationMode is set to liveMode and in cases where the validation fails an error will be returned. However, as stated above, no error is returned and the profile is still accepted.Additionally, the validationDirectResponse field returned is empty/null.

It's almost as if validationMode is being ignored completely. Is there anything we need to do to our merchant account in order to avail CIM liveMode validation/test transactions? Are we perhaps forgetting something else besides setting validationMode to liveMode?

 

Edit: Language: C#

 

Thank you,
Robert Wearing

robert482
Member
6 REPLIES 6

Are you running CreateCustomerPaymentProfile() through in test mode (this is not the same thing as using a developer account or setting validationMode to test mode)? Because even if validationMode were set to testMode, it should still reject a bad expiration date. Billing address or a bad CCV could still be accepted depending on your AVS or CCV filter settings.

TJPride
Expert

Profiles are being created and updated in our Live account which is set to LiveMode as well. All things would suggest livemode validation would work but it doesnt.

 

We only reject if ccv isn't matched (which it shouldn't) and avs just sets flags but still accepts a transaction to be processed on a case by case basis.

Maybe it's not receiving the liveMode value. Try logging the XML just before it gets sent to Authorize.net, verify that the value is actually making it through.

Thank you. It appears that it's not being serialized out at all, so this looks very promising.

 

Thanks,

Robert Wearing

validationModeSpecified was never being set to true; I guess we missed it while reading through the API. Thanks for your help.

Nine times out of ten, the problem is human error :)