#marka5187
upper stream
icy sentinel
Hi, I think you should be able to update the Subscription in questing using our Update a Subscription API: https://stripe.com/docs/api/subscriptions/update#update_subscription-payment_settings-payment_method_types. Specifically, when you make the update request you'd pass in payment_settings.payment_method_types which is a list of payment method types to provide to the invoice’s PaymentIntent. Are you able to try this?
worn sandal
Yes, I'll try that, but was hoping to avoid additional API calls on either the paymentIntent or subscription. And I'm actually already updating the payment method for the customer and subscription via Stripe.net API after confirmPayment, but either I wasn't sure it would work for this, or I did try (have tried so many variations now), and don't recall the result. I'll check this out too. Seems like the Payment Element should support these changes, since it's collecting new payment method detail and then having confirmPayment run on it afterward.
I'll report back if still an issue. Thank you.
Oh, and it looks like there was no mention of setup future use to off-session above? How about that part for the new payment method being setup from Payment Element?
icy sentinel
When you use Subscriptions, it sets up that payment method off_session by default so they can be used for subsequent payments.
worn sandal
OK, in some combination of my tests, I was able to pay with the new payment method (using the previous paymentIntent's specified payment method type), but the new payment method was not saved to the customer. I figured I need to set off-session. So still not sure why the attach failure.
icy sentinel
Can you share the request id please?
worn sandal
I believe this was one: req_1FsygjfMhEkuVc
icy sentinel
Here's how you can find a request ID: https://support.stripe.com/questions/finding-the-id-for-an-api-request
I think I know what the cuprit may be. When you created the Subsciprtion, it does not look like you passed https://stripe.com/docs/api/subscriptions/create#create_subscription-payment_settings-save_default_payment_method which sets subscription.default_payment_method when a subscription payment succeeds. When you create the payment method you already had a default payment method attached to the customer, pm_1NqSlEAUoPbSaQbfI1HK62Ft and epxlicitely passed it in.
worn sandal
Interesting. Yeah, I don't recall using that, but I do specifically set the default on the customer and subscription at subscribe time during the user trial. Perhaps I can swap the two(?).
icy sentinel
You can pass subscription.default_payment_method when you create the Subscription with the trial. I'm also testing some things on my end in the meantime.
worn sandal
What I have been doing when a customer updates a payment method, has been calling this , but doesn't look like I have the above at subscription create:
var subUpdateOptions = new SubscriptionUpdateOptions()
{
DefaultPaymentMethod = paymentMethodId,
};
Subscription stripeSubscription = _subscriptionService.Update(subscription.ExternalSubscriptionId, subUpdateOptions);
And this gets called with the above at payment method update historically in our code. Both of these at the same time, on subscription and customer:
var invoiceOptions = new CustomerInvoiceSettingsOptions()
{
DefaultPaymentMethod = paymentMethodId,
};
var addressOptions = new AddressOptions()
{
Line1 = address.AddressLine1,
Line2 = address.AddressLine2,
City = address.City,
State = address.State,
PostalCode = address.ZipCode,
Country = address.CountryCode
};
Customer stripeCustomer = _customerService.Update(externalCustomerId,
new CustomerUpdateOptions()
{
InvoiceSettings = invoiceOptions,
});
icy sentinel
On the first function, it looks you're setting the default payment method on the Subscription, and the second funcion is saving the pm_ on the customer's invoice settings. You likely do not need to call both but it's up to you.
worn sandal
Understood. I don't recall the use case for having both but it may have been at subscription switch or resubscribe, etc. It was intentional at the time. And seems somewhat related to this setting you've now suggested above as well.
worn sandal
Thank you
untold flame
Sorry this is a bit of an annoying flow unfortunately. Try setting https://stripe.com/docs/api/subscriptions/update#update_subscription-payment_settings-save_default_payment_method so that it properly attaches that PaymentMethod and make it the default on the Subscription
worn sandal
I'll do it going forward, but concerned about potential old payment intents where this may come up in the future.
untold flame
You should be able to update all your Subscriptions
You can also call the Update PaymentIntent API and set setup_future_usage (which is null by default)
worn sandal
ok, and it should update any existing paymentIntents, even if old/failed?
untold flame
Not sure, you'll need to test this thoroughly first. You can reproduce most of this in Test mode
worn sandal
Yep, makes sense. I'll try it. Thanks for the help.
untold flame
Unfortunately I have to run for the day but you can contact our support team if you have follow up questions: https://support.stripe.com/contact
We'll be back on Monday otherwise