gucci-subscription-defaultpm

[fallow spear]

So, our app is service we are offering subscriptions to (duh). The test case I ran into was this: if a user abandons the signup flow before they purchase a subscription, we create a customer for them and attatch the ID to the user in our DB. That way, if the unsubscribed user comes back to the site, they are prompted right away to pick a subscription and enter payment details.

this is the user I'm testing with: cus_OHT7ow7POiJ2g4

here's a link to their logs: https://dashboard.stripe.com/test/customers/cus_OHT7ow7POiJ2g4

[full bough]

HI 👋

Dashboard links aren't helpful here

[fallow spear]

do'h

apologies

[full bough]

You can stick with just the IDs

that's enough for me

[fallow spear]

👍

[full bough]

Okay so the Customer is created but no Sub yet

[fallow spear]

what I did was:

1. sign up
2. not finish the payment details
3. got routed to our "you forgot to finish signing up" page
4. picked a subscription and generated the invoice for it
5. entered payment details. This is then set as the default payment method for the user: pm_1NUuC4AKr8gWA65AAHLIu3QE
6. Then, when I tried to update the subscription, I was met with a Stripe error: req_hTHfdYUA9tIqi2

I understand the nature of the error

I don't understand why the user's default payment method isn't used as a fall back...

my understanding is that Stripe is going to try and look for a payment method assoc. with the intent generated by the invoice, then will look at the user's default payment method if there isn't one assoc. with that specific intent

I know this is a little all-over the place in terms of an explaination, I guess I feel like I'm just missing something at a "high level" of how Payment Methods get matched up with invoices for subscriptions

[full bough]

don't understand why the user's default payment method isn't used as a fall bac
I'm not sure what is going on here. The request you linked is about adding a new subscription item

Since you create a Subscription and invoice before they have a payment method, you need to be more explicit

Stripe looks for the default paymemt method when you create the Subscription

[fallow spear]

interesting... I'm looking at our server-side code to confirm that we're updating the subscription correctly

okay, I think I see the issue... I think we are updating subscriptions correctly, but the scenario I've created here is attempting to create a new subscription

our "update subscription" code looks like this:

const updatedSubscriptionItem = {
                    items:[{
                        id: currentSubscription.items.data[0].id,
                        price: priceItemId,
                        quantity: normalizedQuantity
                    }],
                }
...
const updatedSubscription = await this.stripe.subscriptions.update(currentSubscription.id, updatedSubscriptionItem)
``` does this look the recomended way to change subscription plans?

[full bough]

This will add a new item to a Subscription. But that isn't enough context here.

You can't update the subscription if it's still incomplete, like the error says

IF you want to add items to the subscription before the customer pays for it then you should create the subscription with the items in it

[fallow spear]

okay, after looking through our code a bit more and running some tests, I guess the question I'm trying to ask here is: why isn't the invoice resolving after the payment details get added to the user... if I delete the subscription, but leave the default payment method attatched to the user, then re-subscribe, I hit the same bug... do I need to set auto_advance to true when the subscription is first created?

[full bough]

Let's back up a bit. When you create the Subscription for the Customer and it generates an invoice, are you using that payment intent to capture the users payment method details?

[fallow spear]

yes, although this might be where the issue is stemming from: the signup flow passes along the intent to the payment details, but if the user abandons the flow and returns, that intent is not retrieved. Instead, we ask the user to input their payment details and then set those as a default payment method on their account, which we thought could be used as a fall-back method when they do create their subscription

but if they attempt to purchase before setting default payment methods... that might be the source of my issue

[full bear]

That's possible. I think the next step is to add clear logs to your flow to figure out the order of things and what exactly is missing at which exact step

gucci-subscription-defaultpm