#BidBird®
flint sleet
umbral vapor
Actually of bunch of these, at the moment:
Partitioned cookie or storage access was provided to “https://js.stripe.com/v3/elements-inner-loader-ui-aa766bc76ed26ddb87c1276c85ea5495.html#referrer=http%3A%2F%2Fbidbird.test%2Fauctions%2Fjobs%2Fcreate&controllerId=__privateStripeController1481” because it is loaded in the third-party context and dynamic state partitioning is enabled.
heady kite
Do you have a test page we can look at?
umbral vapor
trying to get ngrok going. having a quite time with it
holy cow, after several days it's working!
so user: shelley@example.com password when you go to Post Jobs tab at top
let me know if you can see this:
or some version
rocky cedar
Hi, stepping in and catching up here
I do not see 'Post Jobs' at the top, can you share where I should be looking at?
umbral vapor
that's weird the assets went away. let me try again
hows this one on http?
@rocky cedar that one working ok for you?
rocky cedar
Nope, I do not see it.
umbral vapor
man I don't understand.
rocky cedar
Nothing in top
umbral vapor
I get what your seeing. But not the reason behind it
let me try production building it. and see if that works. on npm run dev right now
that one ok?
rocky cedar
Now it's totally broken, just see a blank page.
umbral vapor
https://e557-184-176-132-26.ngrok.io ok, here is with https. this one ok?
rocky cedar
Not seeing it
rocky cedar
Now it's just spinning and nothing is pulled up. No errors on my dev console
umbral vapor
I wonder if this one is the correct. http://192.168.86.61:8000/
if not, something must be preventing sharing on the mac side of things.
rocky cedar
No go here either
umbral vapor
ok, so I'm sorry. Just sorry.
how else could we tackle this PaymentElement not mounting
rocky cedar
We would need to replicate this to see exactly what is happening. What other errors are you seeing on your console? Can you share screenshots so I can look around?
umbral vapor
yea, somethings screwy with the share.
anyhow here's some screen shots
thank you for trying. It's just such a pain. Feel bad
rocky cedar
No problem, looking at these now
umbral vapor
its weird, I could load the card.element but the payment.element is not loading
for context, working on upgrading from the 2018 api with stripe elements
rocky cedar
Can you copy and paste the errors in red here from the screenshots?
rocky cedar
So looking at these console errors, you can ignore these for now. Looking at the screenshot you shared earlier where the Payment Element is spilled over the container, we believe you're setting a height for it and it's too small for the Payment Element. As for next steps, can you look at this container where the Payment Element is in and see if it has an explicit height? If so, can you manipulate it via your dev console to see if it changes how it appears?
umbral vapor
yes, sure. I'll try anything. this is the:
that's the full blade file with html. I have not explicitly set any heights will try now
rocky cedar
It could also be your CSS or JS, so would also look at those.
I see you're using a few libraries for your CSS, I would also look at that. The next step is to increase the height of the container so the entire Payment Element is visible without a spill over.
umbral vapor
I was giving this a go overflow-y-auto didn't seem to do much.
here's something interesting.
If I change this:
// Create and mount the Payment Element const paymentElement = elements.create("payment", { to
// Create and mount the Payment Elementconst paymentElement = elements.create("card", {
the card shows.
lilac dagger
Hello again! We talked briefly the other day. I think I might be able to help. The issue here is that the container you're mounting the Payment Element into has a fixed height. The Card Element works because the Card Element has a fixed height, but the Payment Element has a variable height.
Is there any way you can provide a link to this page, or a test case that reproduces the same issue, so I can look at it with the web dev tools and show you specifically what the issue is?
This kind of thing is ~impossible to solve in detail without access to the page.
umbral vapor
I just tried some height things. Open to suggestions.
Sorry I wish I could, have been trying to get ngrok, laravel valet or expose to play nice but cannot get the assets to load for the link I send you
lilac dagger
Can you create a minimal test case and put it somewhere like GitHub pages or anything like that?
umbral vapor
I just put it completely outside the container and still no dice on the payment element.
well, here's a question. It's less important to have ach and all that right now. Could we work on the payment flow? Maybe get that up and going and circle back?
lilac dagger
What do you mean?
umbral vapor
Well after a customer submits a qty of items, I'd like to update the payment intent. Is that best done when a customer hits "Purchase Credits"
The old api would create a charge at that point
lilac dagger
Meaning you want to update the Payment Intent's amount using the new amount you calculate based on the new quantity?
umbral vapor
yes.
lilac dagger
Yes, you can do that if you want.
umbral vapor
would you recommend something else?
lilac dagger
I don't know enough about what you're building to make a recommendation.
Can you tell me more?
umbral vapor
I'm trying to update from the 2018 api that used the charge objects. After submitting a quantity the payment gateway would hit a "charge" method.
Is the PI flow different than this?
This is what I'm contemplating
lilac dagger
Have you seen our migration guide for going from Charges to Payment Intents? https://stripe.com/docs/payments/payment-intents/migration
umbral vapor
yes. and I'm on step 2.5
however, when I submit the $stripeIntent it comes in as json, is not updated with amount, quantity etc
lilac dagger
Taking a step back, what does your ideal payment flow look like from your customer's perspective?
umbral vapor
it's the original intent created
So, they'd come to this form, select number of jobs they'd like to post, and then purchase them at $5 ea
it's really a simple purchase
fetching from the server when the quantity is not known on the server at that point is peculiar to me. but I don't fully understand the fetch()
lilac dagger
Okay, so after they specify the quantity and you know the total amount to charge you should create the Payment Intent with that amount, pass the client_secret to your frontend, and use it with stripe.confirmCardPayment and the Card Element.
It sounds like you're creating the Payment Intent too soon, before you know the amount.
umbral vapor
interesting. Ok had a dev here say to create the PI when the form/page loaded.
lilac dagger
You can do it that way, but for your use case I wouldn't recommend that approach. There doesn't seem to be a need to create the Payment Intent that early in the process.
umbral vapor
great. let me shift that real quick
is this line in the payment-form not needed then?
data-secret="{{ $stripeIntent->client_secret }}"
actually, that migration guides says to create the PI first?
Or can that be done with the fetch() right after:
form.addEventListener('submit', async (event) => { event.preventDefault();
Not sure I understand. You're asking about details specific to your integration, and I don't know how your code works.
umbral vapor
I posted the js above.
lilac dagger
At a high-level, what you need to do is this:
- Determine the final amount you want to collect
- Create a Payment Intent with that
amount - Pass that Payment Intent's
client_secretto your frontend - Mount the Card Element, then hook up
stripe.confirmCardPaymentto the pay button, pass it theclient_secretand the Card Element, and it will attempt to confirm the Payment Intent and collect the money from the payment info entered into the Card Element
The specifics of how you do that are entirely up to you.
You can do it however you wish.
umbral vapor
alright, I just save this post. I think i'm heading out for the day. Let me try my best over the weekend and i'll be back! Thank you @lilac dagger so much.
lilac dagger
Happy to help!