Working with cashier

[RTC1]

Great project, thanks for making it open source.

What is the recommended process for working with Cashier - is there any way to create a newSubscription on a connected account? Or is that not something this project addresses?

[lindyhopchris]

Hi! So I'd definitely like to get this working with Cashier... i.e. provide a very similar interface for it. My main requirement though is that you shouldn't have to install Cashier, i.e. we just need to make sure any support we put into this package for Cashier doesn't cause any problems if you don't have Cashier installed.

I'd definitely need help working on Cashier integration because it won't be a priority for me as we're not using Cashier (at the moment).

I'd also prefer to integrate Cashier v10 when it is out, as I don't see the point of writing stuff now for Casher v9 when it is imminently about to undergo a major change.

Would you be interested in helping out with dev'ing Cashier v10 stuff?

[RTC1]

I can probably spare some time.

Just had a look at the Cashier code and it doesn't appear that extendable. Wondering if it may be possible to hijack the call outside of Cashier in the Stripe package. What are your thoughts?

[lindyhopchris]

I'll have to take a look into the code and get back to you. If it isn't that extendable, then maybe we just put a Cashier-like interface into this package that takes care of Connect subscriptions in a familiar way. Will take a look though and see what we could potentially do.

[RTC1]

Is it worth forking cashier, and then including this package + the connect account id functionality?

[lindyhopchris]

It's an idea but I'd prefer to avoid that as it'll be a nightmare to maintain.

How about an interface like this:

$account->newSubscription($user)->create($token);

I.e. calling newSubscription() on the user will use your application's Stripe account (as per normal Cashier usage), but calling it on the account model will create one on that account, for the supplied user?

Then within the account's newSubscription() method we can return the builder class that Cashier's newSubscription method returns... but with the account_id set as an option. That way we re-use the Cashier interface for consistency.

You know Cashier better than me - are there any other integration points you'd need for subscriptions on a connected account? I'd think we'd also need to link the account model to the subscription model, but we could use Connect webhooks to do that I'd reckon.

[RTC1]

My main concern is all the SCA stuff. That's my reason for going back to Cashier from a custom solution I've written.

[lindyhopchris]

Yep makes sense - that's exactly why I'm making changes to my Stripe integrations at the moment.

So there don't appear to be upgrade docs yet for v10, and the Laravel Cashier docs don't seem to be updated yet.

You're going to have to give me a steer on how you want this to work though, as I don't use any of the subscription stuff on Connect accounts - my implementation is all one-off payments where we collected credit card details via Stripe Elements at the point of purchase.

I'm assuming you want some sort of version of the Billable trait?

The first problem to solve is that Cashier uses columns on the user model, and assumes that user has one stripe_id - i.e. the stripe_id in your own application's Stripe account.

So we probably need a table to hold the user information that represents that user in a connect account. I.e. these columns:
https://github.com/laravel/cashier/blob/master/database/migrations/2019_05_03_000001_create_customer_columns.php

But on a separate table that has a user_id and account_id to create the link between a user model and a connected account model (provided from this package). Maybe this table is called billable_users, so the model is BillableUser.

Then effectively the BillableTrait (or our equivalent of it) is on that BillableUser model? A lot of the Cashier classes take a $owner model, which in our case would be a BillableUser model.

We'd then have a version of this table:
https://github.com/laravel/cashier/blob/master/database/migrations/2019_05_03_000002_create_subscriptions_table.php

But user_id in that table would be the id of the BillableUser. Plus it'd need an extra column for account_id to link to the Stripe account model from this package.

I'd suggest this should be a separate table to subscriptions to separate it out from subscriptions on your application's Stripe account. Maybe the table is called connect_subscriptions?

Then you'd presumably need to use Cashier's webhook controller (at least for the moment, unless we can convince them to separate out some of the logic in there so we can call it separately). We'd need to overload this method:
https://github.com/laravel/cashier/blob/master/src/Http/Controllers/WebhookController.php#L201-L210

To return our BillableUser model instead.

This is a rough sketch of potentially how to approach it... before we start on any coding, what do you think... sound about right or any concerns?

[lindyhopchris]

There's now an upgrade guide here...
https://github.com/laravel/cashier/blob/master/UPGRADE.md