Support Starling Lab's need for a seperate billing account

[prodalex]

As an organization (i.e. Starling Labs) I want to have another entity/user identified by their email being able to add a payment method for all our accounts that we create.

• I need to be able to invite a payer by email address
• The payer (billing role) needs to be able to login into the console and add a payment method valid for all spaces created in that account.
• The payer should receive the invoices to their billing email address

[reidlw]

This may be treated as a 1-off for this customer until we get multiple requests for this.

[hannahhoward]

Confirming priority with Starling labs

[travis]

So after digging into this a bit I think we may want to break this up into a few different pieces:

I need to be able to invite a payer by email address

This we can do a few different ways - correct implementation depends on decisions about items below...

The payer should receive the invoices to their billing email address

This should actually be pretty simple - Stripe supports having a separate "billing email" - customers can't set it themselves in the "no code customer portal" (https://docs.stripe.com/customer-management/activate-no-code-customer-portal) but we can add a capability that uses the Stripe API to set this - should be a pretty straightforward project.

The payer (billing role) needs to be able to login into the console and add a payment method valid for all spaces created in that account.

So this is tricky - we currently rely on the "no code customer portal" for payment method updates, which means we don't need to worry about accepting payment information and keeping it secure, etc etc. Unfortunately this portal is only accessible by the "account email" [ed: see below - may have a solution for this!] - setting a billing email and trying to log into the customer portal with it seems to not work (based on testing I did this morning with my account). As a result, if we want to enable this we'll need to:

1) Figure out how to accept payment details ourselves and add capabilities that will do this. This is actually a fairly large project because we will at LEAST need to update every level of the stack to avoid holding on to credit card details anywhere (one example - UCANs in the UCAN log will, as currently implemented, be archived with credit card details in them - we'll need something somewhere to redact those). 2) Add a new "login" flow that we can use for "billing users" - this will probably involve the primary account holder generating a delegation to the billing user and sending them a link containing the delegation. This should be relatively straightforward but will require a minor overhaul of the current login flow.

ed: late addition I found this which may give us a solution here - it looks like we can use the stripe API to create a billing portal session for users:

https://docs.stripe.com/api/customer_portal/sessions

This will still be a bit tricky, as the Stripe client lives in w3infra so we'll need to add a new capability. (2) above would still need to be done, but we can avoid the REALLY hard bits in (1).

Conclusion

Adding the ability to set a billing email address feels like an easy win that will provide a lot of value for our users. Adding the ability for the billing email address to add and update payment methods feels HARD and probably not worth it since payment method updates should be infrequent and should probably coordinate with the account holder anyway. I'd recommend grabbing the easy win and deferring the hard thing to much later.

ed: late addition if the customer portal creation API call works as advertised it should enable us to implement payment method updates - I'm still not entirely sure it's worth the work since this is still something the billing person should probably coordinate with the account owner about, but it feels much more feasible than I'd thought previously.

@prodalex what do you think?

[travis]

ok broke this down into two smaller issues ^^

[reidlw]

Committed to doing #61 and moving #60 to Icebox. Will close this one and just track 61.