#daisdead
1 messages ยท Page 1 of 1 (latest)
Hello!
Hello! I wouldn't recommend creating a separate payment intent if you're integrating with subscriptions
Even if you're left with incomplete subscriptions, they should get automatically cancelled/expired after 23 hours so they're not just hanging around
I see - perhaps I should've reversed the scenarios as the trialing scenario is actually the more pertinent case
Gotcha, so really your issue is that you don't want to continue the trialing subscription unless a payment method is provided?
not quite
as part of checkout, a payment method would allow them to continue their subscription once the trial completes but also, we have additional products (add-ons) available to add to the subscription
but we don't want to add those additional products until a valid payment method is collected
Is there a reason you don't want to add them up front?
Is there a reason you don't want to add them up front?
could you clarify this?
In any case, it's a business decision that we only allow these additional products only in the case of a purchased core (or base) plan in the subscription
purchased to clarify means we have a payment method collected and attached to the subscription
I see - mostly I was asking because I was imagining you could just add those add-ons on subscription creation while trialing and then the first payment would still need a payment method
I feel this is partially what setup intent is for but im failing to connect details of understanding what were the "products" they agreed to intend to pay for in the API
Yeah let's back up for a minute and put aside the add-on products for now
For trialing Subscription they should come with a Setup Intent that you can use to collect payment method details. If you don't want to do any updates to the subscription until your sure the customer has a payment method you can add logic on your end to verify that the setup intent is successful
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
yep that all makes sense to me except -
If you don't want to do any updates to the subscription until your sure the customer has a payment method you can add logic on your end to verify that the setup intent is successful
assuming their intent is successful - how do we know what updates to apply from here? The customer intended to set up payment for some x subsription item(s) ; How do we know what the contents of x are since the changes haven't been applied?
I ask since the creation of a setup intent there is no configuration for this is x the customer intended to setup payment for
This could very well be an issue for developers to account for on our side and perhaps I misterpret exactly the Intent APIs and nature
Yeah Setup Intents don't really have any concept of what "amount" will be charged in the future
Gotcha; well at least the background of the APIs are becoming more clear to me ๐
I think I do see a solution moving forward though. We could leverage metadata to track those products to be updated
๐