topic Re: Duplicate transaction with createCustomerPaymentProfileRequest in Integration and Testing

Duplicate transaction with createCustomerPaymentProfileRequest

bepoteat — Wed, 09 Jun 2010 21:31:14 GMT

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.

Re: Duplicate transaction with createCustomerPaymentProfileRequest

RaynorC1emen7 — Wed, 09 Jun 2010 23:09:08 GMT

Did you try passing x_duplicate_window in the extraOptions?

Re: Duplicate transaction with createCustomerPaymentProfileRequest

bepoteat — Wed, 09 Jun 2010 23:34:11 GMT

Yes. Not only is not stated as valid for that request, but I tried passing it in extraOptions, and I got an error.

I forgot to mention that this also happens with updateCustomerPaymentProfileRequest.

Re: Duplicate transaction with createCustomerPaymentProfileRequest

Trevor — Tue, 15 Jun 2010 21:23:35 GMT

We don't currently have a workaround for this beyond waiting 2 minutes between updates. However, our developers have discussed this issue as recently as last week and are looking into disabling the duplicate window by default for all CIM requests other than createCustomerProfileTransaction. I can't make any promises on a timeline, but hopefully this is something that we will be able to resolve for you.

Re: Duplicate transaction with createCustomerPaymentProfileRequest

deviantintegral — Thu, 09 Jun 2011 12:39:59 GMT

Sorry to resurrect an old thread; is this still a known issue? I think I'm running into this problem as well.

Re: Duplicate transaction with createCustomerPaymentProfileRequest

weishijian — Fri, 17 Aug 2012 06:12:32 GMT

the createCustomerPaymentProfileRequest has extraOptions parameter?

Re: Duplicate transaction with createCustomerPaymentProfileRequest

Rob_vH — Tue, 26 May 2015 15:16:04 GMT

How about now?
We are experiencing this issue and it's 2015.

We need to allow correcting mis-typed card codes. Since PCI DSS requirements do not allow you to store the card code, whenever this is the only thing that changes on a request, the request will always look like a dupliate. The result is a very customer jolting experience -- the last thing we want during checkout.

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.

How can we approach this issue? Why can't we disable or shorten duplicate timeout on createCustomerPaymentProfileRequest?

How do you suggest we approach this? Telling the customer to wait 2 minutes after correcting a mistyped card code is off the table.

Rob

Re: Duplicate transaction with createCustomerPaymentProfileRequest

RichardH — Tue, 26 May 2015 15:22:51 GMT

Hello @Rob_vH

Let me do some research on this issue.

I'd recommend subscribing to this topic so that you'll be alerted via email if there are updates. To subscribe, click Topic Options at the top of this thread and then select Subscribe. You'll then receive an email once anyone replies to your post.

Richard

Re: Duplicate transaction with createCustomerPaymentProfileRequest

Rob_vH — Tue, 26 May 2015 15:29:34 GMT

Just for reference, I've tried setting a unique refId on each call to createCustomerPaymentProfileRequest, but bizarrely, Authorize.net still mistakenly believes the two attempts to be duplicates.

Rob

Re: Duplicate transaction with createCustomerPaymentProfileRequest

Joy — Tue, 26 May 2015 16:33:03 GMT

Hi Rob,

It is important to know that refID is not validated anywhere this is why changing this value will not resolve the issue you are getting with the error E00039 due to duplicate payment profile. When running the API call for createCustomerPaymentProfileRequest the fields below are validated. You can also check page 112 of the CIM guide for reference.

customerProfileId
cardNumber
accountNumber
routingNumber
billToFirstName
billToLastName
billToAddress
billToZip

Thanks,

Joy

Re: Duplicate transaction with createCustomerPaymentProfileRequest

Rob_vH — Tue, 26 May 2015 19:54:43 GMT

Joy:

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.

Rob

Re: Duplicate transaction with createCustomerPaymentProfileRequest

Rob_vH — Wed, 27 May 2015 19:58:27 GMT

@RichardH

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

Rob

Re: Duplicate transaction with createCustomerPaymentProfileRequest

RichardH — Wed, 27 May 2015 20:27:37 GMT

@Rob_vH

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

Richard

Re: Duplicate transaction with createCustomerPaymentProfileRequest

Rob_vH — Wed, 27 May 2015 20:37:45 GMT

@RichardH

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?

Re: Duplicate transaction with createCustomerPaymentProfileRequest

RichardH — Wed, 27 May 2015 21:09:17 GMT

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

Richard

Re: Duplicate transaction with createCustomerPaymentProfileRequest

npiasecki — Wed, 27 May 2015 21:43:14 GMT

@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 http://community.developer.authorize.net/t5/Ideas/CIM-Return-duplicate-payment-profile-ID-during-E00039-error/idi-p/49159

Re: Duplicate transaction with createCustomerPaymentProfileRequest

Rob_vH — Fri, 29 May 2015 15:56:02 GMT

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

Re: Duplicate transaction with createCustomerPaymentProfileRequest

RichardH — Fri, 29 May 2015 16:29:11 GMT

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

Richard

Re: Duplicate transaction with createCustomerPaymentProfileRequest

Rob_vH — Fri, 05 Jun 2015 13:47:00 GMT

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

Best,

Rob

Re: Duplicate transaction with createCustomerPaymentProfileRequest

Rob_vH — Fri, 12 Jun 2015 19:55:27 GMT

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