Support multiple stripe accounts

[rorhug]

Running a second or third container is fine if you have a few stripe accounts. However if you have N accounts (i.e. you're building an app that integrates with stripe), it would be useful to sync multiple accounts.

Some technical considerations may be:

• Partitioning: Adding accountId to every, or to just parent tables
• Ability to add an remove accounts via API to both setup and cleanup
• Handling background jobs better for syncing might be important

The work in #13 would also be helpful.

[casualmatt]

I think the issue is more of a RFC. I'm actually not in favor of it; investing energy in adding it is not necessary. Containers are lightweight, and they provide the extra security and isolation necessary for GDPR when u deal with a 3° party account.

[kevcodez]

While I believe that it generally makes sense to include the account id in all tables (feel free to open a PR for that!), I think supporting multiple accounts with a single deployment is not very feasible as this point in time. One then has to think about reworking foreign keys/relations, given data is only unique once put in to relation with an account id.

The nice thing about the current approach is that it's lightweight and very straightforward

13 requires Stripe API keys with write-access to be present, which would then mean that you'd basically have long-living tokens with write access from many Stripe accounts in a single deployment, increasing security risks.

I'm not entirely advocating against ever doing this, but there's also a decent advantage in keeping it simple and single-tenant and then just creating multiple deployments for multiple Stripe accounts (just a few env vars and clear separation).

I can at least tell you that we won't be actively working on multi-account support in a single deployment at this point. If you do want to take a stab at it, feel free to make a proof-of-concept though. It does need to be backwards compatible