Hi @janiv,
Define fixed.
The problem in this thread (as I understand it) is limited to this scenario:
- A call to createCustomerProfileRequest or createCustomerPaymentProfileRequest with a live validation requested will generate an authorization to the card.
- A merchant receives a decline because of an incorrect card code
- Within two minutes, the customer corrects the card code and the merchant resubmits the profile request with all of the same data.
- Our system rejects the transaction as a duplicate transaction with a code 11.
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.
- Use a createTransaction request instead. You can send flags with a transaction request to create a profile from the data in that transaction. If you don't have an initial transaction to charge, set the request to be authOnly, amount for $0.00 (or $0.01, depending on processor), and duplicateWindow to whatever you want. If the transaction fails, a profile is not created, and if it succeeds, the profile information is returned in the response. (Note: this only creates a new profile. It doesn't create a new payment profile under an existing profile.)
- Validate the card separately - You can do a createTransaction call for an authorization for $0.00 (or $0.01, depending on processor), with whatever duplicateWindow you want. If that's successful, move on to creating the profile without the profile doing validation
- Change the <merchantCustomerId> - Customer ID is one of the fields checked for duplicate transactions. When creating a profile using createCustomerProfileRequest , <merchantCustomerId> gets mapped to the customer ID that's sent with the validation transaction. If the validation transaction fails and needs to be resubmitted right away, you can change <merchantCustomerId> to a new value. (Note: this wouldn't work when adding a new profile to an existing payment profile since the <merchantCustomerId> would have already been set on creation of the profile. Of course, you could send an update request to update the <merchantCustomerId> in the profile between the first failure and the resubmission, but that's a little silly. This also would assume you haven't already keyed the first <merchantCustomerId> that you sent to something in your database, or else you'd have to update there as well.)
- Use or embed our Accept Customer hosted forms to allow the customer to add or update their own information.
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.
