#LBG-events
grave ember
Hi, looking to this test event : evt_1KnikRLJLkeHRLt1VJs3TrOO
Why is there a "plan" and a "price" key in the event items.data key ? What is the difference between those 2 ? They have the same id ?
The "plan" key is duplicated" in the object key as well
gray geyser
basically Price is a new(well, since 2019, so new-ish) object that replaces Plan
Plan is still included in the object so that older intergrations using the Plans API are able to still work with the event and not break. It's the same information in both plan and price, just formatted differently. It's for backwards-compatibility.
grave ember
Ok so I should use "price" then
gray geyser
yep!
grave ember
Other question: we are using Checkout Session in subscription mode to create a payment_method and a subscription. The subscription created uses the payment_method created at the same time. How to update the payment_method (card) on the customer object AND the payment_method on the subscription object in a SCA way ?
Do we have to create a Session to update the payment_method so the customer can CONTINUE to pay his subscription ?
nimble kelp
HI 👋 just to clarify, you're asking if in the future a customer needs to update their payment method, what flow you can build for that?
grave ember
Hi @nimble kelp. Yes, knowing that there is a subscription using this payment_method
nimble kelp
Perfect, there are a couple ways that you can do that.
This guide walks through using Checkout:
https://stripe.com/docs/payments/checkout/subscriptions/update-payment-details
Or, you can look into using the Customer Portal (I need to double check whether this automatically updates a customer's subscriptions, or if that still needs to be handled manually).
https://stripe.com/docs/billing/subscriptions/integrating-customer-portal
grave ember
Ok, give me a moment to check on those links please
nimble kelp
Sorry for the delay while I tested. The Customer Portal flow that I tested did also update the default payment method for a customer's subscription, that had a default payment method explicitly set previously, if the "Use as default payment method" checkbox was checked.
grave ember
Ok, I'm running some tests
While I am running some tests I have another question. For the subscription I already mentioned, we are using a Volume pricing, with tiers. What is the best way to upgrade or downgrade the tiers of the subscription in a SCA compliant way ?
neon trail
Updating a subscription like that probably won't cause the user to need to re-authorize by themselves
Updating your subscriptions won't throw any new scenarios at you. As long as you are otherwise collecting card details via our SCA compliant products, you will be okay
grave ember
What do you mean by "Updating a subscription like that" ?
Do you mean updating the tiers by updating the quantity ?
neon trail
I was referring to any kind of change that affects the monthly recurring price. I thought your question was mostly about if updating subscription quantities has SCA implications.
If you are referring to this kind of tiered pricing, then yes https://stripe.com/docs/products-prices/pricing-models#tiered-pricing
Are you unclear on how to change the quantity, or are you referring to some other kind of update?
grave ember
This is what we use. Yes my initial question was does updating quantity could have SCA implications ? Like a new SetupIntent to complete or something else ?
neon trail
No, it does not have SCA implications. It is ultimately up to a bank when to ask for 3DS authentication, but they don't know when you make a Stripe call to update one of your subscriptions.
Like it could be possible that on the next payment, the bank will ask, but we already reccommend that you are ready to respond if a bank asks for SCA auth on any recurring payment so you will hopefully have that path covered already.
Is your integration currently set up to ask your users to re-authenticate on recurring payments?
grave ember
All the bank will see is the difference in the payment price, going from 29€/month to 99€/month might trigger a SCA on the issuer side indeed
Well, seeing all our current issues with SCA, I don't think we cover the re-authentication on recurring payments
Do you refer to this :
neon trail
Yes, that is the easiest way to do it. If you have that setting turned on, you should be covered in this scenario.
If you have that on, as the setting indicates, we will reach out to your users to do 3DS confirmation if a payment requires it.
grave ember
Do you confirm that the Radar Rules are correct for re-authentication on recurring payments ?
(It's by default I think)
neon trail
Unfortunatley I am less familiar with Radar. You can reach out to our support team for that question, they can better address whether those rules will suit your needs https://support.stripe.com/?contact=true
grave ember
Ok, we'll do our own reminder for all failed payment by sending a custom mail with invoice_url anyway
In our current integration, we first create a Session in setup mode to save the customer's credit card as a payment_method. Then, the user can navigate on our front to choose a subscription. Once chosen, we create a subscription on the customer's. Unfortunately we missed the setupIntent completion in our integration (sample: seti_1KkdXRLJLkeHRLt1NjAADvIj)
I guess this SetupIntent is to set the payment_method as off_session, potentially requiring the user's consent with a new SCA authent
We are currently migrating to a Session in subscription so to create the payment method AND the subscription at the same time. We cannot create a Session with payment_intent_data.setup_future_usage = off_session when using a mode = subscription
Do you confirm that Stripe automatically set it as off_session as the mode = subscription ?
plush sonnet
Hi 👋 I'm stepping in for @neon trail Give me a minute to get caught up
grave ember
Hu @plush sonnet
Other question : what is the best webhook event to catch to access to the new payment_method information following a Checkout Session ? checkout.session.completed ?
Or maybe payment_method.attached or payment_method_updated ?
plush sonnet
Hmmm ... 🤔
Checkout sessions will generate the checkout.session.completed as well as payment_intent.succeeded and charge.succeeded events.
What payment method info do you need to extract?
grave ember
id, card brand, expiring year, last 4 digits, etc.
plush sonnet
In that case, the Charge object returned in charge.succeeded will have that data without requiring additional API calls
grave ember
OK et me try this, thanks
grave ember
Do you confirm that Stripe automatically set it as off_session as the mode = sub...
What do you think about this ?
plush sonnet
What is the "it" here? This does not make sense to me
grave ember
I refer to the setup_future_usage for the payment_method created with the Session in mode subscription
plush sonnet
Do you have a request ID for the Checkout session creation?
grave ember
Is this this event ? evt_1KnmkkLJLkeHRLt1dtL0bCWH
I create the Session manually and copy paste the url to a browser to complete the flow
plush sonnet
Here's how you can find a request ID: https://support.stripe.com/questions/finding-the-id-for-an-api-request
grave ember
There is is field in the SetupIntent I sent you
plush sonnet
Request IDs start with req_ and it would be a big help
plush sonnet
Thank you!
grave ember
If I am not mistaking, this Session (req_W5audkJzqBDPQS) creates a SetupIntent (evt_1KnmkkLJLkeHRLt1dtL0bCWH) with usage = off_session
So that would set the payment_method in off_session mode, no ?
plush sonnet
That is correct
grave ember
Perfect
What happens if we use a card configured for off_session for on_session payments ?
(with StripeJS confirm payment flow)
plush sonnet
Do you mean the same card numbers or passing the actual payment method ID?
grave ember
payment method id*, sorry, all our payment_methods are credit cards
plush sonnet
How are you passing the ID in this case? What API calls are being made?
grave ember
The customer has to pay his platform subscription, off_session, just like seen previously. But he has to be able to create direct charges to a Connect Standard Account, always on_session. To do this, we create the platform customer on the Standard Account if it does not exists already (clone of the Platform Customer), then we clone the Platform Customer payment_method_id and create a payment_intent between the cloned Customer (on the Standard Account) and the Standard Account using the new payment_method_id created (the clone)
(With StripeJS Confirm Payment by payment method : https://stripe.com/docs/js/payment_intents/payment_method)
Hope I explained well
plush sonnet
Hmmm...
No I see what you mean. The cloned payment_method object was created with off_session: true but now the ID is being used for an on-session payment
grave ember
Yes
Does this affects the original payment_method_id ? Will it stay in off_session mode even though its clones are being used on_session ?
plush sonnet
Okay okay okay. I get it now.
Despite being called a "clone", there is no actual relationship between the payment method created on the Platform and the Standard Account. Each is a separate entity
So doing something with the "clone" won't impact the original
Does that simplify things?
grave ember
In that case, the Charge object returned in `charge.succeeded` will have that da...
Meanwhile, I was doing some tests on this, and unfortunately no charge.succeeded event was generated. But, I can use payment_method.attached to get all the payment method information I need
plush sonnet
Ah sorry, at the time I was writing that I was thinking you were using Checkout in payment mode
grave ember
No worries, do you agree with the fact that payment_method.attached is the best event to catch payment method information after a Checkout Session in subscription mode OR in setup mode (the customer is updating his payment method) ?
plush sonnet
Yes that is a good event to listen for since it will cover both uses of the Checkout Session
grave ember
Ok thank you so much for all the information you provided with your pals, huge help
I'll work on the work flow to update the payment method and will come back to you if needed
rose path
👍