I continue to encounter billing failures for real customers when validating a new CIM payment profile for some non-US bank (Australian) credit cards. It would seem that the $0.01 (one-cent) validation transactions are declined by a few banks even when the customer's credit card account is valid.
I've found by hearsay that these declines are probably fraud protection measures put in place by certain banking institutions. It seems like the official CIM API's validateCustomerPaymentProfileRequest would be tuned to avoid such failure.
Anyone else see these problems? Would you share your solution to this quandary?
I'm curious if instead of using validateCustomerPaymentProfileRequest, calling createCustomerProfileTransactionRequest for $1 & then voiding it would be more likely to be successful?
Curious to hear your experiences,
I'll tell you what I do - it may not be appropriate for you. When a customer makes a purchase, I display a checkbox asking if they want to save the credit card for future purchases. If so, I do the current purchase normally using AIM, and then create a CIM profile specifying "test" mode that does not create the .01 transaction, assuming that if the AIM transaction succeeded, the card is good. I have not had a problem with this sequence. Since I always do it this way, I have not encountered the situation you did, but I do have many international customers who have saved their CC info with us.
If the customer's order is for backordered merchandise only, the AIM transaction is an "auth only" for $1.00. This too has never given me grief.
These declines may be due to the Address Verification System (AVS) rejection settings selected within the account you are using.
The Address Verification Service (AVS) is used to validate the address that is on file with your customer’s credit card issuer for domestic transactions. However, in most cases, credit card institutions outside of the US do not support AVS. The result is that most international transactions cannot have their addresses verified. This puts these transactions at a higher risk of fraud. This also may result in higher discount rates from your Merchant Service Provider for accepting international transactions.
By default, the Authorize.Net gateway rejects these types of transactions. However, these setting can be altered so the majority of international transactions can be processed. To modify your AVS settings, please review the following instructions:
1. Log into your Merchant Interface at https://account.authorize.net
2. Click Settings in the main left side menu.
3. Click Address Verification Service;
4. Unselect the check boxes for AVS Code G, U, and S to accept international credit cards
5. Click Submit to save changes
Note: By changing these settings, you do accept any risk associated with processing international transactions.
Setting <validationMode>testMode</validationMode> would prevent these declines during creation of the profile within your account, however the declines would still occur when a createCustomerProfileTransactionRequest function was attempted.
Thanks for explaining your transaction sequence. This kind of solution may be feasible for us. I would probably do the $1 authorization via AIM, void that auth, then create the CIM profile with no further validation.
The response we get back is "payment declined" not "AVS error". But our AVS settings are not exactly like you describe.
"G" & "U" are already unchecked, but we still have "S" checked. I will try unchecking "S" as well & see if our decline rate drops.
Thanks for your response!
One additional complication with the validation request for international transactions is from the currency conversion. For example, a USD 1¢ authorization attempt will be end up as a fractional cent when converted to Euros (approximately 0.6¢ at the current rate). As one might expect, international banks are more likely to reject this authorization than to simply round it up. Currently, the best workaround we can offer for this is to use a "testMode" validation when working with an international card.
A validateCustomerPaymentProfileRequest doesn't process a transaction but it does validate the payment information on file within the payment profile as much as is possible without processing a transaction, meaning it validates that the payment information on file passes a Mod-10 check and that the expiration date is a future date, but a createCustomerProfileTransactionRequest will process a transaction for the amount specified unless <validationMode>testMode</validationMode> is included in the request.
True validation of the payment information can only occur at the issuing bank and issuers are only sent this information for validation with a live mode transaction.
That is not true.
validateCustomerPaymentProfileRequest does process a transaction. It performs a $0.01 auth-only transaction, and then immediately voids it, thereby "validating the payment information with the card issuer's bank".
To clarify, Elaine's response was directed specifically at hotslot123's question regarding testMode validation. As she described, this type of transaction does not actually send any data to the card issuing bank and only performs field validation. This is significantly different from what happens when you specify liveMode validation or if you process a normal createCustomerProfileTransactionRequest.
The exception to this is if you have specified the validationMode element in the createCustomerProfileRequest to testMode. ValidationMode is not a required element for this transaction type and is an unlikely source of confusion, but it is important to note any exceptions to the rule. If you do specify the validationMode as testMode on a createCustomerProfileRequest, it will act similarly to a testmode validation.
Mars is absolutely correct that a validateCustomerPaymentProfileRequest will generate a $0.01 auth-only transaction if the validationMode is set to liveMode.