foca | Stripe Developers | Page 1

shadow onyxBOT Nov 18, 2022, 2:17 PM

#

grave gull Nov 18, 2022, 2:21 PM

#

Ultimately, what we want is for the ApplePay flow to just show $0.00 (or for subs that don't have a trial period, to show the amount of the first payment—though we're not planning on offering non-trial subs at the moment.)

sleek zinc Nov 18, 2022, 2:29 PM

#

Hello, do you actually have this flow implemented? Some of this description does not gel with my understanding of how Subscriptions work in Stripe

grave gull Nov 18, 2022, 2:33 PM

#

Yes.

We have the first flow in production (SetupIntent => render form using the client token => create a subscription on the SetupIntent's callback).

And we have a development branch implementing the second flow (create subscription => grab the latest invoice's payment intent's client token => render form).

#

In this development branch, we're observing the subscriptions coming as active immediately.

#

This is how we're creating the subscriptions, BTW, using Stripe's ruby library:

Stripe::Subscription.create(
  customer: stripe_customer_id,
  metadata: { user_id: current_user.id },
  items: [{ price: stripe_price_id }],
  trial_period_days: trial_days.present? ? trial_days.to_i : nil,
  payment_behavior: 'default_incomplete',
  payment_settings: { save_default_payment_method: 'on_subscription' },
  expand: ['latest_invoice.payment_intent']
)

sleek zinc Nov 18, 2022, 2:35 PM

#

Can you send me an example ID of a subscription that you have done this second flow with?

grave gull Nov 18, 2022, 2:36 PM

#

sub_1M598rBQtDRDx8wl2BXcbnzt

sleek zinc Nov 18, 2022, 2:36 PM

#

I am a bit confused because trialing subscriptions will be in a trialing state, not active, their first $0 invoice won't have a payment intent, and the payment sheet should not automatically close without the custmomer's consent

#

That last part is especially worrying. Will definitely set off alarm bells if I can confirm that behavior

#

I don't even know if that would be our code

grave gull Nov 18, 2022, 2:37 PM

#

Not sure what you mean by the payment sheet closing.

sleek zinc Nov 18, 2022, 2:37 PM

#

Sorry that last part isn't relevant now, confirming that is the goal any which way

#

Ah I think I misunderstood your last paragraph

#

For example, would a previous customer who churned and is renewing get their previous payment method automatically attached to the new subscription? How do we prevent that to avoid rendering the form from automatically creating a subscription that will charge customers without their consent when the trial period expires?

#

Can you explain how users are getting signed up without their consent?

grave gull Nov 18, 2022, 2:40 PM

#

Sorry if that wasn't clear, this is a hypothetical. My concern is whether someone who already has a Stripe customer from a previous subscription, which has an up-to-date payment method attached as their default payment method, would get that payment method attached to the subscription automatically when creating it.

#

But again, that's not even the core problem right now, just me trying to figure out what all the edge cases are if we were to create the subscription to gather the payment details.

#

(And you're right that the status of the subscription is trialing not active, but when we get the customer.subscription.created hook—the problem is that the subscription never goes through a pending state, and so we have no easy way to identify whether we should give access to content to a subscriber)

sleek zinc Nov 18, 2022, 2:53 PM

#

Sorry if that wasn't clear, this is a hypothetical. My concern is whether someone who already has a Stripe customer from a previous subscription, which has an up-to-date payment method attached as their default payment method, would get that payment method attached to the subscription automatically when creating it.
Gotcha, thank you for clarifying. This will kind of happen in effect. If the customer has a payment method attached and set as their default, the subscription will try to charge that payment method when it requires payment. So in this case, the subscription should not be created until the user has consented to pay.

#

And so to clarify, the edge case we are talking about is mostly presenting the actual amount to the user on that initial Apple Pay sheet?

grave gull Nov 18, 2022, 2:54 PM

#

Yep 🙂

#

The whole creating a subscription before was a workaround that we saw for that. But it clearly has some pretty dangerous edge cases that will require us to be super careful about.

sleek zinc Nov 18, 2022, 3:08 PM

#

Hey just a heads up, I am pulling in a colleague to help on this thread as the server is a bit too busy for jus me right now. I am trying to think of how you can make sure the subscription doesn't start too soon but my colleagues will likely be able to help you before I can

pseudo current Nov 18, 2022, 3:11 PM

#

👋

grave gull Nov 18, 2022, 3:11 PM

#

Thanks! I will be in an our of meetings for the next few hours, so my replies might be a bit delayed, but I'll definitely be paying attention and appreciate the help 🙂

pseudo current Nov 18, 2022, 3:14 PM

#

Just to check, your original question was about the amount pending UI in the apple pay payment sheet, correct?
Broadly, this is normal when setting up a card because the exact amount isn't really known (you might discount later, or they might upgrade).

You have some other questions about new subscriptions for an existing customer etc, and want to make sure we focus in the right place.

grave gull Nov 18, 2022, 3:20 PM

#

Just to check, your original question was about the amount pending UI in the apple pay payment sheet, correct?

Correct.

I understand this is how a SetupIntent works, but we've seen this flow to create a subscription with a trial show $0.00 on the Apple Pay sheet, so we know there's a way to get there—likely not using a SetupIntent the way we are 🙂

Our question is "how do we get there?"

#

For example, our other subscription app uses Stripe Checkout, and when we go through the Checkout flow for a sub with a trial period, the apple pay sheet says "$0.00", not "Amount Pending".

And we've seen other companies do similar with internal forms (that presumably use stripe elements)

pseudo current Nov 18, 2022, 3:57 PM

#

I'm happy to share feedback internally around this, since I think it'd be great if there was a way to present more specific information to the customer. But I believe our guidance would be to communicate future amounts to your customer prior to them proceeding with setup. Really you don't know the actual amount unless you're taking immediate payment, so "pending" is the most reliable.

#

Actually, after a bit more digging, it looks like there is support to provide paymentSummaryItems in the ApplePayConfiguration within the Payment Sheet configuration:
https://stripe.dev/stripe-ios/stripe-paymentsheet/Classes/PaymentSheet/ApplePayConfiguration.html#/s:18StripePaymentSheet0bC0C21ApplePayConfigurationV19paymentSummaryItemsSaySo09PKPaymentH4ItemCGSgvp

An array of payment summary item objects that summarize the amount of the payment. This property is identical to PKPaymentRequest.paymentSummaryItems. If nil, we display a single line item with the amount on the PaymentIntent or “Amount pending” for SetupIntents. If you’re using a SetupIntent for a recurring payment, you should set this to display the amount you intend to charge, in accordance with https://developer.apple.com/design/human-interface-guidelines/technologies/apple-pay/subscriptions-and-donations

#

I think this is where you want to look

#

If you know those pending amounts, you should be able to specify them there

#

I don't have an ios app set up to test this myself at the moment, but this sounds like what you need to try

#foca