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 for your reply, however, unfortunately your reply does not address my request. I am aware of which fields are being compared to determine duplicates, already. That does not tell me how Authorize expects us to handle the extremely resonable and common case of having a customer correct an incorrect card code. The only data we can change is the card card. 


So when changing only the card code, how can we prevent the CIM API from erroneously preventing our users from completing checkout due to a false duplicate assumption when calling createCustomerPaymentProfileRequest?


We believe strongly that the use case we are presenting is both common and reasonable; but is not properly handlable given the way the API works. We want to disable the undesirable/unneeded/unwanted duplicate detection check or be provided with an override method. createCustomerPaymentProfileRequest should accept/respect the x_duplicate_window extraOptions setting. Currently there is a bug because it does not.






Has your research borne fruit? I've got heat on me from above to get this issue solved.





We've confirmed the issue remains, and unfortunately I don't have any time line for a solution.




That's certainly unfortunate. 


How agile is the development group there? Are they protected by red tape and dozens of managment approval levels or can they take support tickets from reasonably sized clients and implement solutions to them? We can't be passive about this.  Can you suggest an approach? 


We are escalating this now, we'll get back to this thread as soon as we have better information.



@rob_vH ... the problem is Authorize.Net built a profile management system when they needed a tokenization system like the PayPal Vault or Stripe, and then tried to sell it as a tokenization system anyway. They haven't fully admitted this mistake to themselves yet.


The best workaround I have come up with is to use a unique customerProfileId for each and every transaction your system creates, such as a GUID, and track these as simply two pieces of Authorize.Net metadata in your database instead of just one, essentially moving the layer of abstraction up another level and moving it into the control of your application.


I have requests on CIM regarding the E00039 issue from

2009 (six years, mind you!), so don't hold your breath. Feel free to upvote

Regular Contributor

@npiaseckiHaving used both schemes in my employement at various merchants, I can say I prefer the profile system because it greatly empowers handling months-ahead pre-orders and backorders. I somewhat like payment profiles for this reason.


The only problem is that they create false-positives for duplicate transaction when, during payment profile creation fails due to card code input incorrectly and then the user attempts to correct without waiting (way too long) 2 minutes.  All they have to do is duplicate their logic for extraOptions x_duplicate_window allowing us to tweak or override this superfluous feature when we don't need/want it.


As to your criticism, that seems really exasperating. This flaw is a deal-breaker for us so I hope they are more responsive with this issue than the one you've been waiting months/years on. If not then they will lose us as a client. Maybe they don't care about that; we probably are not their biggest client and I know they have many. But we do process 6 or maybe 7 figures annually; I hope that matters to them.  I guess we'll see.


@RichardH what is the most efficient way to track the status and progress on this issue? Is there anything we should do formally to push it? I have to report on this in our morning standups and weekly reviews with management. 


@Rob_vH I've recorded this issue in our tracking system, and it's tied to this community thread.  When there are updates, we'll post them here.


In the meantime, @brianmc our API product owner offered an alternative solution:


We recently enhanced createTransactionRequest to both perform a transaction AND create a profile at the same time.  If the transaction was unsuccessful, ie incorrect CCV, a profile is not created and the error is returned immediately.  This may require some coding on your part, but it does offer the functionality you desire today.





@brianmc Okay, how is that different from the behavior of createCustomerPaymentProfile? When the CCV is incorrect, it immediately returns and does not create the payment profile. Is the difference that the duplicate window setting is understood and honored by createTransactionRequest and not by cCPP? If that is the case, then I understand what you're getting at. Further in the same case, is there a way to get around the fact that when the card is being used to create a payment profile, we very well may have no transaction to create?  Either way, yes, this would take some significant changes to our software. My concern is that when I search, there are clearly lots of people frustrated by this and coming up with varioius hacky solutions to get around the API's shortcoming, but it really really seems like a < 1 day request for a single programmer. Like, it should be literally 2-5 lines of code in your service model; and you already have it on other service calls, so you clearly already have a tested solution. All you need is an update and integration testing. So what gives? It's a standing problem. Nobody thinks it's "ok." It makes your API look bad. It should have just been fixed 5 years ago.  There is clearly a lack of push on this issue. What motivates you to complete changes?






@brianmc @RichardH 

Hi Brian and Richard, 


It's been another week on this issue and we have code moving down the pipeline toward production that needs this fixed in order to go live. How are we doing there guys? Is there some progress to report?