topic Re: Understanding why validateCustomerPaymentProfileRequest goes through in Integration and Testing

Understanding why validateCustomerPaymentProfileRequest goes through

Newba — Sun, 16 Feb 2014 15:23:47 GMT

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?

Re: Understanding why validateCustomerPaymentProfileRequest goes through

RaynorC1emen7 — Sun, 16 Feb 2014 20:56:53 GMT

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

Re: Understanding why validateCustomerPaymentProfileRequest goes through

Newba — Mon, 17 Feb 2014 03:55:45 GMT

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?

Re: Understanding why validateCustomerPaymentProfileRequest goes through

RichardH — Mon, 17 Feb 2014 05:23:52 GMT

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

Richard

Re: Understanding why validateCustomerPaymentProfileRequest goes through

Newba — Mon, 17 Feb 2014 14:06:13 GMT

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.

Re: Understanding why validateCustomerPaymentProfileRequest goes through

RaynorC1emen7 — Mon, 17 Feb 2014 14:37:48 GMT

You did use the livemode on the validateCustomerPaymentProfile?

Re: Understanding why validateCustomerPaymentProfileRequest goes through

Newba — Tue, 18 Feb 2014 20:41:37 GMT

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.

Re: Understanding why validateCustomerPaymentProfileRequest goes through

RaynorC1emen7 — Tue, 18 Feb 2014 21:20:38 GMT

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?

Re: Understanding why validateCustomerPaymentProfileRequest goes through

Newba — Wed, 19 Feb 2014 07:09:41 GMT

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:	0.00
Settlement Date and Time:	14-Feb-2014 15:45:34 PST
Business Day:	14-Feb-2014
Batch ID:	264095234
Authorization Information
Authorization Amount:	0.00
Submit Date /Time:	14-Feb-2014 05:37:49 PST
Authorization Code:	025176
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:	N
Partial Capture Status:	Not Applicable
Customer IP:
Payment Information
Card Type:	Visa
Card Number:	XXXX[REMOVED]
Expiration Date:	XXXX
Total Amount:	0.00
Order Information
Invoice #:	none
Description:	Test transaction for ValidateCustomerPaymentProfile.
Customer Billing Information
Name:	[REMOVED]
Company:
Address:	[REMOVED]
City:	[REMOVED]
State/Province:	[REMOVED]
Zip Code:	[REMOVED]
Country:	USA
Phone:
Fax:
Email:	[REMOVED]

Customer ID:	[REMOVED]

Re: Understanding why validateCustomerPaymentProfileRequest goes through

RaynorC1emen7 — Wed, 19 Feb 2014 12:24:41 GMT

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 authorize.net 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.

Re: Understanding why validateCustomerPaymentProfileRequest goes through

Newba — Wed, 19 Feb 2014 15:04:04 GMT

That's right, same information, except the amount, transaction type, description, and use of an invoice number in the actual order. That's an interesting idea to see if it would succeed with a higher amount. I'm having someone else do the live card testing so I don't need to ask them to reimburse me for using my personal card, and so that he can possibly discover any problems that I might not notice. So once he gets around to testing it again, if he uses the correct name and address and it fails, we can try to see if it will succeed with a different amount.