#jarrett

1 messages · Page 1 of 1 (latest)

amber gustBOT
eager jolt
#

Hello 👋
My understanding is that it should redirect back to the return_url once you authorize or fail

#

Are you seeing diff results in your testing?

uneven ginkgo
#

nothing happens for me

eager jolt
#

and if you close the modal, do you get redirected to return_url?

uneven ginkgo
#

yep

eager jolt
#

Can you share the screenshot of the modal after you click authorize/fail?
also are you seeing any errors in your console?

uneven ginkgo
#

no errors

#

i click Simulate scan

#

then I clicked Authorize Test Payment

#

i guess i have these errors

eager jolt
#

looks like the confirmation is failing 🤔
Can you look into your Stripe dashboard and share the request ID where you're seeing a 400?

uneven ginkgo
#

i see this too

#

the confirmation isn't failing because if i click close on the modal

#

it redirects and the payment intent has succeeded

#

that first screenshot might not be relevant. i cleared my console out

#

and that didn't happen the second go around

eager jolt
#

Ah gotcha. Looks like the PaymentIntent is still getting processed when the client-side code tries to access it
Can you share that request ID?

uneven ginkgo
#

where do I find the request id for this

eager jolt
#

its the ID starting with req_xxx in the screenshot

#

In the request_log_url

uneven ginkgo
#

it did eventually go through it seems tho

#

it just never triggers a redirect

daring hatch
#

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

#

Taking a look at that request, hang on...

#

Can you share the code where you set return_url?

uneven ginkgo
#
    const { error, paymentIntent } = await this.stripe.confirmPayment({
      elements,
      clientSecret,
      confirmParams: {
        return_url: `${this.paymentIntentPathValue}`,
        payment_method_data: {
          billing_details: {
            name: this.nameTarget.value,
            email: this.emailValue,
            address: {
              line1: this.line1Target.value,
              line2: this.line2Target.value,
              city: this.cityTarget.value,
              state: this.stateTarget.value,
              postal_code: this.postalCodeTarget.value,
              country: this.countryTarget.value
            }
          }
        }
      },```
#

{ betas: ['elements_enable_deferred_intent_beta_1'] }

daring hatch
#

And paymentIntentPathValue is a fully qualified URL starting with https://?

uneven ginkgo
#

http://

#

in development

#

http://localhost:3000/checkout/invoices/63fe3042e1b8327a33061287/stripe_payment_intent

daring hatch
#

So you click on Authorize test payment and then you're taken back to the Simulate scan button in the modal?

uneven ginkgo
#

i'm not even taken back

daring hatch
#

Oh. I thought that's what happened based on your screenshots above?

#

What happens when you click on Authorize test payment?

uneven ginkgo
#

the stripe test page says it was successful

#

then i close that tab manually

daring hatch
#

Let me see if I can reproduce, hang on...

#

Hm, it's working as expected for me. When I click on Authorize test payment and the payment succeeds the payment page detects the successful payment and redirects to the return_url.

#

Let's try this...

#
  1. Get to the point just before you click on your pay/buy button
  2. Open the console and clear it
  3. Click pay/buy
  4. Click on Simulate scan
  5. Click on Authorize test payment
  6. Go back to the tab with the payment page/modal, wait a moment, then share the console output here
#

I want to see all the output to see if there's a clue as to what might be going on.

uneven ginkgo
#

this is all i have

daring hatch
#

429? That's interesting. That indicates you're being rate limited. Do you have a lot of tabs open where you're trying this? Or are you doing anything like polling from the backend? Anything that might be generating a large number of requests to Stripe?

uneven ginkgo
#

not that I know of

daring hatch
#

Do other people have access to this account? Could they be doing something that's causing the rate limiting?

uneven ginkgo
#

yes but it's not likely

#

and why would i only get 429 on the redirect

#

and never on any other request

#

i've been testing this all day today and not one of the other requests i've made for adding, paying, etc has returned 429

daring hatch
#

I'm not sure. Let me investigate more, hang on...

#

It looks like they're all object lock timeouts; that happens when multiple things try to access the same object at the same time. That kinda makes sense; when the modal is open it polls the Payment Intent behind the scenes to see if it's been paid yet or not, and when you click on the Authorize test payment button the Payment Intent is accessed and modified, which means the polling will get lock timeout errors when it tries to read it at the same time.

#

However, I don't know why this would cause the page to not work right.

#

Once the Payment Intent is modified and transitions to succeeded the polling should pick that up and proceed to redirect you to the return_url. That never happens though, right? No matter how long you wait?

#

And there are no further messages in the console no matter how long you wait?

#

This is what I see when I test in the Network tab of the dev tools filtered to api.stripe.com. Can you try the same and see what the output looks like? Even if there are 429's in there I would expect you to get a 200 at the end and then be redirected.

uneven ginkgo
#

I stepped away but it does eventually 200. I thought I said that before but maybe it wasn’t clear that is what I meant here #1080161222676193331 message

daring hatch
#

And then it redirects?

uneven ginkgo
#

No, never redirects

#

I’ve waited longer than one should for it and never had it happen

#

like minutes

daring hatch
#

That's very odd. If it's not redirecting after polling succeeds and sees that the Payment Intent has succeeded I would expect an error in the console of some kind. You're sure there's nothing? You're not filtering console output in any way?

uneven ginkgo
#

I’ll check again when I return

uneven ginkgo
#

nothing i can tell

#

if I have an unrelated question is it best to make a separate thread or ask it here?

unkempt cedar
#

Separate thread usually, but since this one is active, you can ask here

uneven ginkgo
unkempt cedar
uneven ginkgo
#

My issue is the Payment Element is showing ones that I can never use

#

We're using the payment element with deferred payment intent

#

so we can finalize the invoice after we've collected payment

unkempt cedar
#

Ah, okay, then you can either disable it in the Dashboard (which will stop Klarna from being used automatically on all your payment pages), or you can explicitly set which payment method types you want to accept at the Payment/Setup Intent level by setting automatic_payment_methods.enabled = 'false' (https://stripe.com/docs/api/payment_intents/create#create_payment_intent-automatic_payment_methods) and excluding Klarna/Afterpay from payment_method_types (https://stripe.com/docs/api/payment_intents/create#create_payment_intent-payment_method_types)

If you're using Setup Intents, then the parameters are mostly the same, except that you don't need to set automatic_payment_methods.enabled = 'false': https://stripe.com/docs/api/payment_intents/create#create_payment_intent-payment_method_types

uneven ginkgo
#

i don't create the payment intent.... i'm using Invoices

#

I want to accept whatever payment methods are applicable to the user based on their currency and the amount

unkempt cedar
#

If you use the Payment Element, then you're creating a Payment Intent somewhere

uneven ginkgo
#

the invoice creates it

#

how do i tell if a payment method can be used to pay an invoice

#

like klarna, afterpay, etc

#

it seems that the easiest is just disabling those entirely

#

since we only charge through invoices and subscriptions

#

and if it can't be used for an invoice or subscription we can just disable it entirely

unkempt cedar
#

Yeah, disabling it entirely is possible. I also gave instructions for setting the payment method type at the Invoice level, so it's up to you what you want to do.

uneven ginkgo
unkempt cedar
#

That redirects to this thread. Not sure what you're intending to link to

uneven ginkgo
#

didn't realize invoicing was all the way on the end. had to scroll horizonitally

#

i'm confused cause it says Link doesn't work for invoicing but it does for me lol

unkempt cedar
#

Gotcha. Yeah, there are a lot of ways to do this, so if this one works for you, then awesome!

uneven ginkgo
#

but what about the fact that it says Link doesn't work

#

is that an error?

unkempt cedar
#

Which part says Link doesn't work? Can you point specifically to where you're seeing that?

uneven ginkgo
#

scroll all the way right

light swift
#

You paid the Invoice-associated payment intent by managing the payment manuallys via the payment elements, correct?

uneven ginkgo
#

i currently am letting the Payment Element determine it's own since i disabled payments at the account level that can't be used for invoices or subs

light swift
#

Sure, but you said above you tried this successfully

uneven ginkgo
#

yes, Payment Element shows Link

#

i finalize my invoice and pay confirm that Payment Intent with Link