#ironbeard-intents
sand estuary
generally yes, if you integrate by creating the PaymentIntent on page load, you might want to make an XHR call to your backend and update it. Though it doesn't really work with our default integration of PaymentElement(https://stripe.com/docs/payments/accept-a-payment?platform=web&ui=elements) since there's no way to update its UI for a new amount.
ornate niche
Gotcha. Also, a PaymentIntent has a amount, and the only thing we offer are annual Subscriptions to a few Products (possible I'll have a single Subscrption object with multiple Prices). So do I just need to sum the Prices to specify amount, or can PaymentIntent take Price objects?
junior spade
Subscriptions are a little different as they generate their own Payment Intents.
Do you know what you're planning to use to collect payment details (Elements, Checkout Sessions, etc)?
ornate niche
Ah, gotcha. I'm using the CardElements, mostly rolling my own cart/checkout process, etc.
We basically have two Products (one is an email newsletter and the other is SaaS with a few Prices). They are annual subscriptions only.
junior spade
Gotcha, so in that case you would create the Subscription first. The Subscription will then generate an Invoice with an underlying Payment Intent, and you can then use that Payment Intent with Elements. This guide uses the Payment Element, so you would need to adapt it slightly to use the Card Element(s), but it helps show the flow that you're looking for.
https://stripe.com/docs/billing/subscriptions/build-subscription?ui=elements
ornate niche
huh, interesting. I'll check this out, thanks!
junior spade
Any time!
ornate niche
When creating a Subscription, would there be a reason to create it with a payment_behavior value of anything other than default_incomplete?
junior spade
The other options fit some other integration paths better, but default_incomplete is the best fit when you're creating a subscription prior to having a payment method.