chung-yi_elements-intent-params-conflict

[zinc nest]

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1471519785257795655

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

[prime fox]

hi there, looking into this now

[austere nest]

thank you!

[prime fox]

I see this documented in Elements, is this where you're setting capture method on the client side? https://docs.stripe.com/js/elements_object/create_without_intent#stripe_elements_no_intent-options-captureMethod

[austere nest]

That was where we set it, on the top-level. It used to work fine but starting this morning it failed. Example req_UAwd84BlQsZ491.

I think it's because of the mismatch with our server side code, where we set the capture method nested in payment method options: https://docs.stripe.com/api/payment_intents/create#create_payment_intent-payment_method_options-card-capture_method

[prime fox]

ah sorry, I misunderstood your original message. so now you're setting it on Elements under paymentMethodOptions.card, and it works? that seems odd to me

[austere nest]

yeah, it seems to work now. But the server side api supports it tho. So I wonder if it's just not documented, or really not supported.

[prime fox]

hmm I see. setting it there overrides the top-level setting, specifically for that payment method. let me do some digging to see if this is the recommended solution, one moment

[austere nest]

tahnks

[prime fox]

thanks for waiting. I was able to reproduce this, it only occurs if you specify capture_method: manual at the top level while having it in the paymentMethodOptions level in Elements. I believe this is the correct resolution, and we just need to do a better job of documenting it. I'll submit feedback to our docs team, thanks for bringing this to our attention

[austere nest]

Thank you! Just to double check, it is correct to specify captureMethod: manual under paymentMethodOptions.card for both client side (Elements) and server side (creating/confirming Payment Intent)?

[maiden heart]

Hi there 👋 jumping in as my teammate needed to step away. That is correct

[austere nest]

Hi @maiden heart thanks!

[solar mesa]

Hi, wanted to ask if this issue only affects the test environment or it affects the live environment too?

Is there official documentation for this change?

[maiden heart]

Hi there 👋 what change are you referring to?

[solar mesa]

The failure that started this morning for @austere nest

I.e this pattern no longer working

[maiden heart]

We didn't make a change

[solar mesa]

Do you know why it stopped working as of this morning but was working before?

By it i mean this setup

[maiden heart]

Can you share examples where this worked previously? It should have always failed as far as I'm aware

[solar mesa]

Will look for a request

[solar mesa]

Here is an example req_0BPcVl1kpfiIsk

[calm stag]

Hi 👋

I'm stepping in as my colleague needs to go. Give me a sec to catch up

[austere nest]

👋 @calm stag , while above @maiden heart and @prime fox mentioned it's correct to set captureMethod under paymentMethodOptions.card in Elements options, I now noticed in the browser console (test mode) it complains about that:

[Stripe.js] Unrecognized elements() parameter: paymentMethodOptions.card.captureMethod is not a recognized parameter. This may cause issues with your integration in the future.

Can you further help clairfy? Thank you!

[worthy trench]

does capture_method work instead?

[austere nest]

checking...

Got the same warning in the browser console.

[calm stag]

We are in the process of reverting this change but that will take some time.

In the meantime I found a recent request that failed here: https://dashboard.stripe.com/acct_1Rfn0aIR6A944ZOk/test/logs/req_sYIjom3zT1tVsr

I notice you are only passing a single payment method type. In that situation, would it be possible to specify capture_method on the Payment Intent creation at the top level instead of nesting?

[solar mesa]

That is correct, it started failing today

[austere nest]

Thanks for the update. Can you share in more details about the changes that will be reverted? Is it only affecting test mode?

[calm stag]

For that you will need to write in to Support here: https://support.stripe.com/contact

Can you address my question about your integration?

[solar mesa]

It is specified at both the top level and nesting in our integration when creating the payment intent server side

[austere nest]

Thanks. To clarify, @solar mesa and I are not from the same org, and it may be confusing. 😓

[solar mesa]

Apologies, yes we aren’t

[calm stag]

It is specified at both the top level and nesting in our integration when creating the payment intent server side

But that is not true. Capture method is not provided at the top level in this request: https://dashboard.stripe.com/acct_1Rfn0aIR6A944ZOk/test/logs/req_sYIjom3zT1tVsr

[solar mesa]

Interesting it doesn’t show in the body, but we pass it into the paymentintentcreateoptions

Which parameter would be the toplevel for the server side payment intent creation?

[calm stag]

The capture_method parameter

[solar mesa]

For stripe.js we are passing the top level on the client but no nesting. On server we are specifying toplevel and nesting

[calm stag]

As I said, the failing payment intent creation request does not specify a top level capture method

[solar mesa]

Neither does the successful one. Both the fail and successful do not have it in the body shown on stripe. but it is specified in the request

[calm stag]

If it isn't in the body of the request, the Stripe API didn't get it.

And, with respect to the successful request, that is because of a change we made that we are reverting

But I am asking if you can try to successfully pass the parameter on the top level. This is not happening right now and that implies the way you are structuring the Payment Intent creation in your Ruby code is not correctly passing this parameter.

[solar mesa]

We always specify the top level, this logic has not changed for a few weeks.

I have no idea why it is not shown in the request body on stripe.

I will do a manual step through

[calm stag]

That value is not being passed to the API. I recommend investigating the options variable after creation to determine if the value is set.

I just testing my Payment Intent creation in Ruby and the following code passed this value:

payment_intent = Stripe::PaymentIntent.create({
  amount: 2000,
  currency: 'usd',
  customer: customer.id,
  payment_method: 'pm_card_visa',
  confirm: true,
  return_url: 'https://example.com/return',
  capture_method: 'manual',
})

puts payment_intent

[solar mesa]

You are correct

I was looking in the wrong place. Thanks!

[calm stag]

Okay great! As I mentioned, we are reverting the change currently so that the failing request i provided above will succeed in the future. But, in general, it's advised to try and match the parameters as closely as possible between the Elements Session and the Payment Intent creation.

I realize there are some parameters in the Payment Intent that are not currently available for Elements Sessions.

[solar mesa]

Thanks again! We were not specifying top level. Specifying top level worked. I was looking in a place with the fix. We will keep it consistent across the elements session and payment intent creation

[austere nest]

@solar mesa if your question was answered, I'd like to get back to my above questions!

[solar mesa]

😅😅😂 apologies

[austere nest]

no worries! 👍

[calm stag]

Capture method is only available at the top level on the Elements instance. Unfortunately, we do not currently support including captureMethod within the paymentMethodOptions [parameter](<https://docs.stripe.com/js/elements_object/create_without_intent#stripe_elements_no_intent-options-paymentMethodOptions?)

[austere nest]

Got it. I might have been confused above. #1471519785257795655 message

In our case, we specifiy capture_method on the server, when creating payment intent, under the payment_method_options. How should we match it on the client side Elements?

I briefly tested it, and it seems to work without captureMethod at all specified on the client side. I'm not sure if that's correct.

[calm stag]

That is why I was asking about specifying capture_method on the top level on the server. Currently you cannot match that same specification when creating elements without an intent.

[austere nest]

My understanding is that specifying capture_method under payment_method_options is more flexible because it'll only respect the options for individual payment method when applicable. Whereas top-level capture_method: manual can't be specified for certain payment methods like ACH debit

I can test the following 2 options and report back:

• client: top-level captureMethod; server: top-level capture_method
• client: no captureMethod; server: capture_method under payment_method_options

[rich cloak]

fyi i'm taking over for snufkin, and yes if you can test and report back that would be great!

[austere nest]

Actually, I don't fully understand what's being reverted currently and if that would affect my test. Should I do my test now or wait until it's reverted?

[rich cloak]

i think testing now makes sense

[austere nest]

OK both works.

Interesting that the second option, in which Elements does not specify captureMethod: manual at all (but server specifies capture_method: "manual" under payment_method_options). 🤔

Does it mean when we are creating/confirming payment intent on the server, the captureMethod specified on the client Elements doesn't matter?

[rich cloak]

let me run a quick test of my own

the captureMethod specified on the client Elements doesn't matter?
i can confirm that this sentence is not true, for example if you specify manual in elements and automatic_async server side the server request will error

but oddly if you leave the server side request blank it will default to automatic_async which doesn't seem great 😅

still testing some things out though

you're doing nothing but passing capture method of manual in all of your tests right?

testing all the options for when the frontend specifies manual:

frontend specifies manual, backend specifies manual at top and nested levels:
results in capture_method manual and status requires_capture

frontend specifies manual, backend specifies manual at just the top level
results in capture_method manual and status requires_capture

frontend specifies manual, backend specifies manual at just the nested level
results in capture method automatic_async and status requires_capture

frontend specifies manual, backend specifies nothing
results in capture_method: automatic_async and status: succeeded

aaaand

testing all the options for when the frontend specifies nothing:

frontend specifies nothing, backend specifies manual at top and nested levels:
gets error: The provided capture_method (manual) does not match the expected capture_method (automatic).

frontend specifies nothing, backend specifies manual at just the top level
gets error: The provided capture_method (manual) does not match the expected capture_method (automatic).

frontend specifies nothing, backend specifies manual at just the nested level
results in capture method automatic_async and status requires_capture

frontend specifies nothing, backend specifies nothing
results in capture_method: automatic_async and status: succeeded

also FYI i think the incident itself is mitigated, how are things looking on your end @austere nest ?

[austere nest]

frontend specifies nothing, backend specifies manual at just the nested level
results in capture method automatic_async and status requires_capture

I think I got a slightly different result. Let me check again.

Re the incident, our automated tests are passing again so I assume it was back to normal! 🎉

[calm stag]

Hello 👋

I'm back and yes, we are seeing the reverted behavior deployed.

[zinc nest]

chung-yi_elements-intent-params-conflict

[austere nest]

frontend specifies nothing, backend specifies manual at just the nested level
results in capture method automatic_async and status requires_capture

This is our test (pi_3T0601GK3Gnpfa3O1gcp9p2k) for this scenario. The top-level capture method of the created payment intent is automatic (not automatic_async for some reason), but the nested capture method in payment_method_options is properly set to manual, and I think that takes higher priority. So looks like the result is correctly a credit hold for us.

The result of the above scenario is the same as:

frontend specifies manual, backend specifies manual at just the nested level
results in capture method automatic_async and status requires_capture

I wonder if the frontend specified captureMethod: manual is actually doing something. 🤔

[calm stag]

When provided, the nested capture method in the payment_method_options takes precedence over the top level on the Payment Intent. But you are asking if setting this on the Stripe.js Elements instance impacts anything?