Subscription creation request fails with customer credit balance (or 100% coupon)

[Gidgidonihah]

Bug report

In a situation where a subscription is immediately marked as active, rather than incomplete (e.g. the customer has an account credit balance or uses a coupon that gives 100% off) a customer can't obviously complete a subscription or add a credit card.

Describe the bug

I've only tested this with the fixed-price-subscriptions example (which is the same situation as I need), but assume the same problem exists in others.

When a subscription is created (especially with payment_behavior: 'default_incomplete') and the invoice does not require payment (the customer has a credit balance > the cost of the invoice, or the subscription was created with a 100% coupon) the invoice is marked as paid, and the subscription is created in active status, rather than in incomplete status.

This results in a 500 error when the server tries to get the client secret (subscription.latest_invoice.payment_intent.client_secret) since one does not exist. This gives the customer an active subscription, but they aren't able to add a payment method and at renewal, the subscription is broken for them.

Worse yet, it also isn't obvious to them that this is the case. A customer might click the Select button multiple times seeing it not work, and each time a new active subscription is created. At the end of rage clicking, the customer has 10 active subscriptions, no idea that any of them exist, and a no way to continue signup.

Obviously this example doesn't allow us to enter coupon codes to test that scenario, but we can with the account balance. Also regarding coupons, the readme shows coupon support for all examples, none of the examples actually support it. Should probably file that as a separate issue.

To Reproduce

Steps to reproduce the behavior, please provide code snippets or a repository:

1. Run the fixed-price-subscriptions example with any backend (Tested with React and Ruby)
2. Create a customer
3. Find the customer on the stripe dashboard
4. Chose Actions and Adjust credit balance
5. Give the customer a balance greater or equal to the cost of a premium subscription
6. Click on a price (basic, or premium)
7. See problems:
   • 500 error in network console
   • no credit card form to fill out
   • active subscription on the customer in stripe dashboard
     • multiple if they rage clicked

Expected behavior

Honestly, I'm not sure. I think MY expected behavior would be for the invoice to not be paid if we've asked for a payment_intent, but that isn't what the docs say should happen.

Maybe just handle the error and give a setup intent instead so that the payment method can be added? But that leaves us with the fact that it's seems super weird that the customer would have an active subscription after only clicking on the price. It's also not clear to the customer that this would be the case.

Better yet would be an explicit example of how to handle this scenario.

Screenshots

None.

System information

• OS: Any
• Browser: Any
• Server environment: Ran in Ruby, but verified via code in all.

Additional context

Basically I haven't found the "correct" way to handle these scenarios and if anyone follows this example, these same scenarios will be broken for them.

"This is a brand new customer. Why would the customer have a balance?" you might ask. Sure, in this example it tends to be. But what if the customer wants a 2nd subscription for a different product? What if the customer didn't sign up, called customer support and got offers a free month? What if...

"Why would you use a 100% of coupon? Just use a trial period..." Sure. That could also work. But how is that implemented? What if we don't ever offer trials, and we just want a specific person to have a free month. Isn't that what coupons are for? What if we want to allow our QA department to sign up without "paying" for the account, but also want to see the subscription go through it's various lifecycle events? What if...

[hideokamoto-stripe]

@cjavilla-stripe
We may need to consider a new example case to support this case.

e.g.) register-card-before-subscribe

These steps will work well for this case:

Step1: Register payment method

• Create a new Setup Intent
• Show the PaymentElement form
• Customer save their payment method

Step2: Start a new subscription

• List the Prices and Products
• Customer chooses the price
• List their saved payment methods
• Customer chooses the payment method
• Create a new subscription

In this workflow, we don't have to create and use a Payment Intent on the subscription creation step.