b33fb0n3_api

[acoustic vale]

👋 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/1227895114685218837

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

[kind sinew]

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

• b33fb0n3_api, 20 hours ago, 48 messages
• b33fb0n3_docs, 2 days ago, 9 messages
• b33fb0n3_best-practices, 2 days ago, 42 messages
• b33f_paymentmethod-retrieve, 6 days ago, 20 messages

[tall timber]

👋 happy to help

would you mind sharing your use case? why do you need to create the PaymentIntent first?

[thin herald]

I am creating a payment flow that supports multiple different products. Some are one time purchasable and some are subscribable. To have a general flow of collecting payments, payment information and other order information, I would like to collect a paymentintent first

[tall timber]

are you worried about the orders that contain both subscription and one-off purchases?

[thin herald]

I am not

[tall timber]

do you have the case where this might happen?

[thin herald]

no

[tall timber]

ok so either one-off payment or subscription right?

[thin herald]

the customer only pay products that are one time purchasable or subscribable

[tall timber]

ok perfect

in that case on the frontend you don't have to change anything

on the backend though depending on the case

you either create a PaymentIntent (for one-off purchases) or create a Subscription and expand the latest_invoice.payment_intent but in both cases you just return the client_secret to the frontend to be confirmed

you can see how this works here https://docs.stripe.com/billing/subscriptions/build-subscriptions?platform=web&ui=elements#create-subscription

[thin herald]

where do I need to insert this?

Right now the flow looks like this:

Client clicks "pay" -> Server creates paymentintent and send back clientsecret & status -> Client do steps to confirm the paymentintent.

paymentintent.succeed
One time purchase
order will be created

Subscription
order will be created -> subscription will be created

[tall timber]

Client clicks "pay" -> Server creates paymentintent and send back clientsecret & status -> Client do steps to confirm the paymentintent.
here

when the client clicks pay

depending on what type of products your customer select

you either create the PI or you create the Subscription and expand on latest_invoice.payment_intent

[thin herald]

so I create both? Paymentintent and Subscription?

[tall timber]

in both cases you return the client secret and the client confirms

[tall timber]

either not both

when you create a subscription it automatically creates an invoice

that has a PaymentIntent

[thin herald]

so I can't only create the subscription when the payment is succeed?

[tall timber]

unfortunately for the time being that's the best flow

[thin herald]

can't I disable that for the first month or press it in the future?

[tall timber]

this is not the recommended flow/best practice

[thin herald]

Do I need to additional events when proceeding?

paymentintent.succeed
One time purchase
order will be created

Subscription
order will be created -> subscription will be created

[tall timber]

yes

[thin herald]

😦

[tall timber]

I will get into how you handle webhooks later

but would you mind trying this out for now?

[thin herald]

yea, I try it. Please bare me some minutes

[tall timber]

yes take your time, when you're ready we'll move to the webhooks part

[thin herald]

Done. The subscription and everything around it is now created, but it's "incomplete". How to directly confirm the payment intent now? My initial paymentintent (I mean for one time purchases) is directly confirmed, because I have all the information from my customer.

• How to add additional metadata to the created paymentintent and change the description?
• How to bind the paymentmethod to the customer when the charge succeeds like setup_future_usage: "off_session" in a paymentintent?

[tall timber]

when you created the subscription did you expand on latest_invoice.payment_intent?

would you mind sharing the request ID that created the subscription?

[thin herald]

yes. The req id is evt_1P4JTrD4LgnRPd5twexPW7t6

[tall timber]

just fyi, the request ID is req_xxx https://support.stripe.com/questions/finding-the-id-for-an-api-request

but I can get to it from the event ID

no worries

[thin herald]

oh sorry. Then it's req_UMFgE5GYBKOfQs

[tall timber]

no worries I was able to find it

sorry it's a bit busy on discord now

will be with you shortly

[thin herald]

sure take your time

[tall timber]

ok so basically with the subscription creation parameters you shared the payment method will be setup for future usage automatically since you passed payment_settings.save_default_payment_method

what do you need to use the metadata for exactly?

[thin herald]

that sounds good 👍

[thin herald]

inside the metadata of the subscription there is a accountId parameter. This parameter stores an accountid to my backend, to handle the permissions of the specific account. If the subscription is canceled or unpaid the permissions that comes with the subscription will be removed. If the subscription succeeds the permissions will stay there.

Inside the metadata of the paymentintent there are two values: futurePurchaseid and cartid. Both handle the fulfillment of the specific order. Cartid hold the id of the cart that will be read to add a new order. The futurepurchaseid is an id that will be used to create a new purchase (e.g. subscription update, order, ...)

[tall timber]

ok perfect, now we're moving to the fulfillment section which involves how to treat webhook events

basically for your payment_intent.* events you need to add on simple logic

if(payment_intent.invoice <> null)
 ignore event

[thin herald]

ok, right now I only listen to the payment_intent.succeeded event

[tall timber]

in that event you need to ignore payment_intents that are bound to an invoice

[thin herald]

What does that mean?

[tall timber]

if payment_intent.invoice is not null this means that the PaymentIntent was created by an Invoice

and instead of handling it on the payment_intent.succeeded event

you will handle it in the invoice.paid event

[thin herald]

ah that makes sense. Done

[tall timber]

more on fulfilling subscriptions can be found here
https://docs.stripe.com/billing/subscriptions/webhooks

[thin herald]

Alright 👍
How to do this stuff now?
#1227895114685218837 message

[tall timber]

which part?

confirming the Subscription's latest_invoice.payment_intent?

[thin herald]

❓ How to directly confirm the payment intent now? My initial paymentintent (I mean for one time purchases) is directly confirmed, because I have all the information from my customer.

❓ How to add additional metadata to the created paymentintent and change the description?
✅ How to bind the paymentmethod to the customer when the charge succeeds like setup_future_usage: "off_session" in a paymentintent?

[tall timber]

for the first question do you mean you already collected a Payment Method for the customer?

❓ How to add additional metadata to the created paymentintent and change the description?
why do you need the metadata on the PaymentIntent you can add the metadata directly on the subscription when you create it

https://docs.stripe.com/api/subscriptions/create#create_subscription-metadata

[thin herald]

yes, I done that, but both are different:
#1227895114685218837 message

[tall timber]

when you're dealing with subscriptions pass all the metadata needed on the subscription

since in all cases you're ignoring the payment_intent.* events when it's a subscription

you don't need the metadata to be on the PI

[thin herald]

you don't need the metadata to be on the PI

I need metadata on the PI, because of this:

Inside the metadata of the paymentintent there are two values: futurePurchaseid and cartid. Both handle the fulfillment of the specific order. Cartid hold the id of the cart that will be read to add a new order. The futurepurchaseid is an id that will be used to create a new purchase (e.g. subscription update, order, ...)

[tall timber]

just put all of the metadata on the subscription

[dire compass]

Hey, taking over here. Let me know if there's any follow-up Qs I can answer!

[thin herald]

I have 🙂

[dire compass]

Which part specifically?

[thin herald]

I guess the metadata for the subscription is for the subscription and I should handle only subscription events. Same for the paymentintent. My paymentintent events only handle the order fulfillment and the subscription only handled my subscription stuff

So how to do this: #1227895114685218837 message

[dire compass]

❓ How to add additional metadata to the created paymentintent and change the description?
This part?

Then just make an API call to update those fields: https://docs.stripe.com/api/payment_intents/update

[thin herald]

Yes this part. So I need to explicitly update the paymentintent?

How to do this:

❓ How to directly confirm the payment intent now? My initial paymentintent (I mean for one time purchases) is directly confirmed, because I have all the information from my customer.

[dire compass]

To clarify, is this a Payment Intent you're creating directly or one that is generated from a Subscription?

[dire compass]

You call confirmPayment using the latest_invoice[payment_intent][client_secret]: https://docs.stripe.com/billing/subscriptions/build-subscriptions?platform=web&ui=elements#complete-payment

[thin herald]

In the first attempt I wanted to create the initial payment as paymentintent for myself and create the subscription when the paymentintent is successfully. But @tall timber told me to not do that. Instead I should create a subscription for the customer while having the customer in my checkout process and then handle the webhook events as isolated parts

[thin herald]

For one time purchases the paymenintent is already confirmed. For subscriptions I done what tarzan told me

[dire compass]

OK, then you can set the description on the associated Payment Intents via this param: https://docs.stripe.com/api/subscriptions/create#create_subscription-description

[tall timber]

hey @thin herald I'm back, just a quick question

so we could be all on the same page

[thin herald]

sure

[tall timber]

are you collecting the payment method before you create the PaymentIntent/Subscription?

[thin herald]

I do

[tall timber]

ok that's where all of the confusion is

we don't really recommend you doing that for several reasons and the main one being that you would have to eventually handle any required action (e.g. 3DS) on the front end when you confirm the payment on the backend (for both PI and Subscriptions)

[thin herald]

I think your colleague sees it differently: #1227561359718486056 message

Right now I am using this flow ("before"): https://docs.stripe.com/payments/payment-element/migration-ct#server-side

[tall timber]

you don't have to use the confirmation token on the backend

you can use it on the front end

      clientSecret,
      confirmParams: {
        confirmation_token: '{{CONFIRMATION_TOKEN_ID}}',
        return_url: 'https://example.com/order/123/complete',
      },
    });```

[thin herald]

yea, but somewhere this confirmation token need to be created (normally while entering the paymentdetails) and then need to ship around and need to be displayed.

[tall timber]

so basically you would send back the client_secret either from the PI itself (for one-off payments) or from the Subscriptions' latest_invoice.payment_intent

[thin herald]

And I guess you know my problem with that: #1227561359718486056 message

[tall timber]

that's what I tried explaining yesterday if you already have a payment method that is saved

you no longer need the confirmation token

because you can automatically pass the PaymentMethod Id

unless I'm missing something here

[thin herald]

yes, that's what I am doing right now. Red is the subscription stuff. Green is the paymentintent stuff. And yellow is the response

[tall timber]

perfect

[thin herald]

❓ How to directly confirm the payment intent now? My initial paymentintent (I mean for one time purchases) is directly confirmed, because I have all the information from my customer.
❓ how to handle the webhooks correctly?

✅ How to add additional metadata to the created paymentintent and change the description?

I will do that with an extra update of the paymentintent

✅ How to bind the paymentmethod to the customer when the charge succeeds like setup_future_usage: "off_session" in a paymentintent?

[tall timber]

How to directly confirm the payment intent now? My initial paymentintent (I mean for one time purchases) is directly confirmed, because I have all the information from my customer.
with this code

      clientSecret,
      confirmParams: {
        confirmation_token: '{{CONFIRMATION_TOKEN_ID}}',
        return_url: 'https://example.com/order/123/complete',
      },
    });``` on the frontend

[thin herald]

the frontend does not have a confirmation code. In addition, the frontend already receives a confirmed paymentintent for "One time purchases".

[tall timber]

where are you confirming the PaymentIntent?

[thin herald]

while creating it with confirm: true

[tall timber]

and you're passing the confirmation token ID?

[thin herald]

I am using this right now ^
Only payment methods

[tall timber]

ok in that case you can pass the https://docs.stripe.com/api/subscriptions/create#create_subscription-default_payment_method

to the subscription

but then you no longer need the clientSecret

the idea of sending the clientSecret to the frontend is to confirm the payment on the frontend

[thin herald]

I thought the idea of sending the clientSecret to the frontend is to complete additional steps?

like what I do now:

[tall timber]

yes that's also one way to look at it

but why do it twice

you can confirm directly on the frontend

[thin herald]

what makes that easier?

[tall timber]

without having to create 2 steps for nothing here and failing the invoice on the backend

[thin herald]

I think it's easier to pass confirm: true instead of doing all the frontend stuff

[thin herald]

what do you mean?

[thin herald]

I now used the defaultPaymentMethod to add the paymentmethod to the subscription. That works fine, but it seems like it's still not confirmed

And now you know, why I just wanted to have the first payment paid thought the same way for subscriptions and one time purchases, because now I have not 1 flow to follow.. now I have 2 flows and both need to be maintained 😦

[winter python]

hi! I'm taking over this thread.

[thin herald]

hey 👋

[winter python]

I see a lot of context was shared in this thread. could you try summarizing your question?

[thin herald]

of course. Here are the important messages:

Initial question:
How can I collect the first payment of a subscription with an extra paymentintent and then automatically?

tarzan told me to create the subscription in backend and then pass it to the frontend: #1227895114685218837 message

And the rest of the thread is just fixing issues with that. These are the current open questions for it:
#1227895114685218837 message

[winter python]

can you share an example of a Subscription (sub_xxx) that you created this way so I can better understand?

[thin herald]

which way?
My way: sub_1P4IgrD4LgnRPd5tAerKG0pI
or
tarzan's way: sub_1P4LLmD4LgnRPd5tb12NGhny

[winter python]

okay I re-read the thread. so it looks like you have two main uses case:

• one time payments
• recurring payments with Subscriptions
  and if I understand correctly, you manage to make the one time payment work. so you questions is about Subscriptions now?

[thin herald]

yes

[winter python]

My way: sub_1P4IgrD4LgnRPd5tAerKG0pI
looks like this Subscriptions was created succesfully.
tarzan's way: sub_1P4LLmD4LgnRPd5tb12NGhny
next step here is to confirm the PaymentIntent on the frontend.

note this thread has been going on for 3h+, so it's getting difficult to help on Discord. I would recommend you to contact Stripe support directly with your issue. Make sure to:

1. clearly explain what you are trying to do
2. descible what is the exact issue you are facing
3. include all relevant information (object IDs, code samples, etc.)
   And they should have more time to investigate your issue and help: https://support.stripe.com/contact

[thin herald]

Yes, I understand. I would also rather have a solution than spend more hours writing.

Instead of going to the support I would try this:

What have you already attempted?
I think about setting a trail of 30? Maybe I do something with the billing anchor..? I don't know. Maybe something in this direction

Another solution I could think of is to confirm the paymentintent via the confirm api but I don't know if that's a possible fix for tarzan's idea...

[winter python]

Discord works best for simple/quick questions. For more complex questions like yours (that has now 3h+ of context), Stripe support is the best way to go. This will allow you to clearly explain your issue from scratch, and get back a clear answer.

[thin herald]

I understand that you don't want to help me on this point. It doesn't matter to you how I end up implementing it, after all, you and I don't know each other. I think everyone gets in a pickle and I assumed it would be a small thing, as I'm sure you saw in my initial message. In it I talked about simple parameters of the subscription object.

With this message I thought tarzan will go guide me through this whole process: #1227895114685218837 message
but that wasn't the case. This message confirmed my decision once again: #1227895114685218837 message
I trusted tarzan and my trust was broken. 😦

I will now get to work and solve the problem (unfortunately) without help. Nevertheless, thank you for being here soma.

[winter python]

If you send your message to Stripe support, it will get back to my team, and we will be able to dedicate some time to your issue to solve it. But if you prefere to work on this by yourself, that's perfectly fine.

[thin herald]

yes, I guess it's easier with a not intended version then contacting stripe support via the website

[winter python]

I'm not sure what you mean by "not intended". but here's a direct link to the page where you can write technical question to the support team: https://support.stripe.com/contact/email?topic=api_integration

[thin herald]

I already tried and I normally won't get an answer or the thread takes weeks. And for this kind of solution it's not worth to wait weeks for.

By "not intented" I mean to not follow the best pratice of subscriptions and just try to make it work somehow

[winter python]

I already tried and I normally won't get an answer or the thread takes weeks. And for this kind of solution it's not worth to wait weeks for.
make sure to check the "I am a developer and I have an integration-related question" checkbox on the link I shared, and your question will get directly to our team.
By "not intented" I mean to not follow the best pratice of subscriptions and just try to make it work somehow
got it.