HS

[twilit merlin]

Relevant code 3 (Frontend JS): // Confirms payment by using the client secret from the above code

const { error, paymentIntent } = await stripe.confirmPayment({
    elements,
    clientSecret,
    redirect: "if_required",
    confirmParams: {
        return_url: thankyouPage
    },
});```

[urban leaf]

Ah yes this makes sense since Invoice uses a different set of PaymentMethods than the "Automatic Payment Methods" PaymentElement uses 🤔

Taking some time to reproduce

[twilit merlin]

Just to expand on what we are exactly looking for. We have products that have monthly recurring, annual recurring and one-time payment options.

Our integration for the recurring is working as expected through the Subscription API endpoint.

However, when processing the one-time payments, we need to assign those payments to a specific price id (i.e. the one-time price id of a product) similar to how Stripe hosted checkout does for the one-time payment option (we can see what exact plan/price was chosen for the one-time payments through Stripe pricing tables/checkout).

But for a custom solution, doesn't look like it is possible to do that using a simple charge/payment (as it only takes the amount and not a price id) so we tried to leverage Invoice API with a price id as an Invoice Item instead.

But if there is any other better way to handle this, please let me know.

Basically we have created our own version of Stripe pricing tables (with monthly, annual, one-time payment options), and now trying to build the Stripe checkout experience using Payment Elements in order to keep the user on the site itself.

[devout pollen]

give us a while to get back to you, we're still looking into it

[twilit merlin]

No worries, please take your time. I just wanted to provide additional details on our use-case/workflow.

[devout pollen]

are you using the deferred intent flow? https://stripe.com/docs/payments/accept-a-payment-deferred

[twilit merlin]

Yes, I'm using the deferred flow, for both the recurring as well as one-time payments.

When the user lands on the checkout page (after selecting a plan), I use the amount, currency and mode (payment|subscription) to render the payment form. Once the user clicks on submit button, I create/fetch the customer_id server side and then proceed with the next API call (invoice|subscription) to get the client secret for the payment confirmation on the frontend.

I'm not creating the Payment Intent directly (like the doc page that you just shared), rather I'm calling the Invoice API which in turn creates the Payment Intent.
https://stripe.com/docs/invoicing/integration?method=elements#create-invoice-code

[devout pollen]

is there a reason why you're using the deferred intent flow here? typically you would simply initialize the Payment Element with the PaymentIntent's client_secret and then call confirmPayment normally

[twilit merlin]

Hmm I'm not exactly sure, but at some point I was struggling to get the integration working in a one-click sort of submission on the checkout page. On the checkout page, I wanted to make sure the whole form (name, payment details, address etc.) is available for the user to be filled out in a single go/step and then they just click the "Submit" button once. At that time only the deferred flow seemed to work for me.

Will the regular flow work just the same in this case? i.e. load the checkout page, initialize the complete form (name, payment details, address) and handle everything on single click of submit button after that?

More importantly, will I able to process one-time payments using a price_id? Or have some kind of plan/price information show up for these one-time payments in the dashboard (without going the metadata route) similar to Stripe checkout for one-time payments?

[devout pollen]

could you elaborate a bit more on which specific part you were struggling with?

when you say payment details is available for the user to fill up, do you mean the Payment Element?

[twilit merlin]

Honestly, I do not remember the exact details at this moment as it was couple months back, but the Payment Elements were not getting initialized for some reason. I might have missed something else at that time, so it is possible that it might not be related to normal/deferred flow, but just that the deferred flow seemed to work and I decided to stick with it.

Payment details: Yes, Payment Element, Link Authentication Element and the Address Element. Basically everything that will be part of the checkout form to collect these details.

The screenshot right now is missing the Address Element, but it will be added to the form eventually.

[devout pollen]

okay, i'm guessing that you're loading the Payment Element prior to creating the Subscription, is that right?

[twilit merlin]

Yes, that is correct.

[devout pollen]

that's probably why you were having trouble previously then.

If you want to load the Payment Element prior to having a Subscription (and hence corresponding PaymentIntent), then you would want to try using the Payment Element to create a PaymentMethod first, then pass that PaymentMethod to your backend and create the Subscription. You may subsequently need to return the client_secret to the frontend to be handled if further actions are required

[twilit merlin]

Sorry, when you say I need to use Payment Element to create PaymentMethod, can it be done without the user filling out anything? Because like I mentioned previously, I need to render the payment form once the user lands on the checkout page (before they start interacting with the page). And then I need to process the form on a single user click. I'm slightly confused here now with the creation of PaymentMethod first?

I might need to come back tomorrow to check the reply to this thread.

[devout pollen]

sorry, my previous answer was pretty confusing. let me get back to you in a bit. You can probably come back tomorrow to check on my reply, but the thread will be closed by then. You can ask a follow up question again on the main channel and provide a link to this thread as reference if necessary