Closed bhaibel closed 6 years ago
@bhaibel - I think we want to connect this to the project not the user as the a user may have many projects; and a user may have different stripe accounts.
For instance, I have like... 3... One for apprenticeship.community, one for zinc, and one for me personally. I've used them all in different situations.
I hear what you're saying, but when I think about how to present that to the simplest-case user in a way that's intuitive, it's kind of challenging -- maybe that's me being rusty at UX or maybe that model is inherently just complicated, but either way I start wondering if per-project credentials are something we want to punt to the next iteration of this feature, to keep the surface area of this story small.
Also, when you describe how you'd want to use multiple Stripe accounts, I start wondering if maybe the solution is encouraging people to create organization accounts -- the reason you use Zinc's Stripe account in some circumstances and Zee Spencer's Stripe account in others is AFAICT because Zinc and Zee aren't quite the same entity -- it's not just complication you're doing for shits and giggles. Maybe the UX answer lies in getting to the name of that domain concept.
Wouldn't moving the Connect Payment Processor button from the User page to the Project page allow that? There's no additional complexity there, purely a change of location. A Project HasOne PaymentProcessor, and Project Creators can create or remove the PaymentProcessor from the Project.
The complexity is for users who have the less complicated (and I suspect more common) case of one stripe account and several projects they want to promote -- "why do I need to do this again ugh."
On Fri, Dec 29, 2017 at 6:44 PM, Zee notifications@github.com wrote:
Wouldn't moving the Connect Payment Processor button from the User page to the Project page allow that? There's no additional complexity there, purely a change of location. A Project HasOne PaymentProcessor, and Project Creators can create or remove the PaymentProcessor from the Project.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/wecohere/nourish.party/pull/80#issuecomment-354513377, or mute the thread https://github.com/notifications/unsubscribe-auth/AASb3HFKXdyS-31DQvY8MPEdUNsUNyeOks5tFXlKgaJpZM4RPSFL .
-- -- Betsy
I think this is probably fine for now and we can always change it later once we start building out the more complex use cases.
UX design PR for https://github.com/wecohere/nourish.party/issues/10.
Relies on the assumption that we'll be using Stripe Connect's OAuth flow, with the "Standard Account" subtype. When users click "connect to Stripe," they will be taken to a Stripe-maintained onboarding flow that will return them to us once they have either logged in to an existing Stripe account or created a new one.