mursk_subscription-creation

[full swift]

👋 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/1288568552076476447

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

[arctic tundra]

mursk_subscription-creation

When you create a Subscription with collection_method: 'charge_automatically', the first Invoice is created, finalized and paid all at once

[knotty zenith]

Got it, so there's no way around that. So would the only way to handle invoice advancement outside of Stripe be to use send_invoice?

[arctic tundra]

What are you really trying to do? Why would you create a Subscription at this exact second, if you don't plan to get the Invoice paid for multiple days?

[knotty zenith]

Sorry, I can provide some context. All of our subscriptions are managed in Stripe, but in some cases, we accept payment through PayPal, which Stripe doesn't support in the United States. So my goal was, on subscription creation, prevent the finalization of the invoice so that I can wait for the invoice.created webhook event and, when I receive that event, finalize the invoice, pay for it with PayPal, mark it paid out of band and get the subscription active.

What I have currently works, but the only thing that looks strange is the failed payment attempt that takes takes place because Stripe automatically creates a payment intent as it advances the invoice. Since the customer is using PayPal (not supported), they don't have a payment method and the payment fails.

[arctic tundra]

Use payment_behaviour: 'default_incomplete' which will finalize the Invoice but not pay it automatically in that case. That should work for your flow while you get the Paypal payment and then mark the Invoice as paid

[knotty zenith]

I have that set, if you follow the request ID provided through to the invoice and then the subscription, you'll see the subscription is incomplete because the request body to create it was

{
  "automatic_tax": {
    "enabled": "False"
  },
  "collection_method": "charge_automatically",
  "customer": "cus_QupObPWiSBKaH6",
  "items": {
    "0": {
      "price": "premium-annually",
      "quantity": "1"
    },
    "1": {
      "price": "storage-gb-annually",
      "quantity": "5"
    }
  },
  "metadata": {
    "userId": "9deb0af6-65fa-4a07-ae14-b1f6012c7a3d"
  },
  "off_session": "True",
  "payment_behavior": "default_incomplete" // here
}

[arctic tundra]

yeah sorry you did provide a request that was just auto_advance: false with nothing else so I'm answering based on the exact question you shared

So... I guess I'm back to being confused about your issue. The Invoice is not paid at that point so what's the problem?

[knotty zenith]

No problem, apologies for the confusion.

Ah wait, I think I may have confused myself. The payment I thought that failed that I was referencing is pi_3Q2zk8IGBnsLynRr1uWJ8AG8, but it actually looks like it's just incomplete. So if I pay the invoice using https://docs.stripe.com/api/invoices/pay then that payment should complete?

Or will it just be a different payment entirely and I can disregard that one.

[arctic tundra]

I want to say yes. Sorry you're using words in ways that is tricky

you say "payment" but seem to both mean the PaymentIntent and the Invoice being paid

The easiest would be to just try in Test mode to confirm

[knotty zenith]

Alright will do, thanks.

[arctic tundra]

But yes the Invoice will be marked as paid and the underlying PaymentIntent will be canceled in that case I think

[knotty zenith]

Cool, that makes sense. Appreciate your help.

[arctic tundra]

sure!