Test Invalid Credit Card (CIM)

[jlvn]

Hello,

I am wondering if there is a way to test a card that cannot be billed in CIM using validateCustomerPaymentProfile. Currently, we use testMode to create a customer profile, but then submit a request to validateCustomerPaymentProfile to make sure that it works.

Is there a particular credit card number that I can use from my developer account that will get added with createCustomerProfile, but fail the validateCustomerPaymentProfile call?

If I submit an expired card, the call to createCustomerProfile will fail. What I really want to test is a card that is completely valid on the surface, but is actually unable to handle a charge.

Thanks in advance for the help!

[RaynorC1emen7]

On a production account only.
Set the validationmode=tesmode on createcustomerprofile. just use a test CC# like 4111111111111111.

can't do that with a test account not unless you want to set the expired date to the this month and test it next month.

[jlvn]

I see. Thanks for the help.

Is it not advised to use testMode in Production? The reason I ask is because we had a lot of clients complain about getting "double charged", so we transitioned to testmode in production. Is this a bad approach or is it fine?

[RaynorC1emen7]

You do get charge for every transactions you run on the production when testmode is off.

When you create a payment profile and set the validationmode = livemode, it will create an auth_only transaction(fee) to test the CC info. then when you create a charge transaction from that payment profile, will be another one.

[jlvn]

Interesting. We have a "recurring" process where we try to bill our users' cards for 5 consecutive days if they failed. From what I remember, when we have liveMode enabled, people were complaining that there were 5 $25 charges on their credit card, even though they were declined.

I believe this was the reason why we switched to testMode. When you use testMode, it first does a validation transaction before it tries to bill the full amount. Using this approach, our users don't have such a high amount in pending charges.

Is this the wrong approach in addressing this? Should you never use testMode in Production?

Thanks for your help!

[RaynorC1emen7]

when CIM parameter validationMode=testmode. the cc info are not getting validated, meaning they could put 4111111111111 and it will get save into the payment profile.

when CIM parameter validationmode=livemode, the cc info will get validated by an auth_only ($.01 or zero dollars) transaction to test the account.

Are they talking about getting hold on the credit or it did get charge 5 $25 charges? It could be your AVS settings that reject the transaction. But it will still be a hold on the credit unil the reject(void) transactions clear.

Should you never use testMode in Production?

depend on what the merchant want, some of the want to test it before saving it, some don't because of the fee for each test(auth_only) transaction.

[jlvn]

Yes, that's correct. Many of our clients were complaining about having so many holds on their credit cards. These could very well have been people who failed as a result of AVS errors. We used testMode to get around this issue because the test transaction was a much lower amount.

So from what I understand, there's no way to prevent these holds from getting added to a card if it fails due to an AVS error. Is that correct?

[RaynorC1emen7]

validationmode=livemode should have caught the AVS decline, while validationmode=testmode would not(there is NO test transaction).

Are you sure it wasn't validationmode=testmode when the 5 $25 hold happened because what would make more sense? And when it get decline, you do try to find out why it was decline in the CIM validationDirectResponse?

[jlvn]

So, I actually misspoke...here's the our situation:

We are currently using testMode. We switched from liveMode to testMode years ago, for reasons I'm not exactly aware of. With that being said, we WERE having customers complain about having numerous $25 holds on their credit cards. In order to address this, we made a call to validateCustomerPaymentProfile before making the charge so the pending charge would be a much lower amount.

This solution has seemed to work well for us with one exception. It seems that some banks interpret small charges like the one made with validateCustomerPaymentProfile as fraud. So we have had many customers who are unable to proceed with their payments, since their bank thinks that the validation charge is fraudulent. Is there any way you would address this?

I think the solution for our situation is to continue to call validateCustomerPaymentProfile before actually making the charge. We should be able to flip to liveMode without any issues. This way there aren't any holds for large amounts of money. Do you think this is a good practice? I'd be intested in a proposed solution to the fradulent charges that I described earlier.

Thanks again for all of your help!

[RaynorC1emen7]

From the CIM documentation

The validationMode parameter enables you to generate a test transaction at the time you
create or update a customer profile. The functions CreateCustomerProfile,
CreateCustomerPaymentProfile, UpdateCustomerPaymentProfile, and
ValidateCustomerPaymentProfile all include a validationMode parameter, which can have
one of the following values:
 testMode—performs field validation only. All fields are validated. However, fields with
unrestricted field definitions (such as telephone number) do not generate errors.
If you select testMode, a $1.00 test transaction is submitted using the Luhn MOD 10
algorithmto verify that the credit card number is in a valid format. This test transaction
does not appear on the customer's credit card statement,but it will generate and send
a transaction receipt email to the merchant.
 liveMode—generates a transaction to the processor in the amount of $0.01 or $0.00.
If successful, the transaction is immediately voided. Visa authorization transactions
are changing from $0.01 to $0.00 for all processors. All other credit card types use
$0.01. Consult your Merchant Account Provider before changing to Zero Dollar
Authorizations for Visa because you may be subject to fees.
For Visa transactions using $0.00, the billTo address and billTo zip fields are required.
 none—When this value is submitted, noadditional validation is performed. 

 By using testmode, it doesn't really test the CC other than it it pass the Luhn MOD 10, since it doesn't go to the processor, I not sure how it would sent to any bank at all.

It would be easier to see why it get decline when you charge the full amount by looking at the CIM validationDirectResponse, it should give a reason why it got decline and maybe some change on the merchant account settings can make it work better.