supercodepoet-payment-element | Stripe Developers | Page 1

copper path Oct 21, 2021, 3:17 PM

#

hello again 👋

steel cliff Oct 21, 2021, 3:19 PM

#

hello

copper path Oct 21, 2021, 3:19 PM

#

As far as i know now the payment element doesn't support changing the subscription quantity, you'd need to manage that on the subscription level

steel cliff Oct 21, 2021, 3:20 PM

#

so from the client side

#

we would need to send updates to the subscription for a change in quantity

#

would the create a new payment intent client secret we have to re-pass to Payment Element?

#

or is the intention of the Stripe subscription flow is to collect the user data and quantity and have that locked before showing the payment form?

copper path Oct 21, 2021, 3:28 PM

#

that's a great question, and i can see how updating this right up to the time of submitting payment might be difficult

steel cliff Oct 21, 2021, 3:32 PM

#

yeah, we want to have just one payment form with one submission step. We gather all the information and the payment information and then submit for finalization.

#

we would rather not be forced into a two step process of collecting out data that we need and then going to another screen to collect payment data where quantity or even plan is locked

#

is there a way to handle the one step process? that is how the older Stripe.js integration worked

copper path Oct 21, 2021, 3:38 PM

#

i don't really have a good answer for you right now, to be honest

#

just so i make sure i understand, you're using the default incomplete behavior to confirm the PI to finish creating the sub?

steel cliff Oct 21, 2021, 3:45 PM

#

right now we are using the old Stripe.js integration where do NOT create an default_incomplete subscription

#

we charge immediately on subscription creation and use the default source on the customer

#

which we get a source token from the JS and pass it to the server to complete account setup and charge

copper path Oct 21, 2021, 3:46 PM

#

ok gotcha

steel cliff Oct 21, 2021, 3:47 PM

#

the flow in that documentation is a lot different where you create the customer, subscription and then pass a client secret from the first invoice to then be able to try and charge the customer

#

but in that scenario it seems like all variable data needs to be locked down before charge or have the ability to change plan and quantity after the payment form is shown

#

so we either need to update the subscription client to server with updated information before the customer finalizes payment information or be able to pass that updated information to the payment form for updated totals

#

just need to know how Stripe expects the flow to work so we get the correct path down

#

I can send requests to update the subscription when the user makes a change on the client but needed to know if those changes update the client secret and if the Payment Element needs to be re-render with new secret or if the secret will stay the same

copper path Oct 21, 2021, 3:51 PM

#

Yea to be honest i haven't tried this scenario yet with the new payment element

steel cliff Oct 21, 2021, 3:54 PM

#

is there a better solution that matches our checkout flow? what we would like is one screen that we collect all information and then charge for the subscription (looking to implement async payment methods in the future). We want the JS side of the equation to handle SCA and if that captcha gets launched again so we don't have a broken integration

copper path Oct 21, 2021, 3:55 PM

#

Remind me: are you using React in your front end at all, or just Stripe.js by itself?

steel cliff Oct 21, 2021, 3:55 PM

#

Stripe Checkout would be great but it doesn't looks to have enough customization knobs

#

we use Vue.js and integration Stripe.js into our Vue components

#

so it would be similar as using React

copper path Oct 21, 2021, 3:56 PM

#

OK cool - thanks. I'll see about the custom integration and get back to you. Might take me a bit though, and depending on how early exploration goes I might suggest we move to email with a ticket thread.

#

But regarding Checkout, is there a particular customization knob you're missing for your needs?

#

There are certainly limits to customizing Checkout, just curious which aspect of that you ran up against

steel cliff Oct 21, 2021, 3:59 PM

#

one off the top the head was the ability to give a unit to the quantity for a subscription. We would like to say Qty 5 seats where right now it says Qty 5, which can be confusing to the customer - 5 what? 5 subscriptions? etc

#

I can also give you a screen shot of our checkout page that shows the current integration if that helps

split wedge Oct 21, 2021, 4:03 PM

#

catching up here @steel cliff , one sec

steel cliff Oct 21, 2021, 4:04 PM

#

#

ok

split wedge Oct 21, 2021, 4:04 PM

#

off hand, PaymentElement in this scenario would be the last last page in your payment flow, so qty changing has to be done on a previous page, as that doesn't work well with how PaymentElement is set up
OR
on your current page ...

#

you have to make that page 2 sections, the top one where you can change qty and then select a "Done", which then mounts a PaymentElement which then greys out the top part for changing qty.
and if customer does want to update qty, then you unmount PaymentElement, let them change qty and then remount PaymentElement again.
Basically treat it as "two states", updating qty vs done updating qty and mount PaymentElement selectively

steel cliff Oct 21, 2021, 4:09 PM

#

when remounting the PaymentElement does that need a new client secret from the Subscription and then I assume that when the use changes qty and such I send those updates to the Subscription?

split wedge Oct 21, 2021, 4:10 PM

#

yes, it would first mean a new request to update the Subscription quantity, or a new Subscription entirely and that would require a new PaymentIntent amount and then you confirm that with PaymentElement.

steel cliff Oct 21, 2021, 4:13 PM

#

ok. So want to make sure I have all my facts for choosing and integration, Stripe does not have an integration that is one step that supports SCA?

split wedge Oct 21, 2021, 4:15 PM

#

Stripe does not have an integration that is one step that supports SCA?
can you elaborate that more?
Not sure what angle you're asking the question from, seems different from what we were talking about just before

steel cliff Oct 21, 2021, 4:16 PM

#

ok, yeah, let me try again

split wedge Oct 21, 2021, 4:16 PM

#

sure

steel cliff Oct 21, 2021, 4:16 PM

#

if you see the screenshot of the current checkout page

#

we collect all the information and then charge for the subscription and then setup all the data on our end

#

but that older integration that gets a source token that attaches to the customer as the default payment option and used to charge the subscription

#

but this integration doesn't appear to support SCA and a Stripe captcha (which we ran into a few weeks ago)

#

so we need to upgrade to a more payment intent flow

#

but it appears we would need to change our checkout flow to be more of a two step process

#

collecting email, qty, plan

#

then allowing payment method to be collect

#

to be able to then charge for the subscription

#

just wanted to see if there are any integrations from Stripe that would support SCA and captcha that would still just involve one step

#

collect all data email, qty, plan, and payment

#

then submit for charge

#

like the old source token method

split wedge Oct 21, 2021, 4:20 PM

#

gotcha thanks for detailing that, so ...

#

collect all data email, qty, plan, and payment
PaymentElement is a bit different in that it needs a PaymentIntent to be mounted, becuase it needs to know which PaymentMethods to render (as it renders multiple PaymentMethods depending on what the PaymentIntent supports)

if you don't use PaymentElement but instead use the standalone CardElement, you can make it a bit simpler.

However all that said, it will still be two steps.

With the recommended integration, you have to collect qty first so that you create a Subscription with "default_incomplete" first, then confirm the Subscription with card details to collect a payment.

The older way was simpler but due to its simplicity, it did not handle complex cases like SCA which aren't binary "success or fail" but rather have multiple states, so the API integration needs to have a couple of distinct steps rather than one unified step that handles everything.

steel cliff Oct 21, 2021, 4:28 PM

#

ok, thanks for that explanation

#

one final question

#

on the Payment Element flow

#

with the following code

#

const {error} = await stripe.confirmPayment({
element: paymentElement,
confirmParams: {
return_url: "https://my-site.com/order/123/complete",
}
});

#

when you get redirected to the return URL you get a payment intent ID to check to see if the subscription whas charged, correct?

#

will we also get a "customer.subscription.created" webhook to be able to know the subscription was charged and we can finish setting up the data?

#

and invoice.payment_succeeded will come in after customer.subscription.created

#supercodepoet-payment-element