10-31-2017 10:15 AM
When a bill-to address is supplied but doesn't match the billing location for the credit card being added/updated:
According to the API documentation for liveMode validation, "Address is required for cards that support $0 authorizations and will be validated along with card code if submitted."
I see the response back for "Test transaction for ValidateCustomerPaymentProfile." for 0.00, but don't see anything different in the response I'm getting back regardless of what address is used.
Is there something I'm missing here....?
10-31-2017 12:29 PM - edited 10-31-2017 12:32 PM
Are you posting to the sandbox? If so, the sandbox will let any information pass, because the card is not actually submitted to the card companies for validation.
Though, you can simulate a variety of responses using the data at https://developer.authorize.net/hello_world/testing_guide/
10-31-2017 12:36 PM - edited 10-31-2017 12:38 PM
You could check your Authorize.net Merchant control panel, under Settings > Address Verification Service, to ensure your General AVS and Address and ZIP Code Responses are appropriate.
10-31-2017 12:52 PM
@NexusSoftware, I believe last time that was attempted, we ran into an issue where 'incorrect' addresses were causing rejections/declines. Granted, this was a few years ago, so maybe that has changed.
AVS settings seemed like an all-or-nothing approach. A business might be willing to take the risk of a charge-back on a $30 purchase, for example, but likely wouldn't risk it on a $30,000 transaction. I'm looking for something where a person can see if the address matches and decide for themselves, rather than a hard-stop for everything.
We want to give users a chance to correct the data if it seems like it might not match exactly, but we'd still prefer to capture it anyway if they want to continue anyway.
For the times when we simply don't have any billing location to tie the card to yet but we still want to create the payment profile and start the process, we currently create the payment profile using testMode and then switch to liveMode validation once an address is tied to it.
10-31-2017 01:04 PM - edited 10-31-2017 01:04 PM
You could select the Authorize and Hold For Review or Process, Report Triggered Filter option. Or you could capture a failed AVS response(codes 27 and 127) with your application and provide a way for your customers to modify their address before re-submitting.
10-31-2017 01:16 PM
Without declining the transaction, what -- beyond what I'm currently doing -- would allow me to 'capture a failed AVS response', though? Creating/updating the payment profile is not including any failure, which is why I posted this thread :)
Authorize and hold for review isn't practical for this application, unfortunately.
11-03-2017 06:12 AM
@NexusSoftware, still looking for feedback on your comment about us capturing "a failed AVS response(codes 27 and 127)".
How would you recommend that be done, as the create/update payment profile transaction does not appear to return a response code for that -- at least not without making some sort of global change that would adversely impact all of our processing...
11-03-2017 06:31 AM
You need to generate a failed response by adjusting your AVS settings, in order to capture and react to it.