#ericwood-payment-request-windows
tardy ocean
interesting, no i haven't seen this happening before
chrome should behave the same across platforms
this is with the same payment request button code?
abstract dirge
that was a surprise to me as well, since it's non-native UI! We're doing things slightly custom and not just using the payment request button element, but this is using the same underlying paymentRequest object, just prompting for googlepay
lemme get the exact code showing the prompt one sec
we're basically just calling paymentRequest.show
the UI it's showing I think is the generic PaymentRequest UI (not the GooglePay-specific one), but I'd expect that behavior to be identical on MacOS using the same Google account
tardy ocean
not sure if i can help for a direct google pay integration, unfortunately. the stripe payment request button should be using only the updated google pay UI now, as far as i know.
abstract dirge
I'm not picky about the UI, but unfortunately I can't ship this with the total intermittently not populating...the inconsistent UIs might be a clue, although not one I've been able to make sense of so far
there doesn't seem to be a way to introspect the paymentRequest object to verify I set the correct fields via update; this is making it a bit tougher to fully verify I don't have a race condition somewhere in our code. do you know of a way to do this?
tardy ocean
The raw browser payment request api is pretty challenging to understand in my experience, the update behaviour in particular
is this not a stripe-based integration then?
abstract dirge
yeah I've had issues with it in the past; this is all through the Stripe libraries, though; we're using the stripe.paymentRequest API directly: https://stripe.com/docs/js/payment_request/create
tardy ocean
Does this happen with a simplified pattern without updates? I'm trying to figure out how we can try to repro this to investigate
ie, figure out what exactly is needed to trigger this semi reliably
its more challenging because i wont have a windows machine for testing myself
so if you have a clear repro i can share with the team (eg on a jsfiddle or codesandbox etc) this would be helpful for the stripe.js team to investigate
abstract dirge
I'll see if I can spin up something this morning, I was hoping maybe this was a known issue but I'll see what I can do to isolate it further! we do have a publicly accessible review app that reliably shows the issue, but it does mean a few steps to go through the checkout process and the code not being accessible
appreciate the help and I'll report back with a better demo of the issue
abstract dirge
hey @tardy ocean quick update! I made a quick POC here, and I'm getting mixed results on windows still, but overall it seems to work somewhat consistently? https://codepen.io/eric-wood/pen/rNwjqyN
something I noticed, though, is calling update too soon results in the update not taking effect. I don't know why that would be the case; without the setTimeout it never works on MacOS or Windows
I really dislike how we're doing this but it's a codebase I inherited (isn't that always how it goes?); curious what your take on that behavior is but I'm going to see if I can refactor so we're not relying on update and instead create the object with the correct fields directly
abstract dirge
heh just dropping a message in so it doesn't get archived 😬 still new to discord threads, I can re-post my question!
stable seal
hey sorry for the delay, I thought @tardy ocean was working with you but they are in a meeting. Trying to grasp what this thread is about, give me some time, Discord is quite busy right now
abstract dirge
yea no worries I am honestly psyched that y'all are around at all to answer questions! let me know if you'd like a synopsis, I might be able to save you some time
stable seal
yeah sorry, we're a small team and everyone is quite busy right now, it will likely take many/multiple hours to try and follow up on this
abstract dirge
all good! I will let the thread expire and check in tomorrow if there's no response. thanks!
stable seal
don't worry I'll change the default expiration date
@abstract dirge are you maybe seeing
Uncaught IntegrationError: You cannot update Payment Request options while the payment sheet is showing.
in the logs on Windows?
abstract dirge
hmmm I was not, lemme check
tardy ocean
howdy again 👋
abstract dirge
not seeing that; it probably happened because you clicked it before that settimeout heh
hey!
I guess the clearest way to illustrate the problem is removing the setTimeout entirely; my thesis is basically "you can't call update until things complete asynchronously after calling stripe.paymentRequest"
stable seal
I can't even make your example work right now. I get "no payment options available" on codepen despite Stripe's normal PaymentRequest button working fine
do I need to click something somewhere?
tardy ocean
@stable seal did you paste in a PK?
abstract dirge
I left the publishable key out, maybe that's it?
tardy ocean
first line of JS
stable seal
ah no okay
tardy ocean
also it seems to wipe occasionally, heads up
abstract dirge
oh yea you may need to fork; I can throw our test PK in there if it makes life easier
tardy ocean
@abstract dirge when i set the timeout to be 10s for example, and click the button before that, i end up in the weird $0 state
stable seal
how are you reproducing the bug? Like I changed the pub key and it works fine, every time I reload the page it loses the API key so I'm confused
@abstract dirge when i check the timeout to be 10s for example, and click the button before that, i end up in the weird $0 state
That's already what I explained above @tardy ocean
that's unrelated to eric's bug, that's Rubeus idea and it's expected
abstract dirge
here I'll toss our PK in so it's less confusing; the issue we're having is we create the paymentrequeset and then try updating it; doing so too soon seems to be a noop
stable seal
you can use Stripe's default key: pk_test_TYooMQauvdEDq54NiTphI7jx
if you just want one that's not yours
abstract dirge
oh nice ok saved with that PK
stable seal
okay I can see the $0 sometimes, let me see if I find anything useful thee
abstract dirge
but yea the core problem seems to be calling update too soon doesn't update anything, probably because the stripe.paymentRequest call is doing some network stuffs that needs to complete first
stable seal
Okay the only time I get the $0 I have the error mentioned above, it's because I click before your setTimeout is done
My take is that if you change the pending amount from 0 to 1799 for example you'll see 17.99 instead every time because it's your default amount and update hasn't run first
abstract dirge
with the setTimeout it will work, but if you lower it below, say 500ms it'll mostly not work
or if you remove it entirely it will 100% not work
stable seal
I recommend adding clear logs before/after the show and before/after the .update call to understand what's happening in what order first
Sorry I thought the codepen was the way to reproduce the exact bug, is it not?
abstract dirge
it probably got lost in my walls of text; the idea was if you get rid of the setTimeout it stops working, or if you play with the timing
the idea was to illustrate that there's an undocumented timing component to update
stable seal
Can I ask you to make a clear codepen with the exact bug and clear logs before/after each important step so that it's easy to debug all the same way?
tardy ocean
the initial problem was seeing this in windows only, with a suspected timing factor affecting this integration pattern
abstract dirge
this codepen was an attempt to recreate what our code was doing, I added the setTimeout since the call to update happens very soon after the page loads, but asynchronously
which led me to notice calling it too early results in no update taking place, which is what led to this; the windows aspect was a red herring it seems
if you comment out the setTimeout you'll notice the update call never takes
which is unexpected, at least to me; if this is expected behavior then it helps me determine how to approach the problem
stable seal
I'm sorry for being dense, I don't know codepen, how do I comment the code and still re-run it N times in a row on reload?
abstract dirge
codepen won't do that, but you can refresh a few times
you can view the full thing sans-editor here: https://codepen.io/eric-wood/full/rNwjqyN
tardy ocean
you can fork like jsfiddle but i think it requires an account
abstract dirge
I'll fork mine and do a case that always fails (without the setTimeout)
non-working version: https://codepen.io/eric-wood/pen/jOwydVX
stable seal
yeah I want nothing to do with creating an account just to test something, that's why I was asking
abstract dirge
no worries, sorry about that I didn't realize it was going to be a pain!
stable seal
and so just to confirm: you now say this is unrelated to Windows and happens on your Mac too?
abstract dirge
yep it happens consistently across both platforms
unsure how that was happening earlier, but hey sometimes race conditions are just like that
stable seal
Gotcha, thanks for clarifying
We're asking our team in parallel, this does look like a real Chrome bug to me
can you do a third codepen where the default amount is not 0?
abstract dirge
I'm kinda shocked I'm one of the first to uncover it if so; I couldn't find anything on the chromium tracker this morning tho
yep!
stable seal
just to confirm that Chrome basically "caches" the amount
Well I mean why would someone do what you do though 😅
no one should initialize the button with $0 and instantly update it to a real amount
abstract dirge
lol yea I don't like how we're doing this AT ALL but these are the cards I've been dealt
stable seal
sure but that's why no one would have found it I think
abstract dirge
this sets it to $10 and then updates it: https://codepen.io/eric-wood/pen/MWoJLoM
tardy ocean
if i set the pending amount to 10 that is what gets stuck & shown in the broken cases
$0.10
abstract dirge
yeah my gut reaction, not knowing much about the internals of stripe.js, is that creating the paymentRequest object fires off some requests which need to complete before update works properly
or the update happens and then the init requests come back and reset the state, or something along those lines
stable seal
yeah that could make sense
abstract dirge
the paymentRequest object itself contains no state I can see re: the current totals etc., which reinforces to me that it's stored server-side and I'm calling update before the proper call/response happens
tardy ocean
right, so we'll nailed down pretty firmly that we need to address something here in Stripe.js
abstract dirge
ok! to take this back to our product manager at least it's pretty safe to say the solution for now is to stop doing this all funky and initialize with the correct values?
tardy ocean
That would work around the issue, it seems
I'm going to write this up to share with the team who works on Stripe.js internally, i can keep you updated on it if you email in and mention my username
abstract dirge
awesome, thanks so much! I have an email support thread that hasn't gone anywhere yet, I'll mention that there
tardy ocean
if its about this, then sure, but if its something else then a new email is probably better
abstract dirge
oh yea it's this issue