📝 Stripe documentation on Using Connect with Standard accounts can be seen - here.
📖 This lesson's lecture slides can be found - here.

Let's brainstorm the GraphQL fields we'll need to integrate Stripe Connect into our app. As we've mentioned in the previous lesson, Stripe uses the industry-standard OAuth 2.0 protocol for authorization. At this point, we're not looking to see how payments can be made from tenants to hosts when a booking is made but instead provide the capability for users to connect through our Stripe Platform and be a connected account on our platform. Why do we want this? By having users connected on to our Stripe Platform account - when a payment is made to them - we can be the middleman and ensure the payment is routed to their Stripe account while we take our platform fee.

Gameplan#

Here's an overview of what it would look like when users have connected to our Stripe Connect account, TinyHouse App.

At this stage, these users would have a standard Stripe account, be able to log in to their own dashboard and be able to process charges of their own. In short, we want to have users who've logged in to our TinyHouse application be able to connect to their Stripe account and be a connected account on our Stripe Connect platform.

The authentication flow for having a user connect to their Stripe account is going to be very similar to the OAuth 2.0 implementation for when a user logs in with their Google Account.

On the client application, we'll have a call to action for the user who's already signed in to our application to connect their Stripe account.

When the user clicks the action to connect, they'll be redirected to Stripe's login page to log in with their Stripe account. This page notifies the user about the Stripe Connect account they're connecting with and this is determined by the Client ID value that is part of the URL. At this moment, for a real live application, the user will need to sign in with their already existing Stripe account or create and activate a new account in the form presented to them. If our Stripe connected account is in test mode, Stripe will give users the capability to skip this account form which will be useful for us during testing.

Once the user is successfully logged in, they'll be redirected to the redirect URL we've specified for our connected account client. We've said in the previous lesson, we'll want users to be redirected to the /stripe route of our app. In development, we've set the route as localhost:3000/stripe but in production, we'll reference our production app's domain name (e.g. tinyhouse.app/stripe). Either way, Stripe returns an authorization code as a query parameter in the URL.

When redirected, our client app receives the authorization code and sends it to our server. Our server uses this authorization code to make another request with Stripe to receive the connected user's account Stripe information. Many different fields are to be returned but we'll be interested in keeping and storing the user's connected stripe_user_id value. This stripe_user_id value will be used later on to act on behalf of the user. If someone books this connected user's listing, we'll create a stripe charge and then say we would want the account with this user's id to be paid out. On our database, we're going to store this stripe_user_id as the walletId field of a user document.