#shreyjain-connect-billing

1 messages · Page 1 of 1 (latest)

feral bladeBOT
lucid oxide
#

Yes, as long as your customers don't involve any connected accounts themselves that would be the way to go

#

You can create subscriptions using COnnect patterns as shown here:

smoky notch
#

Awesome! I just checked out my onboarding flow and yeah this is pretty much what I need. So is there a React component that Stripe gives me that I plug into my app?

#

For the OAuth integration?

lucid oxide
#

We don't recommend oauth for onboarding anymore, instead you create accounts and account links to complete onboarding:

#

For express accounts, for example

smoky notch
#

Oh nvm, you're saying i should use this ok

#

So for the connect-embedded-components, it need a CONNECTED_ACCOUNT_ID when i set up an Account Session – where do I get that from? I know the user has to authenticate it, but is there something I do before i send an API req to this endpoint:

const stripe = require("stripe")(
  // This is your test secret API key.
  '',
);

const express = require('express');
const app = express();

app.post('/account_session', async (req, res) => {
  try {
    const accountSession = await stripe.accountSessions.create({
      account: {{CONNECTED_ACCOUNT_ID}},
      components: {
        account_onboarding: {
          enabled: true
        }
      }
    });

    res.json({
      client_secret: accountSession.client_secret,
    });
  } catch (error) {
    console.error('An error occurred when calling the Stripe API to create an account session', error);
    res.status(500);
    res.send({error: error.message});
  }
});

app.listen(3000, () => {
  console.log('Running on port 3000');
});
lucid oxide
#

You should remove that test key first of all, and probably roll it now that you've shared it publicly

smoky notch
#

Rolling it rn

lucid oxide
#

But for the actual question, this would be an account you create for them

smoky notch
#

Oh got it – what if they already have an account

feral bladeBOT
lucid oxide
#

Ah like their own existing account they signed for themselves, outside of your platform context?

smoky notch
#

Yeah

#

And they can like access that account for themselves through their own stripe dashboard, im just trying to make changes if they make changes through my dashboard and have things automatically done through my dashboard

grim kernel
#

shreyjain-connect-billing

#

👋 taking over but I don't really get what you're asking. You use "their own stripe dashboard" and "my dashboard" without much context unfortunately
We focus on helping developers with developer-related questions about our products and APIs. As a Connect platform you can see everything a connected account does and you can use the API to make changes on their behalf as needed

smoky notch
#

Yep thats exactly what I need!

#

I think Connect with the links shared in this thread is for new accounts that I create! But i want to be able to integrate with existing stripe accounts

#

my dashboard = the dashboard my customers will use to configure what kind of billing they would want for each one of their users

their own stripe dashboard = they already have an accessible Stripe account running, and I'm just programmatically making changes on their behalf using the API (as you mentioned)

#

Let me know if this makes sense

smoky notch
#

Right, and is there a React component that i can use to build OAuth with Stripe?

grim kernel
#

no

smoky notch
grim kernel
#

no you don't need any of this. Read the docs I linked it explains how this works, there's nothing React specific in there

smoky notch
#

Ok, so it's just a button with hardcoded values like my client_id and such in the URL

grim kernel
#

yep!

smoky notch
#

Perfect!

#

I think that's it for now, and then will follow up after if I have any other questions. thanks sm for the help, and hope it wasnt too much of an inconvenience

grim kernel
#

no inconvenience at all, we're always happy to help. The main issue is how important the right "Stripe-specific vocabulary" is and how common words like "dashboard" or "checkout" can mean completely different things. Like you have your own app's dashboard for configuring things but a Stripe account has their own Stripe Dashboard too and in one sentence using both words it can be quite tricky to grasp

#

I'll keep this thread open for a bit if you have more questions let me know

#

You might also want to look at https://stripe.com/docs/stripe-apps which is a completely different integration path where you can build an app a user can "install" in their account too

smoky notch
#

Oh ok i did have one more question – I want to redirect my users back with some variables in the redirect_uri

#

But seems like I have to set that on Stripe's dashboard

grim kernel
#

I highly recommend to never do this

smoky notch
#

Making it not dynamic (where i can set a variable on it like an ID)

grim kernel
#

It's OAuth, don;'t try to make anything dynamic in the URL that anyone can change or abuse. Use a cookie or a browser session to recognize who they are when they come back

smoky notch
#

Yep makes sense – on my end I'll store something locally so I know which "organization" they authenticated to integrate stripe billing with

grim kernel
#

yeah that's what I recommend in that case!

#

you could use the state query parameter, but it is dangerous since anyone can change it

smoky notch
#

But an ID is like some UUID, so it's hard to guess a UUID for someone's who exist

grim kernel
#

agreed and you call always make it a hash or something, just usually bad practice 🙂

smoky notch
#

Got it – will just use something stored locally

#

Also – scope values are either "read_only" "write_only" or "read_write"?

#

Oh there is no "write_only" only read_only and read_write

grim kernel
#

correct, doesn't make sense to be able to write and not read

smoky notch
#

Yep totally

#

Awesome – the Oauth flow is super intuitive now haha

grim kernel
#

yay!

smoky notch
#

I just realized why i couldnt read the docs fast enough

#

No dark mode

grim kernel
#

lol

smoky notch
#

When i pass a unique token to you guys in state to prevent CSRF attacks, where should i store it to validate it when you send it back?

grim kernel
#

in your own database/cookie/session, really up to you