spoon-token-duplicate | Stripe Developers | Page 1

raw ruinBOT Jul 24, 2023, 3:56 PM

#

dim forum Jul 24, 2023, 3:56 PM

#

Hello! Give me a few minutes to take al ook

#

It looks like in this specific case, the token was initially used for for this request (req_ccMKq1sPyWte2q - which declined). Then, you tried to use the same token again resulted in the error (as expected)

mellow vortex Jul 24, 2023, 4:13 PM

#

but I didn't. That's the issue!

#

It never returned the decline the first time, just this duplicate token error, but it DID actually process the decline (and I've had the same thing happen with successful payments)

dim forum Jul 24, 2023, 4:17 PM

#

Hmmmm... let me double check something

#

Ah, I see what you're saying (and now I see why you mentioned disabling the button upon click) - your current theory is that these are two button clicks resulting in your server (that calls /v1/payment_itnents ) being called twice

mellow vortex Jul 24, 2023, 4:25 PM

#

originally, yes, that was my thought...thought...each button click SHOULD still produce a new stripe token, so not really sure about any of this right now

#

but even with a "perfect" single click, controlled by developers that know they are NOT sending multiple requests, I still have this error quite a bit - but no always, which is why it's so weird

#

(and JS to disable the button...it's NOT a double-submit issue)

#

It's like the try: thinks it's failing, but it actually worked! ?????

#

I don't know...this is so weird and seems to be on Stripe's end, but I don't know. I'm calling the Stripe.js to do the work - and a simple python script on the backend processes the most basic direct charge...

#

the bad part is this is happening now that we implemented...so out LIVE systems are offline while we test and try to figure this all out

#

I need a quick solution, or I need to consider pulling Stripe altogether and reverting the customer's entire enterprise back to their old payment provider

#

this is REALLY quite a problem, because we didn't really notice it but once or twice during development...but now that it's implemented, it's happening like 40-50% of the transactions at times

dim forum Jul 24, 2023, 4:36 PM

#

The only real quick solution I can think of is using a idempotency key (https://stripe.com/docs/api/idempotent_requests) to de-dupe these requests

#

And if you haven't already, I'd add logging to see if you can track when these double clicks are actually happening

mellow vortex Jul 24, 2023, 4:44 PM

#

they aren't doubleclicks - i confirmed that

#

they are just random dup token errors immediately following sucessful transactions...it's not creating addition, new transactions

dim forum Jul 24, 2023, 4:51 PM

#

And you're 100% sure you're not making a request to stripe more than once?

#

Also just want to double check something - do you have automatic retries enabled? https://github.com/stripe/stripe-python#configuring-automatic-retries

mellow vortex Jul 24, 2023, 5:03 PM

#

Not making more than one request

#

there;s only like 75 lines of code in the whole backend, and the stripe call is simple, no parrellell, nothing like that

#

I added Idempotency keys manually, and it changed NOTHING

#

now I'm trying seeing the retries

#

(automatic retries which handle Idempotency keys internally, according to the docs)

#

I added the stripe.max_network_retries = 2

Still getting this EVERY time:

Request req_JtVoVPEwdvrCoE: The token tok_1NXSCHDPB9GZZ8S3TCuDvtfl has already been used. Each token can only be used once to create a source.

And this was a BRAND NEW transaction, created from a link

#

no matter what I do I just keep getting these stupid duplicate token errors even though I;m using the stripe.JS exactly as recommended - and SOMETIMES it works just fine. It's also happening like 80% of the time in FF, and less so - though still too often - in Chrome

raw ruinBOT Jul 24, 2023, 5:09 PM

#

grizzled vapor Jul 24, 2023, 5:09 PM

#

spoon-token-duplicate

#

@mellow vortex the network retry is unlikely to be related if you use idempotency properly

mellow vortex Jul 24, 2023, 5:10 PM

#

stripe.js is the one returning the token and i pass that, so no clue, but this is absolutely maddenning - we NEVER had anything like this with other payment systems...Stripe is THE MOST DIFFICULT time I've ever had implementing payments, and I've implemented a LOT of payments - NTOHING WORKS AS ADVERTISED here.

#

And that should only impact network issues...this is NON-STOP

grizzled vapor Jul 24, 2023, 5:11 PM

#

It looks like you are really making 2 separate requests to use that Token. One is declined and the next one is explicitly rejected because you already used that Token id.
If you add logs to your server-side code you should see yourself calling that API twice

mellow vortex Jul 24, 2023, 5:11 PM

#

it's like it's caching the tokens or something

#

I absolutely don't

grizzled vapor Jul 24, 2023, 5:11 PM

#

I mean you do, it's right there

#

What are you really doing? Tokens tok_123 have been deprecated for years

mellow vortex Jul 24, 2023, 5:12 PM

#

I will share my code...it's SO simple... one call - success and redirect, or decline and redirect....

#

huh?

#

what are you asking me?

grizzled vapor Jul 24, 2023, 5:13 PM

#

You seem to be building some brand new integration and being lost. I'm asking what exactly you're trying to do and which exact doc you are following to make this happen? Your code seems to create a Token tok_123 client-side in Javascript which is uncommon for newer integrations as this path has been replaced with a newer one for years now

mellow vortex Jul 24, 2023, 5:13 PM

#

Let me put it this way... I didn't right any code that calls it twice

#

If it's happening, it's not my code doing it

grizzled vapor Jul 24, 2023, 5:13 PM

#

It is though

mellow vortex Jul 24, 2023, 5:14 PM

#

LOL Ok

grizzled vapor Jul 24, 2023, 5:14 PM

#

I get you're frustrated clearly, and I'll help you figure it out, but it's importnat to get this is 100% your code

mellow vortex Jul 24, 2023, 5:14 PM

#

in what way, though?

#

i mean, it's one short file with ONE call

grizzled vapor Jul 24, 2023, 5:14 PM

#

The first step is to add clear logs to your server-side code in Python where you call the Create PaymentIntent API https://stripe.com/docs/api/payment_intents/create. This API is passing the Token id tok_123. If you can add a clear log before that call you'll see it's called twice

mellow vortex Jul 24, 2023, 5:14 PM

#

there's one single payment intents call...that's it - one try: block

grizzled vapor Jul 24, 2023, 5:15 PM

#

My guess: you have a problem in your JS code, the part that sends the Token tok_123 to your server and that is calling it twice

mellow vortex Jul 24, 2023, 5:15 PM

#

where are you seeing this tok_123?

#

I'm just getting the toekn from the JS as supplied straight from the documentation

#

and it acts differently depending on the brownser

#

NOTIBLY different

#

FF gets this error non-stop, while Chrome works without any error about 50-60% of the time

#

see, that's the thing...I don't ALWAYS get the error

grizzled vapor Jul 24, 2023, 5:17 PM

#

Sure, because it's a bug in your JS. Please try to do what I said. Let's leave the frustration on the side for a little bit. Add clear logs to your python code first.

mellow vortex Jul 24, 2023, 5:17 PM

#

what do you want me to log?

#

EXACTLY

grizzled vapor Jul 24, 2023, 5:18 PM

#

no need to yell, I'm helping you

#

Before calling the Create PaymentIntent API https://stripe.com/docs/api/payment_intents/create you would add any log that shows the parameter(s) you are passing and that you're calling that API.

mellow vortex Jul 24, 2023, 5:21 PM

#

Here is the JS that creates the token:
event.preventDefault();

  stripe.createToken(cardElement).then(function(result) {
    if (result.error) {
      // Log the error message and re-enable the submit button
      console.error(result.error.message);
      submitButton.disabled = false;
    } else {
      // Append the token to the form data
      var hiddenInput = document.createElement('input');
      hiddenInput.setAttribute('type', 'hidden');
      hiddenInput.setAttribute('name', 'stripeToken');
      hiddenInput.setAttribute('value', result.token.id);
      form.appendChild(hiddenInput);

      // Submit the form
      form.submit();

#

Top of file: <script src="https://js.stripe.com/v3/"></script>

#

I have 8 minnutes before I have to revert 😦

grizzled vapor Jul 24, 2023, 5:24 PM

#

We won't resolve this in 8 minutes really

mellow vortex Jul 24, 2023, 5:28 PM

#

I know

#

The log file shows this:

#

Stripe Token: tok_1NXSYKDPB9GZZ8S3gi0SqLzW
Stripe Token: tok_1NXSYKDPB9GZZ8S3gi0SqLzW

#

I'm going to try another one...

grizzled vapor Jul 24, 2023, 5:29 PM

#

Okay so clearly you see your code is called twice now!

#

So the next question is why. I'd recommend looking at the logs of your server: how many times is that "route" called, the thing that triggers this call

mellow vortex Jul 24, 2023, 5:30 PM

#

Next call was:

#

Stripe Token: tok_1NXSa9DPB9GZZ8S341I17A77
Stripe Token: tok_1NXSa9DPB9GZZ8S341I17A77

#

My JS front end calls it

#

Now this is CRAZY!!!

#

I just used Chrome instead of FF

#

Stripe Token: tok_1NXSbuDPB9GZZ8S3QIlKjHth

#

Got a proper Decline

#

And no duplicate

#

NOT MY CODE

grizzled vapor Jul 24, 2023, 5:32 PM

#

I mean 100% your code

#

and please STOP YELLING

mellow vortex Jul 24, 2023, 5:33 PM

#

I'm not yelling. I'm typing.

grizzled vapor Jul 24, 2023, 5:33 PM

#

in caps, because you are frustrated, which on the internet means yelling. I'm a human trying to help you here and I'm asking you to try and work with me patiently without yelling

#

It's almost always due to some JS that isn't written properly and so in Chrome it just ignores and Firefox it doesn't. It's common when you use logic that isn't really browser compliant for example or when you have the same "event handler" registered twice (which not all browsers handle the same way)

#

What I'd recommend now is to add logs to your JS code to figure out if your form submission might be called twice

mellow vortex Jul 24, 2023, 5:34 PM

#

I don't agree with that "caps are yelling" BS - caps when used sparingly are to highlight a point, like bold or <strong>

grizzled vapor Jul 24, 2023, 5:37 PM

#

Sure, but to me (and most people in the internet) it means yelling so I'm asking you to avoid it if possible

mellow vortex Jul 24, 2023, 5:38 PM

#

That's stupid. Now youre just being petty.

#

Don't help me if you don't want to. But DO NOT lecture me.

grizzled vapor Jul 24, 2023, 5:40 PM

#

I'm helping you, I already showed you where the problem comes from despite the tone and back and forth.

#

Again I get you are really frustrated, bugs like this are really annoying to narrow down and debug. All I'm asking you is to work with me and not use all caps

#

Have you been able to add a console.log() near your form.submit() call to see if it's called twice?

mellow vortex Jul 24, 2023, 5:57 PM

#

Yes.

#

Submitted once. Not twice.

#

Even in FF

grizzled vapor Jul 24, 2023, 5:57 PM

#

Okay next step is to look at the Network tab in the developer tools and see if you see 2 separate requests hitting your server

mellow vortex Jul 24, 2023, 6:00 PM

#

single post to my backend

#

(according to the network tab in FF in dev tools at the bottom)

#

I see multiple calls to stripe, but only one to my backend, nd one redirecting back to the front end ot deliver the error about duplicate tokens

#

all logging and console is showing one and only one request when i submit

grizzled vapor Jul 24, 2023, 6:04 PM

#

Okay so then the next step is to figure out why you get the log you added earlier twice. If this doesn't come from your front-end then I'm not really sure what it could be yet. I'd recommend adding a log at the root of your route in your server-side code to confirm it's hit twice

#

Do you have a page where we can repro?

mellow vortex Jul 24, 2023, 6:11 PM

#

It's hit twice

grizzled vapor Jul 24, 2023, 6:11 PM

#

like you need to check this option in Firefox to see all the logs

#

have you enabled that option?

#

My guess is that you forgot return false; in your event handler

mellow vortex Jul 24, 2023, 6:12 PM

#

I planted a log at the top of the py script, and it's hitting twice from FF (not Chrome) but FF only shows one call in the console and looking at it, it's not calling twice

grizzled vapor Jul 24, 2023, 6:13 PM

#

yeah did you enable the option I said above?

#

It's either return false; in the handle or https://developer.mozilla.org/en-US/docs/Web/API/Event/stopImmediatePropagation maybe

#

If you could share your exact code for the event handler (you didn't show where it was called) I might be able to stop something else

mellow vortex Jul 24, 2023, 6:14 PM

#

It's small. I can give you the full page

#

I'm not a JS dev AT ALL btw...

#

I'm just folloI've a backend dev by trade...frontend is NOT my bag...

grizzled vapor Jul 24, 2023, 6:21 PM

#

No worries. I'd recommend to try the 3 separate things I advised above first
1/ Make sure you enable the "Persist logs" options in developer tools
2/ Add return false; to your event handler
3/ Add stopImmediatePropagation() to your event handler https://developer.mozilla.org/en-US/docs/Web/API/Event/stopImmediatePropagation

mellow vortex Jul 24, 2023, 6:23 PM

#

were is the persist logs option. i don't see it.

Also, here's my log results from JS...looks like 1 run:
Stripe token creation callback invoked. pay-for-training:237:17
Stripe token creation successful. Submitting form. pay-for-training:243:19
Submitted. pay-for-training:253:19

grizzled vapor Jul 24, 2023, 6:24 PM

#

grizzled vapor like you need to check this option in Firefox to see all the logs

here

#

#

this is a screenshot from Firefox developer tools

mellow vortex Jul 24, 2023, 6:27 PM

#

I see nothing like that

grizzled vapor Jul 24, 2023, 6:29 PM

#

mellow vortex Jul 24, 2023, 6:30 PM

#

I see nothing like that. I'm on Windows and my interfact is entirely different

#

I don't even see an option like that anywhere

grizzled vapor Jul 24, 2023, 6:31 PM

#

I can't really tell unfortunately, this part you'll need to figure out where it is in your UI on Firefox. It's inside Developer Tools on the Network tab

mellow vortex Jul 24, 2023, 6:32 PM

#

got it thx

#

so what are we looking for here?

#

I still see just one call from the front end

#

I added return false ,etc. same behavior

grizzled vapor Jul 24, 2023, 6:35 PM

#

I don't know exactly what we're looking for here. We're fishing mostly to try and figure out why your route is called twice from Firefox

mellow vortex Jul 24, 2023, 6:41 PM

#

It's only showing once in all of the logs and everything EXCEPT on the backend where it's clearing invoking twice, but only from FF - mostly

#

Nothing in the network nor the logs seems to be a clue

grizzled vapor Jul 24, 2023, 6:42 PM

#

Have you found the option I discussed in Firefox? Because if not right now we don't really have a way to guarantee that which is what I'm helping you figure out

mellow vortex Jul 24, 2023, 6:42 PM

#

yes

#

I enabled it

#

I can see everything in the logs and network

#

persisted

#

there's nothing there showing dup sends

grizzled vapor Jul 24, 2023, 6:43 PM

#

Okay is there any way for you to give me access to a URL where I can reproduce?

mellow vortex Jul 24, 2023, 6:43 PM

#

sure

#

use this for now:
https://nemt.gentechassociates.com/pay/?order_code=C9DN1690176961

#

The code is a bit of a mess right now, because I've been "trying" stuff suggested, but I'm no JS dev, so...

#

oh wait

#

you won't be able to access, because LIVE system is in maintenance

#

give me a few

#

I have to revert a few things, but I can make it sort of work

#

hang on...

raw ruinBOT Jul 24, 2023, 6:45 PM

#

mellow vortex Jul 24, 2023, 6:48 PM

#

Ok, you can try it now

#

I opened things up a bit...

#

https://nemt.gentechassociates.com/pay/?order_code=C9DN1690176961

GenTech NEMT Training

Processing Payment Link Request…

grizzled vapor Jul 24, 2023, 6:49 PM

#

for what it's worth I just hit the error on Chrome

#

so it's definitely not just Firefox

mellow vortex Jul 24, 2023, 6:50 PM

#

Ok, well that's good'ish. (I've been "getting thru" on Chrome - proper declines mostly, but SOMETIMES I get a Chrome error, too.)

#

I also may have broken tuff playing around adding in those event.stopImmediatePropagation(); here and there and return false to be sure

#

so i don't know....it's a big mess compared to where i started (and at one time in dev, we weren't getting all of these duplicate errors - that started later in the game...)

grizzled vapor Jul 24, 2023, 6:55 PM

#

yeah I agree I don't see 2 requests client-side so it must be something in your server-side code, maybe during the redirect?

#

I have to run but I gave a summary to @inland forge from my team who is taking over.

mellow vortex Jul 24, 2023, 6:56 PM

#

maybe, but then why not all of the time? and most always in certain brownsers?

#

?

#

ok

inland forge Jul 24, 2023, 6:56 PM

#

Hey there, just poking at this i suspect its happening server side also, in whatever handles https://svr1.enterdark.com/cgi-bin/process_nemt_payments.py

mellow vortex Jul 24, 2023, 6:56 PM

#

thank you

inland forge Jul 24, 2023, 6:56 PM

#

Since thats the only request where i see the tok_123 passed

mellow vortex Jul 24, 2023, 6:56 PM

#

old school PyCGI

#

everytime i call it from FF on my end, I get the dup error and my logs show two hits

#

tok_1NXQXIDPB9GZZ8S3G9HbJZYJ
tok_1NXQXIDPB9GZZ8S3G9HbJZYJ

for example

#

but when i call from Chrome, I get one:

like just...

tok_1NXQXIDPB9GZZ8S3G9HbJZYJ

#

for example

#

though, SOMETIMES it breaks from Chrome, too. But it almost ALWAYS breaks in FF

inland forge Jul 24, 2023, 6:58 PM

#

my logs
which logs, specifically

#

Client/browser logs, or server logs?

mellow vortex Jul 24, 2023, 6:59 PM

#

server logs

#

manually logged to a .txt file

#

when it gets called from FF, my log shows two. From Chrome, one. But all network and console tracking front end shows only one proper call each time

#

frontend FF dev tools also show only one call

#

Here's the history...you can see mostly dups, but SOMETIMES it gets a single one properly:
Ping: NOW
Stripe Token: tok_1NXTCRDPB9GZZ8S3wHM5xVEK
Ping: NOW
Stripe Token: tok_1NXTCRDPB9GZZ8S3wHM5xVEK
Ping: NOW
Stripe Token: tok_1NXTNLDPB9GZZ8S3pRsAMY2f
Ping: NOW
Stripe Token: tok_1NXTNLDPB9GZZ8S3pRsAMY2f
Ping: NOW
Stripe Token: tok_1NXTVcDPB9GZZ8S3UJNUyxe2
Ping: NOW
Stripe Token: tok_1NXTVcDPB9GZZ8S3UJNUyxe2
Ping: NOW
Stripe Token: tok_1NXTZKDPB9GZZ8S3ga5GKY0x
Ping: NOW
Stripe Token: tok_1NXTZKDPB9GZZ8S3ga5GKY0x
Ping: NOW
Stripe Token: tok_1NXTaBDPB9GZZ8S3Z1V1AuYl
Ping: NOW
Stripe Token: tok_1NXTaBDPB9GZZ8S3Z1V1AuYl
Ping: NOW
Stripe Token: tok_1NXTgADPB9GZZ8S3D1ODRLlG
Ping: NOW
Stripe Token: tok_1NXTgADPB9GZZ8S3D1ODRLlG
Ping: NOW
Stripe Token: tok_1NXToKDPB9GZZ8S3l3uhmnLQ
Ping: NOW
Stripe Token: tok_1NXToKDPB9GZZ8S3l3uhmnLQ
Ping: NOW
Stripe Token: tok_1NXTpRDPB9GZZ8S3654i4b7T
Ping: NOW
Stripe Token: tok_1NXTqUDPB9GZZ8S317ftpMI0
Ping: NOW
Stripe Token: tok_1NXTr9DPB9GZZ8S3MSBcNZHC
Ping: NOW
Stripe Token: tok_1NXTs2DPB9GZZ8S3bRy7Nq9L
Ping: NOW
Stripe Token: tok_1NXTsbDPB9GZZ8S3pE6A7qEn
Ping: NOW
Stripe Token: tok_1NXTsbDPB9GZZ8S3pE6A7qEn
Ping: NOW
Stripe Token: tok_1NXTt9DPB9GZZ8S3X2C3UFAt
Ping: NOW
Stripe Token: tok_1NXTt9DPB9GZZ8S3X2C3UFAt
Ping: NOW

#

Those logs are pasted from the server...in-code logging

inland forge Jul 24, 2023, 7:02 PM

#

What client side call leads to this?

#

The first time i went through it, I got the error. The last two times i tried, i was redirected to a success page.

#

Hmm when i go back from the success page, I'm seeing the url extended with a bunch of query parameters

#

Is it possible you're redirecting to add some params before the success page, and a race condition determines whether that gets submitted as another payment attempt vs getting to the redirect page?

mellow vortex Jul 24, 2023, 7:10 PM

#

No. I only redirect back to the payment form on Error. On success, I redirect to a basic success page with no need for fluff. (And for the error page, the querystring params are just for display. Everything is verified against the database for things like the order_code and proce matching, etc.)

#

I just looked - the backend script is really simple and short...just two redirects possible. one at the end of the try block, and one at the end of the exception block

#

(and they redirect as described above)

#

what do you mean "what client side call leads to this?" The payment form submits in a "typical" fashion to the backend upon clicking the button. We use the stripe.js to tokenize, etc. and everything seems to work fine...except for this double processing that seems brownser dependent...sometimes.

#

(And I'm a backend, not frontend dev, so JS is not my thing at all...this was all done from docs, gpt, stackOverflow, and winging it, but it WA working...just the dups started showing up late in the game...)

inland forge Jul 24, 2023, 7:18 PM

#

I guess i mean how does the client code / browser make that server request, and have you confirm there are in fact two requests?

#

Have you logged at the server request handler level? Do you generate IDs for requests? You could add timestamps, or do that client side as a crude check.

#

If there are two requests, are they both POST requests? Is it possible there's a cors pre-flight OPTIONS request being handled as a POST?

mellow vortex Jul 24, 2023, 7:22 PM

#

ok, it's a straight JS form.submit() to the URL - there is only one call. Everything code-wise that I can see is one call. Everything dev tools-wise for console and network shows one call (and the redirect back, but not a dup call to server) and server side, when i log, I get multiples, but can't track the source. (And I have no clue what 'a cors pre-flight OPTIONS request being handled as a POST?' means...)

#

client side I checked with console logging...not making multiple calls of any sort

#

the reason for the duplicates is a mystery enterily

#

it seems to be originating server side, yet how? the script is just running twice SOMETIMES apparently, and it's almost happening 100% when called from FF, yet it happens periodically, but less, when called from Chrome

#

these are REALLY small, simple scripts that perform arbitrary one-off tasks...there are ZERO frameworks at play here...it's like an 80 line front end and a 50 line backend tops

#

And btw, the same server runs production tasks on the same tech stack all of the time. ONLY this Stripe implementation seems to be having problems, which tells me it's NOT the server. (Tons of Auth.net transactions for another service with ZERO issues, etc.)

inland forge Jul 24, 2023, 7:29 PM

#

For context on CORS pre-flight (but i agree i don't see an options request): https://stackoverflow.com/questions/29954037/why-is-an-options-request-sent-and-can-i-disable-it

Stack Overflow

Why is an OPTIONS request sent and can I disable it?

I am building a web API. I found whenever I use Chrome to POST, GET to my API, there is always an OPTIONS request sent before the real request, which is quite annoying. Currently, I get the server to

mellow vortex Jul 24, 2023, 7:32 PM

#

I'm not seeing anything like that, so no clue.

#

I'm assuming not. Simpe form post.

#

simple

#

and a basic py script to respond on the backend

#

basic cgi - nothing complicated here

#

i do the exact same types of requests all of the time on this server and don't have these issues...not sure whay's going on with stripe, but there are a LOT of requests flying around for stripe on the front end during a transaction, though I can see there is only one all when II clikc the button to the backend py resource

#

any options?? next steps? Been working to get to this point for many months...now were are trying to go LIVE and asic functionlity regarding Stripe os not working. (Client is talking about reverting to old payent processor ASAP - we had no technical problems working with authorize.net - why is Stripe so insanely ugly and complex??)

#

these dup issues just don't make any sense.

#

nothing is showing them as actually being an issue - the forms are apprarently NOT double-submitting, so I have no clue what's going on at this point....I'm truly stuck in the middle of a production launch!!!

inland forge Jul 24, 2023, 7:46 PM

#

I'm still poking at this -- in firefox is definitely more obvious the page gets redirected to itself

mellow vortex Jul 24, 2023, 7:50 PM

#

yes, whenever an error occurs, the page redirects back to itself and passed the error details

#

it happens A LOT more in FF

#

but all frontend tools show single submits (and there is JS to disable button, so can't click multiple times...)

#

I also want to point out that I've been working on troubleshooting this specific issue since about 6 AM this morning when we discovered it in LIVE testing during implementation. We since backed-out certain prod elements, but we need to start making progress. I've been at this since about this time yesterday, so I'm going on like 36 hours with no sleep to make this happen, and it's failing because...Stripe. (Like I said, don't have any issues doing the same thing with authorize.net.) Are we going to get this fixed, or do I have to revert to the old payment processor? I'm seriously running out of time. I already reverted part of the system, because we had our prod systems in maintenance all day....total downtime. I REALLY need some answers, PLEASE!!!

#

I'm just dying here, and I can't keep going much longer, but I NEED resolution before I can stop. This is causing major problems, downtime, and delays.

#

It will redirect a proper DECLINE back to the form and that's fine, but too often it throws a duplicate token error instead of returning proper decline - or redirecting to success page.

inland forge Jul 24, 2023, 7:54 PM

#

I agree the code I can see is not overly complex, and surprised at this result, but so far as I can tell the issue is not specifically related to Stripe (the double submission).

#

Let see if we can come up with another angle here

mellow vortex Jul 24, 2023, 7:56 PM

#

so how come the double submission doesn't show at all on the front end monitoring tools

#

ok

#

listening....

#

(FYI: NO double submit issues with hundreds of other resources running on this server in a similar fashion. this is the ONLY thing that is doing this, but it's also the only thing tokenizing stuff.)

inland forge Jul 24, 2023, 7:57 PM

#

This is two requests in a pair, like this:
First (fine): https://dashboard.stripe.com/test/logs/req_7ofu0pHS2Ne95K
Second (error because the token is re-used): https://dashboard.stripe.com/test/logs/req_pcxNa0ExrJ5pr3

Stripe Login | Sign in to the Stripe Dashboard

Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.

Stripe Login | Sign in to the Stripe Dashboard

Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.

mellow vortex Jul 24, 2023, 8:00 PM

#

each transaction shows a different Idempotency key. using the auto retry is supposed to guarentee the Idempotency of the call...but it certain;y doesn't seem to be.

#

so what is the second call...what's making it?

inland forge Jul 24, 2023, 8:01 PM

#

Your server is, you must be calling this twice, which is the mystery

mellow vortex Jul 24, 2023, 8:02 PM

#

but we KNWO I'm not calling it twice

inland forge Jul 24, 2023, 8:02 PM

#

I was going to suggest a possible patch to get you moving while you keep digging

#

Provide your own idempotency_key with appropriate factors:
https://stripe.com/docs/api/idempotent_requests?lang=python

Stripe API reference – Idempotent Requests – Python

Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.

mellow vortex Jul 24, 2023, 8:02 PM

#

and like i said, nothing else on this server doing EXACTLY the same types or calls has any issue like this. this is a new experience and only started with the introduction of stripe to our environment

#

i did that

inland forge Jul 24, 2023, 8:03 PM

#

Can you share you server code doing that?

mellow vortex Jul 24, 2023, 8:03 PM

#

i started there, and moved over to auto when it did nothing

inland forge Jul 24, 2023, 8:03 PM

#

What was the idempotency key structure?

mellow vortex Jul 24, 2023, 8:03 PM

#

nothing seems to make a difference anymore

#

i used generated_idempotency_key = str(uuid.uuid4())

#

and then in the call, idempotency_key = generated_idempotency_key

inland forge Jul 24, 2023, 8:04 PM

#

But when did you generate that? Cna you share the code around the payment intent call?

mellow vortex Jul 24, 2023, 8:04 PM

#

but it doesn't matter because it's hitting the script a second time apparently, which makes ZERO sense

inland forge Jul 24, 2023, 8:04 PM

#

mellow vortex i used generated_idempotency_key = str(uuid.uuid4())

This reinforces that your server endpoint is processing twice

#

So what i was going to suggest is something less random to diagnose/test

mellow vortex Jul 24, 2023, 8:05 PM

#

I ripped it out - not using idempotency key changed to auto retry (=1) which docs say guarentees idempotency on its own

inland forge Jul 24, 2023, 8:06 PM

#

You're misunderstanding those docs -- the retries (after 1) will use idempotency key to prevent duplicate actions

mellow vortex Jul 24, 2023, 8:06 PM

#

the amount of "doube hitting" is brownser sensitive though, which leads me to believe it is indeed something initiated by the client that is causing it

#

that's what I'm tryint to do

inland forge Jul 24, 2023, 8:06 PM

#

Instead of UUID, use something like orderid_tokenid

mellow vortex Jul 24, 2023, 8:06 PM

#

the first action seems to be right

#

it's the follow-up/mysterious SOMETIMES second execution that is blowing my mind

inland forge Jul 24, 2023, 8:07 PM

#

so generate say C9DN1690176961_tok_123

mellow vortex Jul 24, 2023, 8:07 PM

#

i gotcha

inland forge Jul 24, 2023, 8:08 PM

#

That way, if/when it does get called a second time for the same token (which would generate this error), you'd get a replay of the success before (or error before, if it errored)

#

This should let you consistently get to the success page

#

Its a patch to avoid the immediate ux problem, but you still need to dig into where those duplicate requests come from

mellow vortex Jul 24, 2023, 8:09 PM

#

I'm at my wits end on that

#

there is nothing in my code that should be doing that

#

the server doesn't do that for dozens or hundreds or other scripts

inland forge Jul 24, 2023, 8:10 PM

#

Hopefully, this can get things working well enough that you can get some sleep and look again tomorrow

mellow vortex Jul 24, 2023, 8:10 PM

#

this is nuts

inland forge Jul 24, 2023, 8:10 PM

#

Let me know when to try again

mellow vortex Jul 24, 2023, 8:10 PM

#

authorize.net runs hundred of trans per day...very similar/same processing but without the tokenization needed, which is what seems to be causing the issues

#

I can't - I need to get this moved to prod, so i can do the other 20 hours or stuff I need to do AFTER this is working

#

(i brough up auth.net because same server, same tech, just different processor - PAINLESS.)

#

Stripe is literally killing me and I really hate this product.

#

sorry, but it do

#

pure vitrol and i will never go through this again

inland forge Jul 24, 2023, 8:15 PM

#

I'm sorry you're having that experience, and we're really trying to help you get past it

#

So the other thing I'd suggest to help you narrow the search:

#

in your client side code, where you gather the inputs and to the form submit

#

add a random number there in a hidden input

#

why?

#

when you inspect this value in the server endpoint, two different values mean somehow the client code is indeed submitting twice

#

if you see the same value, either the server is inadvertently processing the request twice somehow, or the browser is sending the same request twice

mellow vortex Jul 24, 2023, 8:21 PM

#

it's passing the same token - i am seeing the same value in the stripe_token whenever there is a doubled request, but those doubles don't show in an front-end tools, even when they are cleary doing so to the backend

#

i gotcha

#

well, creating the idempot id and passing it should give us the same test, AND solve it IF it is indeed processing the same twice

inland forge Jul 24, 2023, 8:23 PM

#

Hmm yes, I supposed so with the token is generated in the same sequence, you're right

mellow vortex Jul 24, 2023, 8:32 PM

#

And it worked.

inland forge Jul 24, 2023, 8:32 PM

#

The concatenation in the idempotency key?

mellow vortex Jul 24, 2023, 8:32 PM

#

passing idemKey as a concat of order_code and token, yes

inland forge Jul 24, 2023, 8:34 PM

#

Ok, yea, so we still see the duplicated requests, like with this decline you tested:
https://dashboard.stripe.com/test/logs/req_vOzD3EyozMk3H3
https://dashboard.stripe.com/test/logs/req_ZSnAjIyBsyhwkX

Stripe Login | Sign in to the Stripe Dashboard

Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.

Stripe Login | Sign in to the Stripe Dashboard

Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.

#

but with the idempotency replay you avoid the "token already used" error that was breaking your flow

#

Like i said, you still need to look into why you process this twice on your server

#

But this should allow some breathing room while you figure that out

mellow vortex Jul 24, 2023, 8:36 PM

#

Yeah, I'm never going to look into it if it works. I have ZERO time, and I have no clue on where to begin. None of our other software running on our same environement has these issues. NOTHING like it.

#

This process is low volume, really. Like a few thousand transactions a year. I'm not wasting time IF this fixed it. (I need to make sure it;s not actually running the success login twice!)

#

Sure, I'd like to know WHY it's happening, but I can't waste my life shooting in the dark.

inland forge Jul 24, 2023, 8:42 PM

#

That's fair -- i just want to be clear that this is a workaround for the specific shape of the issue you're seeing with an unexpected duplicate request. The idempotency key does not fix the duplicate request, but it prevents those duplicates from having different results leading to the failures you saw.

mellow vortex Jul 24, 2023, 8:50 PM

#

can you tell me what happens with a duplicate success? If it redirects properly, does that mean it runs all of the try code twice? (That's an issue for 1-time delivery upon success.)

#

or does it some how "magically" only honor the redirects when there is a dup without running the rest of the code that executes upon successful payment???

inland forge Jul 24, 2023, 8:54 PM

#

I can't speak to your server code, but the stripe request will just immediately return the previous response

raw ruinBOT Jul 24, 2023, 9:01 PM

#

mellow vortex Jul 24, 2023, 9:05 PM

#

so it will return to the previous transaction's redirect (which we would not have experienced because of the duplicate trans), but not re-run all of the success code, is that correct?

astral oracle Jul 24, 2023, 9:16 PM

#

Hello! I'm taking over and catching up...

#

An idempotency replay response will return the same response; from there it's up to you what you do with it on your end. When you say "not re-run all of the success code" which success code are you referring to?

mellow vortex Jul 24, 2023, 9:19 PM

#

server side code that executes upon success. (everything else is in the exception handler)

astral oracle Jul 24, 2023, 9:19 PM

#

If you mean your server, then that's up to you and how your systems work. I can't tell you how the code on your end behaves.

mellow vortex Jul 24, 2023, 9:20 PM

#

that's not what I'm asking

#

Ok, so in the try: is the attempt to complete the transaction. Later in that same try block is code that executes AFTER success. At the end of a string of events (database work, etc.) following successful payment in that try block is a redirect to the success page for the browser. In the case of any error, the exception block beneath the try, it simply redirects back to the payment page and shows the error. What I want to verify is that when it hits one of these duplicates, it does NOT continue to run the remaining code in the try: block, rather it just redirects back to the success page. (That is fine/perfect, but if it continues back in the try: block, then we would be duplicating post-sale processes, and that would defeat the purpose of dup-catching, I think.)

#

is that clearer?

astral oracle Jul 24, 2023, 9:29 PM

#

Again, I can't tell you how your own code is going to behave. I can only tell you how Stripe is going to behave. It does sound like your success code would run twice though. To put it another way, why do you have reason to believe the code in your try block wouldn't run?

#

@mellow vortex You still there?

#

Curious if you ever added e.stopImmediatePropagation() above e.preventDefault() to your frontend code?

#

Doesn't seem like it based on the page you linked earlier.

#spoon-token-duplicate