Add stripe_product to subscription_items table

[hailwood]

The Issue

Right now there's no way to tell what products a billable is subscribed to. For example a user signs up for a subscription (prod_A) at $89.99/mo (price_A) + an optional second plan (prod_B) for $19.99/mo (price_B).

In the app we have calls to $billable->subscribedToPlan('price_B') to check if they're also subscribed to the additional plan.
But then Mr CEO wants to change the price for prod_B for new subs to $21.99 (price_C)

This means we now need $billable->subscribedToPlan(['price_B', 'price_C']) when really all we want to know is "are the subscribed to prod_B - we usually don't care what price they're paying at that point.

Suggested Solution

• Add stripe_product to the subscription_items table
• Add subscribedToProduct(string|array $products, string $name = 'default'): bool to the billable model
• Add priceIdForProduct(string $product, string $name = 'default'): string to the billable model
• Update findItemOrFail to check stripe_plan and stripe_product

That last point will allow things like

$billable->subscription()->reportUsageFor('prod_B');

[driesvints]

@hailwood I've thought long and hard about this when working on #956 to replace the stripe_plan columns with a striped_product column. The way Stripe intended products to work was indeed the way you described. That a single tier (basic) is a product and all of its prices (monthly/yearly) were gathered under it. Another tier (premium) would then be a separate product. That way you could indeed just do the checks on product ID's rather than price ID's.

The problem however is that the terminology in Stripe is misleading and people think a product is the actual SaaS app (I thought that too before someone explained to me). So people are constantly mis-using this system by placing ALL tiers under the same product. That way you cannot check a product ID to see if you're on a certain tier. In combination with price_id's being an equivalent of the legacy plan_id's people upgrading from older cashier versions don't have the luxury of migrating to the new system.

Because of all this I've decided to keep the stripe_price column and not go for the stripe_product column. I agree, checking multiple price ID's is cumbersome and having to support old ones is a hassle. But if we changed to stripe_product now that would be the single biggest breaking change that Cashier has ever seen and people upgrading from old versions would have a tremendous upgrade path that involves creating new products, migrating customers, etc. We don't want to make them do that.

For now the stripe_price checks work fine although cumbersome. That's why we won't be making any changes to the way this all works. I know that Stripe is very aware of all this and that they're considering making some changes to the entire system to make it more easier to work with. I'm going to await to see what they're going to do before revisiting this.

Thanks for your issue.

[driesvints]

@hailwood I've been pondering about this during the weekend and decided to give this a go in Cashier v13. I've sent in a PR for this here: #1185

Your use-case for priceIdForProduct & findItemOrFail isn't possible however as Stripe subscriptions can have multiple items with different prices of the same product. So we wouldn't be able to fetch a price for a product in that situation.