kt_unexpected

[loud totem]

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1230242642378625024

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

[vernal sleet]

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

• kt_code, 16 hours ago, 38 messages
• kt_code, 21 hours ago, 5 messages

[ebon yew]

Digging in now

So it looks like you're running into the same issue you had in your last thread from yesterday.

• One Subscription (sub_1P6dUoAFQUUIWEfkDe49XM6s) is set to charge a default payment method (e.g. Stripe checks the Customer object and the Subscription object for a default payment method and uses that, or else fails), but there is no default Payment Method set on either object, so it fails.
• The other subscription (sub_1P6dTlAFQUUIWEfkxXQBjWvM) is set to charge a specific payment method (e.g. the Subscription has a default payment method set so it succeeds).

So in your flow, you need to either:
a. set the newly added Payment Method as default on the Subscription by passing save_default_payment_method: "on_subscription" (https://docs.stripe.com/api/subscriptions/create#create_subscription-payment_settings-save_default_payment_method), or
b. set the newly added Payment Method as default on the Customer object via invoice_settings.default_payment_method (https://docs.stripe.com/api/customers/update#update_customer-invoice_settings-default_payment_method)

[violet scroll]

oh that's odd, we're not setting specific payment method vs. default payment method anywhere so not sure why the two subscriptions would have different settings
edit: we are setting default payment method: "on_subscription" for every subscription so not sure why they would be different

the same way that doc lays out, we're creating the susbcription with

      customer: customerId,
      items: [{ price: priceId }],
      pay_immediately: false,
      metadata,
      payment_settings: { save_default_payment_method: "on_subscription" },
      expand: ["latest_invoice.payment_intent", "pending_setup_intent"]
    }
}```

and then doing 
```stripe.confirmSetup({
      elements,
      clientSecret,
      confirmParams: {
        return_url: `${apphome}`,
      },
      redirect: "if_required"
    });```

with element options:
```{
    appearance,
    locale: locale.language,
    currency: locale?.currency,
    mode: "subscription",
    amount: state.totalDueToday,
    setupFutureUsage: "off_session"
}```

so why would we get 2 different results with the exact same setup for each purchase at checkout?

[ebon yew]

Where does the workflow for the 2 subscriptions diverge? Are you able to step through the code and identify the API calls that were made for each?

[violet scroll]

everything in checkout is exactly the same for both subscriptions, they're setup the exact same way.

the only difference I can see is the order of events on the two customers is slightly different after the subscription is created

on the successful customer, the invoice is updated with the tax line item (we use avatax), and then the card is added to the customer, then the setup intent succeeds, then payment intent created then charge succeeds (no failed webhook attempts)

on the unsuccessful customer the card is attached, then the setup intent succeeds, then the invoice is updated with the tax line item (this webhook event fails because we attempt to finalize the invoice and get the error There is no 'default_payment_method' set on the associated Customer, Invoice, or Subscription. Set a default on one of those objects, or specify the Payment Method you wish to use in the 'payment_method' parameter. ), then the payment intent is created but there's never a charge event (failed or success)

but like I said, not sure why these would look any different if both customers are going through the same flow in checkout with the same test payment method & same product

the failed webhook to finalize the invoice seems to be consistent among all of the failures but I can't figure out why it's happening or why it would lead to no payment method on the subscription (it fails to finalize with that webhook call but it does eventually finalize)

[ebon yew]

It sounds like maybe the order is the issue. It might be that Stripe is being helpful in the successful case by inferring that you intend to set the PM as default. Can you just update the code so that whenever a card is attached, it gets set as default on the Customer object?

b. set the newly added Payment Method as default on the Customer object via invoice_settings.default_payment_method (https://docs.stripe.com/api/customers/update#update_customer-invoice_settings-default_payment_method)
This method specifically

[violet scroll]

looking at other failures on test users, the order of events doesn't seem to matter, the failures seem totally random

and how would setting the payment method work with this setup https://docs.stripe.com/payments/accept-a-payment-deferred?platform=web&type=subscription#confirm-the-subscription
because you're not actually creating a payment method anywhere, I thought elements and confirmSetup was supposed to handle that

[ebon yew]

Huh... yeah good point. That's confusing. I see that "save_default_payment_method": "on_subscription" is literally included in both Subscription creation POST requests, so why is it not being set on one versus the other?

Let me grab a fresh set of eyes. The server is a little busy and I'm getting tunnel vision.

[violet scroll]

cool, no worries. appreciate having someone else say it's confusing because I feel like I've been going insane looking at this haha

[ebon yew]

Haven't forgotten about you. Still digging in with a colleague

Okay, we have a theory that might work. It's possible that this is actually just a race condition where in some cases your integration attempts to finalize the Invoice before Stripe actually updates the Subscription with a default Payment Method.

So a solution that might work would be to wait for the customer.subscription.updated webhook Event to trigger showing that the default_payment_method was updated before you try to finalize the Invoice.

If you want to try something a little easier for a proof-of-concept, you could try adding a sleep function after the Subscription is created

I'd recommend a 5 second sleep function, just to ensure everything clears out, but obviously that might not work if the workflow isn't totally serialized

[violet scroll]

hmm yeah I considered that too but didn't dig in too much since the order of events on failures is pretty random, but I'll do some messing around and see if that's the cause

how long do I have before this thread gets auto closed?

[shrewd iron]

Hi, stepping in. I'm happy to keep it open for a bit. If it's closed, you can write in again from the help channel.