cancel
Showing results for 
Search instead for 
Did you mean: 

Duplicate transaction with createCustomerPaymentProfileRequest

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.

 

bepoteat
Member
23 REPLIES 23

@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.

Hi, it's 2017. Is this still not fixed?

janiv
Member

Hi @janiv,

 

Define fixed.

 

The problem in this thread (as I understand it) is limited to this scenario:

  1. A call to createCustomerProfileRequest or createCustomerPaymentProfileRequest with a live validation requested will generate an authorization to the card.
  2. A merchant receives a decline because of an incorrect card code
  3. Within two minutes, the customer corrects the card code and the merchant resubmits the profile request with all of the same data.
  4. 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.

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?