#wasabi-billing-cycle-anchor
fringe bluff
placid ferry
- What happens to a subscription if the billing_cycle_anchor param is not used? How might this impact other events?
fringe bluff
@placid ferry billing_cycle_anchor lets you control when to anchor the billing. So if you don't pass it it just defaults to "now"
placid ferry
I see. So if the goal is to invoice the customer at the start of the billing period. It's not required to anchor the billing cycle as the default is now = immediately, when a customer purchases a subscription. Therefore, invoice will fire immediately as well. Did I get that right?
fringe bluff
exactly!
placid ferry
thank you!
- The use case is that we want to provide the ability for the customer to update their payment when a subscription in active. In this scenario, Stripe has recommended to use SetupIntent API. However, our user is more interested in using payment method API to update the payment, and save that on the customer object. The reason behind this is that they prefer to keep their logic flow consistent using PaymentIntent to create a subscription. I would like to know a) is it possible? b) if there are any tradeoffs between using payment method vs. SetupIntent to update a customer payment.
fringe bluff
It feels like you might be mixing up many concepts together that are unrelated
If you have a Subscription that charges on the 10th of the month, it just creates an Invoice on the 10th each month
if someone wants to change their card on the 17th, there's nothing to pay here
So in that case you create a SetupIntent just to collect card details and do 3DS if needed, that's just the normal integration path
placid ferry
Thank you for clarifying @fringe bluff . The question here is it possible to call Payment Method api to update the payment and save that to a customer that is attached to a paymentIntent?
fringe bluff
It doesn't really make any sense
What customer would be attached to what PaymentIntent? There's no PaymentIntent when you just want to update a card mid month
placid ferry
In this scenario, the assumptions are that, a Customer is already on a paymentIntent. If we update the payment method object, attached with a customer that already attached to that PaymentIntent. Would that be the same as making a setupIntent call?
fringe bluff
That really makes no sense as a question unfortunately 😦
If we update the payment method object, attached with a customer that already attached to that PaymentIntent
those words specifically don't make sense to me.
placid ferry
You are right, there would be no PaymentIntent when updating a payment method object., then attached to a customer. Let say if following this flow, when a subscription for this customer renews, call the PaymentIntent on this customer. Would this logic works as using SetupIntent?
tacit basin
If you want to collect a new payment method for a customer (for example to swap the payment method used for an existing subscription), then yes a setup intent is a great way to do that
When the setup intent succeed, you can used the payment_method from it to update the subscription default_payment_method or the customer invoice_settings.default_payment_method as appropriate for your application
placid ferry
Thank you @tacit basin ~ to confirm, the logic I outlined is not possible or it's not recommended?
tacit basin
Which logic, specifically? Can you quote it?
placid ferry
To update a payment for an existing subscription. Can user call payment method object to update it., then attached to a customer. Let say if following this flow, when a subscription for this customer renews, call the PaymentIntent on this customer. Will the PaymentIntent produce a charge on the updated payment?
tacit basin
That sequence does not make sense, so "possible" is a bit moot
At a high level, what are you trying to do?
Replace the payment method used to pay for a subscription?
You can only update limited details about an existing payment method, specifically for cards the expiry date or billing address: https://stripe.com/docs/api/payment_methods/update#update_payment_method-card-exp_year
placid ferry
Yes. The goal is to allow a customer to update their payment (card number, expiration date, cvc) on an existing subscription. Then, able to use that updated payment on their renewal subscription.
tacit basin
OK, and do you want to build this in your app with a custom flow, or use Checkout to collect those details?
placid ferry
The user will be using element js in both web and mobile
To confirm, using payment method object to update. You cannot update the card number? Or can you pass in a card number param to update?
tacit basin
No, you cannot update the card number, you'd be collected a new payment method, which is perhaps where your confusion comes from
You'll want to follow this guide to collect the new payment method with a setup intent: https://stripe.com/docs/payments/save-and-reuse?platform=web#web-create-intent
placid ferry
Thank you for confirming. That's where I needed the confirmation whether it was even possible to use Payment Method
tacit basin
You're still using payment methods, you're just not updating and existing payment method
After you collect the new payment method with the setup intent, make sure you set it to be the default payment method for paying the subscription invoices: https://stripe.com/docs/payments/checkout/subscriptions/update-payment-details#set-default-payment-method
placid ferry
- The goal here is to migrate existing customers on to stripe by asking them to update their payment info in the existing systems outside of Stripe. Then, use that info to create a subscription in Stripe. What is the best way to implement this in Stripe? An option we are exploring is using the trial end date on a subscription. What is the best way to ensure the customer renews into a paid subscription if we do this?
tacit basin
You may be able to get some support migrating that data in initially: https://stripe.com/docs/security/data-migrations/imports
So clarify you needs for that, you should reach out to support:
https://support.stripe.com/contact
But if you have the payment method or will ask customers to enter them, then yes you can use a trial period with trial_end to set when you'd like the subscription to start charging your customer
placid ferry
The user does not want to migrate data. They want to build a custom UI asking customers to update payment method. Then, create new subscription in Stripe following the custom UI path.
To confirm, Create a subscription with a trial end date will indicate when the customer will be charged on a subscription. Here, the user would pass in the product & price for the paid subscription, and with the trial end date, it won't start to charge until that trial ends?
tacit basin
Correct. At the start of the trial a $0 ("non-payment") invoice will be created, but a real one for the amount controlled by the Price won't be generated until the trial ends.
placid ferry
Thank you!!
tacit basin
NP! Very welcome 🙂
placid ferry
🙂