bernzjh-subscription-trial | Stripe Developers | Page 1

snow nimbusBOT Feb 9, 2024, 5:30 PM

#

@open trail :question: Have a non-technical question, account issue, or need one-on-one support? We wish we could help, but this community is focused on developers and technical discussions. Our support team will be able to assist you better than we can: https://support.stripe.com/contact

junior furnace Feb 9, 2024, 5:30 PM

#

sorry wrong button

#

bernzjh-subscription-trial

#

@open trail In our API we have PaymentIntents for accepting a payment now and SetupIntent for collecting payment method details upfront for a future payment

#

On the Subscription, this exists too. If you take a payment upfront then the first Invoice will have a PaymentIntent that you can use with PaymentElement.
If your first Invoice doesn't take a payment (trial, 100% off coupon, etc.) then you can use the SetupIntent on the Subscription. It's in https://stripe.com/docs/api/subscriptions/object#subscription_object-pending_setup_intent

open trail Feb 9, 2024, 5:33 PM

#

Yeah, we see that and handle the case, but the issue is that we don't want to create the subscription for a user in advance in case they don't complete it. We found conflicting information on how inactive / non completed subscriptions work and if they would be counted towards total subscriptions in the dashboard

junior furnace Feb 9, 2024, 5:34 PM

#

So you're using the "defer intent" flow right? You basically whant to collect the payment method details first and then confirm the Subscription's PI/SI after it

open trail Feb 9, 2024, 5:35 PM

#

Correct. That way we know which subscription to create for them. But we need all payment methods to still show that there is a trial period.

#

And in our current testing, even if a $0 payment is declined, the status of the subscription changes to trialing.

junior furnace Feb 9, 2024, 5:37 PM

#

I don't know what that could mean exactly unfortunately. Why would a "$0 payment is declined" happen? I'm going to need a lot more specific details with exact calls and exact object ids

open trail Feb 9, 2024, 5:40 PM

#

So this is in the sandbox. Put very specifically, we though if we were starting a trial, the price for the amount on the stripe.elements options should be 0.00

elements.value = stripe.elements({
  mode: 'subscription',
  currency: 'usd',
  amount: 0,
  setup_future_usage: 'off_session'
})

But when testing the flow as written in here https://stripe.com/docs/payments/accept-a-payment-deferred?platform=web&type=subscription#create-intent when using the test card 4000000000000002 (generic decline), the subscription generated was still started

#

What other information do you require?

junior furnace Feb 9, 2024, 5:42 PM

#

when using the test card 4000000000000002 (generic decline), the subscription generated was still started
Can you share the Subscription id so I have a look?

open trail Feb 9, 2024, 5:42 PM

#

sure, one moment

#

the subscription id is sub_1Ohy8WBHmaC9ycI0LNXbBL6D

#

Its on the sandbox

junior furnace Feb 9, 2024, 5:48 PM

#

yes, let me look

#

Okay so you created the Subscription with payment_behavior: 'default_incomplete' here

open trail Feb 9, 2024, 5:50 PM

#

Yeah, per the guide above

junior furnace Feb 9, 2024, 5:50 PM

#

yeah the guide doesn't really try to optimize for "never create a Subscription if not needed" though

#

I don't think there's any way to do what you are after right now unfortunately.

#

You'd have to do your own SetupIntent first and get that confirmed and only create the Subscription after the SetupIntent confirmation succeeds

open trail Feb 9, 2024, 5:52 PM

#

So is there a way to apply specific setup intents and payment intents to a specific subscription?

#

Possibly to initialize them with an already confirmed intent?

#

So that the subscription knows that a payment method was validated.

#

This is mostly just to make sure that invoices are assigned correctly to subscriptions

junior furnace Feb 9, 2024, 5:55 PM

#

no that's impossible

#

But you only need to special case the trial part right?

#

If the Subscriptio would charge upfront then you'd have an Invoice + PaymentIntent and that'd work
The problem you have is that default_incomplete will not stay in incomplete for trials and instead goes straight to trialing right?

open trail Feb 9, 2024, 5:58 PM

#

correct. But for the setup intent, is there a way for the client secret to reflect that this is a trial period. In testing, if we got the client secret from the subscription by creating it first, it was reflected across all payment types that it was for a trial

junior furnace Feb 9, 2024, 5:59 PM

#

sadly no. I never realized we didn't have that option 😦

#

So it's a feature request I just filed to the product team but it's unlikely to be built any time soon

open trail Feb 9, 2024, 6:01 PM

#

Unfortunate, since this doesn't seem like a relatively out there flow for trials. It would honestly be nice if the elements option for mode='subscription' had a trial variable to reflect this, or that setupIntents could also have something like trial_end added.

junior furnace Feb 9, 2024, 6:02 PM

#

yeah I totally agree

#

We just missed it! I help dozens of developers a month here and I never realized we missed this

#

We definitely should build it, just would take a while so you can't really wait on that 😦

open trail Feb 9, 2024, 6:04 PM

#

Yeah, this project is under a crunch here. So then my other question is what happens if we cancel a trialed subscription that still has a pending_setup_intent, since I assume that the lack of one would mean that the intent succeeded. Would that count towards subscription cancels in analytics?

junior furnace Feb 9, 2024, 6:05 PM

#

I don't know unfortunately, my team never touches our analytics unfortunately. I'd recommend discussing this with our support team.

But if it were me I would branch my code so that I use mode: 'subscription' if I am taking a payment upfront, or mode: 'setup' if I am doing a trial. And after the SetupIntent is confirmed successfully I'd create my trialing Subscription at that point.

open trail Feb 9, 2024, 6:07 PM

#

and set the setup for price 0? The issue though is still how trials are reflected in alternate payment methods. The setup intent I get from creating the subscription first accurately reflects this, but the one I create myself would not.

#

I imagine that this is important to comply with specifically google pay and apple pay for how to display subscriptions

junior furnace Feb 9, 2024, 6:11 PM

#

possibly. Alternatively my colleague said you could disable wallets (GooglePay and ApplePay) in PaymentElement and use ExpressCheckoutElement separately for those. That one supports setting your own line item(s) info and say if it's a trial

open trail Feb 9, 2024, 6:12 PM

#

If that's what we have to do then we will, but we were hoping to use the payment element because Stripe keeps saying that it produces higher conversions than any other combination, but it will be what it will be.

junior furnace Feb 9, 2024, 6:12 PM

#

I'm not saying to stop using it though

open trail Feb 9, 2024, 6:13 PM

#

Is it possible to disable all wallet elements?

junior furnace Feb 9, 2024, 6:13 PM

#

I'm explaining how to handle the wallets specifically but you would still keep PaymentElement

#

https://stripe.com/docs/js/elements_object/create_payment_element#payment_element_create-options-wallets

open trail Feb 9, 2024, 6:13 PM

#

Okay. That would most likely work for us for the short term.

#

Will try it out.

snow nimbusBOT Feb 9, 2024, 6:15 PM

#

junior furnace Feb 9, 2024, 6:16 PM

#

not perfect for sure but I haven't heard anyone say it's required to show trialing in the UI for GooglePay or ApplePay at least so I'm not sure you have to optimize for this either

open trail Feb 9, 2024, 6:18 PM

#

I mean we are very upfront on the payment page that it will be recurring and everything, so we want it reflected at all stages if possible.

#

Also, is it possible to hide all the wallet fields and just show the credit card fields in payment element (i.e. without it having the 'card' tab at the top). From the docs posted above, It appears that it can only disable apple/google pay specifically.

neon furnace Feb 9, 2024, 6:20 PM

#

Hi 👋

I'm stepping in as my colleague needs to go soon.

open trail Feb 9, 2024, 6:21 PM

#

Hello

neon furnace Feb 9, 2024, 6:21 PM

#

We have filed a feature request for displaying trialing messaging in wallet UIs. However, I cannot guarantee if/when it will get worked on

#

With respect to disabling wallets, you are correct that we currently only have options for applePay and googlePay in Stripe.js

open trail Feb 9, 2024, 6:22 PM

#

Yeah, he stated as much, so I'm trying to figure out the best way to proceed.

neon furnace Feb 9, 2024, 6:23 PM

#

Are there other situations where you want to display other wallet PMs?

#

A kind of "brute force" approach would be to disable the wallets in your account settings

open trail Feb 9, 2024, 6:24 PM

#

But if all wallets are disabled, does it still show the card tab?

neon furnace Feb 9, 2024, 6:24 PM

#

Yes

open trail Feb 9, 2024, 6:25 PM

#

So I believe that would be a bit jarring from a ui perspective.

neon furnace Feb 9, 2024, 6:25 PM

#

I'm not sure I follow.

junior furnace Feb 9, 2024, 6:25 PM

#

wait wait that's not true
if you only have one payment method type, such as only Card, we don't show the header

open trail Feb 9, 2024, 6:26 PM

#

If we show the express checkout elements above it, you have two very different design patterns right on top of each other.

#

We would also have a large amount of unused screen real estate next to where the card tab would be.

#

The express checkout supports the appearance api, but even it they ended up thematically similar, the spacing is still an issue.

#

Ah, okay then that is a different story.

#

if the card header doesn't appear, then we could possibly work with that.

neon furnace Feb 9, 2024, 6:29 PM

#

Sorry I'm trying to catch up on the full integration you are trying to build so I can answer accurately. @junior furnace is correct (it hought there were other PMs invovled). If the only valid Payment method is the Card PM, then we don't display the header (since you have not alternative PMs to select). We would only show the card inputs

open trail Feb 9, 2024, 6:31 PM

#

Okay, we may be able to work with that, though my only other issue here being that if we disable all of the PMs in the dashboard, wouldn't that prevent them from showing in the express checkout element?

#

Google Pay and Apple Pay are not the only ones we wish to support.

junior furnace Feb 9, 2024, 6:32 PM

#

ExpressCheckoutElement doesn't support every PM types. Sorry you might be going too fast and jumping to conclusion

#

You would have PaymentElement for all payment methods that aren't a wallet (Card, SEPA Debit, Klarna, etc.)
And use ExpressCheckoutElement for wallets (ApplePay, GooglePay, Link (+Paypal in Europe))

open trail Feb 9, 2024, 6:34 PM

#

So that is what I want to avoid, clogging up the UI like that, which really brings me back to one of my previous questions. How are subscriptions that have not had their intents confirmed treated?

#

Do they disappear after a certain amount of time, have to be cancelled manually, and in either case does that count towards cancel statistics in stripe's analytics

junior furnace Feb 9, 2024, 6:37 PM

#

that's what I explained earlier unfortunately

#

trials/$0 invoice will transition to active/trialing automatically and there's no way around it, and no automatic cancellation
we don't know anything about analytics on this server/team

open trail Feb 9, 2024, 6:42 PM

#

But for number one, that's only if I create the subscription for a trial. At this point I need to know for non trials as well.

#

Also, for the 2nd question, who can I reach out to for that information

junior furnace Feb 9, 2024, 6:45 PM

#

for #1 I explained how it works. If there is a payment upfront the Subscription will be incomplete and automatically expire after 23 hours.
For #2 you talk to support: https://support.stripe.com/contact

open trail Feb 9, 2024, 6:45 PM

#

Okay, will reach out to them. Thank you for your time.

#bernzjh-subscription-trial