#benjamineugenewhite -
stone flame
Hello, I definitely think that that pattern makes sense. If you want the form to load upfront, creating a PI for a dummy amount and letting the user change away from that totally makes sense
stone flame
Of course, do you have any questions on implementing it or are you mostly trying to confirm that that is a viable way to go?
junior olive
may have follow up questions later, but can ask in different thread.
and yes, for now, just wanted to confirm viability
junior olive
@stone flame one follow up now: are there any examples or guidance for using Elements in context of subscriptions? We allow our users to do one-time or recurring contributions (all from same form).
stone flame
Yes we do! Can you tell me if this doc looks like what you are looking for? https://stripe.com/docs/billing/subscriptions/build-subscriptions?ui=elements
junior olive
It's a good starting point. The complicating factor in my case is that the user can choose an arbitrary amount for subscription, so we don't have preset products + price. In status quo, we handle this by having a single product and then updating the unit amount in price data that gets passed to stripe.Subscription.create (on the backend).
FWIW, I'm refactoring pre-existing integration that was created before Stripe Elements was around/recommended way of doing things.
stone flame
Gotcha
Are you saying that you are unsure if that custom amount + unit price will work here or are you again running this by? Seems reasonable to me though I haven't been able to test
junior olive
I believe the custom amount + unit price should work, but not quite sure how the approach of dummy PI on page load interacts with subscription API. We won't know until user has clicked through form and submitted whether it's a one-time or subscription.
stone flame
Ah I see. That is a fun one. My two initial ideas are:
- Have the page be for a one time payment and if they choose subscription, start a subscription with a month trial or a 100% off for one month coupon
- Create a subscription that will cancel after 1 month, use its first invoice's payment intent on your page, and take away that end date if they choose subscription
I feel like things in the #1 camp will make more sense but may need to think on that a bit
junior olive
with #1 path, wonder if the receipts/emails etc. from stripe would potentially be confusing to end user.
stone flame
Apologies for the delay, that is a good point. I am trying to think of how you might be able to keep the emails and receipts consistent here. That actually would apply to #2 a bit I think as the user may get an email about a subscription payment for a one time payment
cobalt granite
Hi 👋 I'm stepping in for @stone flame .
Unfortunately the only way I could see you using either approach and not triggering multiple emails to customers is if you de-activated automated billing emails and instead triggered them yourself.
junior olive
Thanks @cobalt granite -- so are the automated billing emails recurring, or is that just for initial payment?
cobalt granite
They can be for a number of events, depending on your settings. We walk through it a bit here: https://stripe.com/docs/invoicing/send-email
junior olive
got it -- to further complicate matters, in our use case, we are facilitating contributions to partner organizations, so we use Stripe Connect. Based on what I'm seeing here (https://stripe.com/docs/receipts#receipts-for-stripe-connect), it sounds like this would require having individual connected accounts change their email receipt settings in stripe dashboard. Is that right?
cobalt granite
By Partner organizations do you mean they are Standard Accounts?
junior olive
I believe so. I'm still getting up to speed on all the lingo. We facilitate contributions to partner orgs who grant access to my org's stripe account to handle transactions on their behalf.
cobalt granite
Yes in that case they would likely need to update their own email settings as well