#jz-1_best-practices
split torrentBOT
👋 Welcome to your new thread!
⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1410704668387971113
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
errant jetty
Hello 👋
OAuth enables read_write permissions but this is still more restrictive than sharing a secret API key.
Using a scope of read_only with your OAuth URL is still considered the canonical way to onboard existing Stripe accounts onto your platform where you just need read_only and webhook access
crystal ermine
hey @errant jetty - thanks for the response
the docs are a bit confusing around what default read_only means for stripe. if no params are provided for scopes, then by default we get read_only access to all objects in stripe? or is this an allowlist based permission system
also wondering then in what cases would direct integration be preferred. we have the connect platform since we manage payments for other clients and would like to understand + plan ahead
thank you
errant jetty
Read only means you can only make GET Requests, no POST. This covers all Stripe objects for an account because OAuth uses a permissions system that predates object-specific permissions
When you say "direct integration" you mean where your user shares an API key directly with you and you make API requests on their behalf, correct?
crystal ermine
yeah thats correct - as we understand it, its possible to create restricted keys with object specific limitations
mostly trying to see if there will be objects to connect read only access (we have not had this usecase before with UK based customers)
errant jetty
That is true. However, we generally don't recommend that approach for Connect type integrations
Because it's not Connect
There is no way to revenue share when using a Restricted Access Key
There is a way you can achieve this kind of permissions structure though, using a Stripe App
But it's significantly more complicated
crystal ermine
understand. for this use case we are primarily ingesting data for new/updated objects
we have explored stripe app as well, and from complexity standpoint we thought it would be easiest if there are no compliance issues for EU/UK clients to simply reuse our connect integration and flip the scope
we manage payments for other connect clients, but for this one they are only looking for read-based API integrations without mutations / PCI or initiating payment handshakes
errant jetty
In that case I think OAuth is the most straightforward way to achieve this
crystal ermine
sounds great thank you! and to confirm, it's really as simple as flipping the scope to read_only instead of read_write?
errant jetty
Correct!
crystal ermine
thank you @errant jetty
split torrentBOT