We have an error popping up from time to time when using Square that results in the charge failing. Looking into it more closely and speaking with Square, it sounds like an easy fix:



For Reference
https://developer.squareup.com/docs/build-basics/common-api-patterns/idempotency

Oh, wow. So the problem is bigger than I thought.

The issue hit us twice in a row today. The customer's payment failed. Tried again on a different site, also failed.

We logged into the admin in Square so we could see the error code on the transaction and in BOTH cases, the payment failed because the "idempotency" key had already been used before. In the admin it's listed as the "Auth code". In one case the key was used a month prior on a completely different order.

It looks like the keys that the ECT generates are not entirely unique. Anytime that happens, the payment fails. I assume this is a fairly easy fix, but it's also probably a somewhat urgent fix as the customer is only told that their payment failed and may give up on their order (we ran a report to see that that has happened to us several times)

This may also be the problem I am seeing with failed square payments.
Thanks,
David

Hi Graham, Dave
I started along these lines...

quote:

---

One common way to do this is to use some date/time component as the seed for generating your key. This will ensure that you don't ever end up with repeated values.

---

And have extended the idempotency key using the date and the changes for this are now in the updater in the incfunctions.asp file.
But thinking about it, I'm really not sure this is the problem here. This for instance...

quote:

---

The issue hit us twice in a row today. The customer's payment failed. Tried again on a different site, also failed.

---

I mean, the original key would have something like 2^64 possibilities. The changes that this failed on two computers is like 2^64*2

quote:

---

In the admin it's listed as the "Auth code".

---

But this isn't the idempotency key that we send, so maybe this is the problem? Can we dig a bit deeper and possibly get Square to send more details about the value of the idempotency key?

Vince

Click Here for Shopping Cart Software
Click Here to sign up for our newsletter
Click Here for the latest updater

I see. That's odd. I'll apply the changes now and I'll reach out to them to see if they can explain the difference between the idempotency keys and that auth code we have saved in the db after a payment is completed.

Thanks for the quick work. I'll report back.

I implemented the change and didn't run into an error on the test transaction (yay so far)

Vince, it is possible (I dont know how exactly this is used, so I dunno) that the imdempotency may want to run TIME as well as year, month, day. I dont know this for certain, but I THINK I may have previously had this error when a customer clicked the "process order" button more than once.

Vince, a bit of followup. Square allows us to check, via their admin panel, the error codes that any transaction throws in the last 30 days.

In the last 30 days I have that specific error code thrown 74 times, so potentially a much more common issue.

I will followup in 7 days time to let you know if that error has STOPPED, REDUCED, CONTINUED when compared to that previous rate. Here's hoping reduction! Thanks again for your help on that.

Dave, if you want to check your own Square admin panel, I can send you an image of what to look for. Hit me up via email and I'll send that over to you: dst.graham AT gmail DOT com
It would be interesting to see if I'm the only person having the issue.

Email sent Graham. Thanks.

quote:

---

In the last 30 days I have that specific error code thrown 74 times, so potentially a much more common issue.

---

There is a function to create the Idempotency Key which I tried just calling 6 times in a row, one right after another, and each time results in a different key. And I don't believe that it's possible to get 74 clashes just by chance. But let's see what happens and we can follow up when we know the effect the changes have had.

Vince

Click Here for Shopping Cart Software
Click Here to sign up for our newsletter
Click Here for the latest updater

I was able to find in the developer tools, the responses to failed payments.

I am seeing this on some of them



and this



I am past due for an update and my wife and I have been undergoing a huge remodel of our home while we live in a 5th wheel camper parked next to the house. After about 10 months, the contractor(s) are about done. We have just moved back in while things are wrapping up. Now that I have my main workstation setup again, I can get some work done, including the past due update to my store.

Those are the same errors we are getting. As far as I know, since updating that function we haven't had another error yet. I'm holding off until after the weekend to really get my hopes up, but it looks like a good chance Vince sorted it out.

It would be great if the cvv and address verification showed Y or N as was the case with paypal payments, instead of 0 or 1.

Additionally it would be brilliant if the event log showed failed payment attempts, as was the case with paypal direct, but in addition if we could get the reason there.
It does seem this info is available in the response.

Thanks,
David

Hey Vince, we still have zero of those errors in our log since the update. Looking pretty good that this was a fix to a problem.

I'll check in again in a week or so.

Finally updated and this is looking much better.

The API logs are really helpful and we only had a few failed payments and all of them were customer input issues - mostly cvv incorrect.

Thanks to Graham for finding this and Vince for taking action.

David