I'm using CIM with AVS and CVC, and I'm building a site that allows users to create a profile using createCustomerProfileRequest and then create one or more payment profiles using createCustomerPaymentProfileRequest. Everything seems to be working, except if the test transaction is declined because an AVS or CVC error was returned and then I correct the address or code and resubmit, I get a duplicate transaction error if I don't wait two minutes. I'm not running any transactions other than the test transaction that is run when validationMode is set to liveMode. CIM doesn't allow x_duplicate_window to be used with a createCustomerPaymentProfileRequest. How can I allow a user to be able to correct the address or card code and resubmit without waiting the two minutes?
Any help is appreciated.
Thanks.
06-09-2010 02:31 PM
@Rob_vH wrote:
If I could validate the PAN/exp_date/card_code prior to calling create customer payment profile I would do that. This seems impossible without already having a payment profile id.
Have you looked at running a Zero Dollar Authorization for this purpose, outside of CIM? That would validate the card elements you've listed, and I think it should accept a duplicate_window value.
09-16-2015 01:16 PM
Hi, it's 2017. Is this still not fixed?
08-09-2017 10:52 AM
Hi @janiv,
Define fixed.
The problem in this thread (as I understand it) is limited to this scenario:
This is still the case, but it's a bit of working as designed. createCustomerProfileRequest or createCustomerPaymentProfileRequest aren't designed to take the full array of transaction options such as the ability to set a timeframe for duplicate transactions. Thus, the authorization transactions made with those calls carry the default 2 minute duplicate checking window.
There are a number of workarounds or alternate solutions for anyone worried about this scenario, however.
So, even though it's working as designed, this could still change, of course. We could build the ability to set a duplicate window to go with these profile validation transactions. Or, we could change things so that validation transactions from the create profile requests come into our system with a shorter duplicate window by default. However, because it affects only one specific scenario and there are several workarounds, it's been a lower priority fix for us.
Note, the initial post in this thread mentioned AVS. A decline due to a mismatched address wouldn't be a problem here because any subsequent change in the address causes our system to not see the followon transaction as a duplicate.
08-09-2017 04:21 PM - edited 08-09-2017 04:23 PM
Almost 2021 and this is not fixed.
All workarounds assume that our business workflow and code can adapt to work with something that createCustomerProfileRequest could just facilitate by having a duplicate window parameter.
We have a large number of clients that use Authorize.Net and this is causing us a huge issue.
Is it possible to put it higher in your priority list?
12-10-2020 08:03 AM