Showing results for 
Search instead for 
Did you mean: 

Understanding why validateCustomerPaymentProfileRequest goes through

We have some transactions where validateCustomerPaymentProfileRequest, which is set to liveMode, goes through, but createCustomerProfileTransactionRequest gets a declined (2,1,2) error.  (This is on CIM with XML.)

I think most likely that there may be a mismatch of name or address, but I don't know why the validate transaction is accepted.  If the card information is entered wrong in some way, we would rather that the validate steps catches it first.  Shouldn't the validate step fail in live mode if the name or address is incorrect?


have you log the directresponse for both the validateCustomerPaymentProfile and createCustomerProfileTransaction? That might tell you what got send and what didn't.


We have the direct response for the failure; we don't log the successful ones.  The failure had 2,1,2.  As I understand, the third number (2) is the one that can give some insight into a failure, but the code "2" doesn't say much when we look it up (just reiterates what the first "2" says, e.g. "This transaction has been declined").  The AVS response says "P" ("AVS not applicable for this transaction").  I happen to know, though, that the address they entered and name of the cardholder were both incorrect.  This is using CIM, so these calls are just sending what's in the CIM record, which is wrong.  I could log the successful direct responses from the validation, but what information do you think it would give?  If it's successful, it will just show 1s for approved.  What I'm trying to better understand is why validateCustomerPaymentProfileRequest can be successful when we know that the cardholder name in the CIM and address are completely wrong.  Is there a way that we can make the validate step stricter?

Just to clarify, are you running these transactions in production or in the sandbox?



This is in production.  Everything works fine against the sandbox (using a test card).  I moved the code to production, but only testers are able to access the functionality until we've confirmed that everything is okay.  I asked them to test with a live card, and they're getting the 2,1,2 declined error, although the name and address that they used appear to me to be wrong.  I've asked them to correct the information and test again.  But in the meantime, I'm trying to understand why the "validate" operation succeeds.  All the manual says is "This function is used to verify an existing customer payment profile by generating a test transaction." I'm using the validate call so that I can have it display a screen to allow customers to correct the information before they click the final submit button to process the order.  Otherwise, if it only catches a problem at the end, then I'll need to redirect the user back to a screen to fix their payment information, which may be a less satisfying flow for the user.

You did use the livemode on the validateCustomerPaymentProfile?

Yes, it's set to liveMode.  That's why I'm asking. :)  It's set to liveMode, but it goes through.  It seems that liveMode doesn't check that the cardholder name is correct.   So I'm not even sure now what liveMode actually checks.

I did it on my test account and it look fine, it passed the billing info.

I just remember, since it create a auth_only, then void transaction, it should be in your settled batch, where you can see the detail and the result code. Have you look at that?

Yeah, if I search for settled transactions, these should up as "voided" transactions.  Here's one of them (with private data removed).  Notice that although I removed the name and address, these are the same as they are for the actual purchase which gets declined moments later.


Settlement Information

Settlement Amount:


Settlement Date and Time:

14-Feb-2014 15:45:34 PST

Business Day:


Batch ID:


Authorization Information

Authorization Amount:


Submit Date /Time:

14-Feb-2014 05:37:49 PST

Authorization Code:


Reference Transaction ID:

Not Applicable

Transaction Type:

Authorization Only

Address Verification Status:

Non US Card Issuing Bank (G)

Card Code Status:

Not Applicable

CAVV Result Code:

Not Applicable

Fraud Score Applied:

Not Applicable

Recurring Billing Transaction:


Partial Capture Status:

Not Applicable

Customer IP:


Payment Information

Card Type:


Card Number:


Expiration Date:


Total Amount:


Order Information

Invoice #:



Test transaction for ValidateCustomerPaymentProfile.

Customer Billing Information











Zip Code:












Customer ID:




And the 2,1,2 one have the same exact info, other then the amount and transactiontype?

Then it is the issusing bank issue as it show use the exact same info.


Question, what happened if you do createCustomerProfileTransactionRequest for 0 dollars?

I just re-read your other one, it said your were doing a $2 charge, maybe it have a min amount over that? and they know the $0 is for validation and let it process.