#Disconsented-PaymentElementSub
cursive fiber
Hi, what do you mean by reject? Are you asking if you can block a subscription from being created?
raven sable
Currently, subscriptions are created and include a payment method. I can just not create the sub if the payment fingerprint exists in my database.
Having to accept & create the subscription, and then reject it off screen is a UX that's going to drive failed sales
cursive fiber
So what you're seeking is if the fingerprint exists, you do not want to create a subscription?
raven sable
Pretty much yep
cursive fiber
Preventing a subscription creation by looking at the fingerprint is not possible on Stripe's end. This would have to be build on your end. You'd have some sort of validation on your end
raven sable
I understand that much and I already handle it today but migrating to the flow above, it seems like I cannot handle it "on screen" I'd have to do it after the subscription is created.
Is my understanding correct?
cursive fiber
With Customer portal, https://stripe.com/docs/billing/subscriptions/integrating-customer-portal#portal-sessions -- no
sturdy edge
👋 hopping in since @cursive fiber needs to head out soon
raven sable
👋
sturdy edge
and just to close out the above question - I don't believe the payment element currently has any public flows that support what you need since the Subscription has to be created up front to get a payment intent or setup intent that can be used with the payment element
We do have https://stripe.com/docs/payments/run-custom-actions-before-confirmation (which is currently in beta and you'd have to write in), that would allow you to check the generated Payment Method (at which point you'd check the fingerprint) before choosing to continue with payment
raven sable
Ah bugger, all good thanks for the response. I'll just revert back to the card element then
sturdy edge
Copying your more recent question here as well:
Secondary question, for modelling different billing periods (1 month, 3 month + discount, 12 month + bigger discount). What's the preferred method, create a price for each billing period, automatically apply a discount or something else?
How are you applying the discount for the 3 month + 12 month subscriptions?
More specifically, do you want separate discounts for the 3 month and 12 month prices to be created that ONLY apply if they subscribe to the correct price?
raven sable
Sorry I mean do I model it [as a price], [as a discount] or a third method.
sturdy edge
I think I get what you're saying - basically your pricing model is something like this:
- $10 monthly price
- $27 3 month price
- $100 12 month price
Where you basically incentivize your customers to pay for a longer billing cycle by charging less - is that right?
raven sable
Yep!
sturdy edge
Awesome - so I'd just recommend keeping it simple and model them as three separate prices