#tim_api
naive gulchBOT
👋 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/1486681766289866792
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
sharp blade
hey there 👋 happy to help with this
could you share some more context about the access you want your restricted key to have?
craggy fog
Absolutely, and thank you in advance for your help!
I want customers to be able to sign up for monthly or yearly subscriptions, and make one time payments. Save credit card details ofc for payments on schedule.
I'd also like them to be able to pay with other payment types by country (Paypal/Blik, whatever it may be)
All of this will be done from a website, where we'd link to a specific product checkout ideally with price pre-selected (so we can allow them to choose monthly/yearly prior to hitting a stripe page)
My product catalog and prices are configured, and I'm in the restricted key setup area now, but there are many options and the documentation is more about the technical end that what it does or doesn't enable for us and customers
and I'd like to not end up with a key that if compromised can allow customers to perform fraud 🙂
or also problematic, one that doesn't allow them to pay or subscribe, haha
sharp blade
so before you set up your restricted key, you need to know exactly what API resources it needs access to, which in turn means you'll need to know what APIs your integration will use during your payment flow
as you mentioned, this is more about the technical details, but those details are necessary in order to create a restricted key with the right permissions
to explain with reference to a slightly clearer scenario, say you were building a page to redirect customers to the Customer Portal for subscription management, and wanted to create a key with minimal access, you'd just need to select write access to the Customer Portal, in the "Billing" section
so it's really hard to say in the abstract what permissions your restricted key would need, other than write access to Subscriptions, if you're integrating directly with the Subscriptions API for example
do you have a breakdown of the API calls your payments integration will send to Stripe?
craggy fog
I don't, I just have a breakdown of what I'd like customers to be able to do
Which API calls are required for that I'm unaware of right now. Discovery process. Single payments, subscriptions (monthly/yearly), flexible payment options (none physical, but standard by country), and saved payment details
sharp blade
in that case, I'm not sure a restricted key is really what you need here, since API key access doesn't seem to really be the problem you're trying to solve
the purpose of restricted keys are security-focused API credentials which limit access to only specific resources API (for example, read-only access to Charges)
their intended use cases are things such as connecting with third-party integrations, building microservices, or setting up limited-scope backend tasks, by reducing risk if a key is compromised
but it sounds like you're planning to build a full payments integration from scratch, which would typically involve using a combination of your account's publishable and secret API keys
craggy fog
Wouldn't a restricted key be a better option if the intended integration should still only be able to do certain things, and not, for example, create new discount codes or change account details?
sharp blade
yes but that's the point of needing to know the exact calls your integration needs to make to Stripe, so then for example you know specifically what things the key does/does not need to be able to do
you need to know this in order to know what resources the key needs to be able to access
for example, if you know that the key won't need to create new discounts/coupons, then you could omit access to the Coupons resource entirely, but that doesn't tell you what access the key does need, since that depends on the technical specifics of your integration
craggy fog
If I omit coupons entirely, wouldn't it be unable to read coupons I manually create elsewhere? I'd think it at least needs read access.
And this is where I grow a little confused with the key setup. For example: Are client confirmation token writes required to successfully execute a checkout? Or only reads, as reads are only available for regular confirmation tokens? Tokens are listed as needed on some guides generally, but not Confirmation tokens, just tokens. Customer Sessions are required, for all payment flows seemingly, write and read. But what about Invoices? is the API creating invoices or is the API creating a payment that creates an invoice and thus we only need to read them?
And the API key setup has a section for Checkout Sessions, read and write, but I can't tell if checkout sessions would be automatically created by other API calls and thus we only need read, because write is for manually creating them for some reason, or whether write is required because the intent is read is for diagnostic and support tools to find sessions.
I'd also read somewhere that customers, write, is required else they can't create a place to save payment details, but I'm worried that's inaccurate and actually customers is only needed if you want to manually create and read customer records, where payment setup and saving is just automatic as part of other capabilities.
I don't want my own payment and sub pages, I plan to lean on Stripe's pages for most everything once they've picked a product and monthly/yearly or flat payment.
sharp blade
from my perspective it sounds like you're putting the cart before the horse, since you're trying to figure out what permissions the restricted key needs without first confirming what API resources you need to access (i.e. by actually building the integration)
if you had an integration set up using publishable and secret keys, then you'd have an end-to-end list of what calls you're making (i.e. what API resources you need to access), which would then allow you to create a restricted key with minimal access
It's possible to limit access with a restricted key, but in order to configure it with the correct write permissions, you need to know all the resources your integration actually touches.
I can speak broadly/generally about what is generally needed, for a typical payments + subscriptions integration, but I can't guarantee this will fully support what you need without a list of calls/resources you'll be accessing
that would include resources like:
PaymentIntents – write
Customers – write
Subscriptions – write
Payment Methods – write
Prices / Products – read or write
Webhooks / Events – read
SetupIntents – write
Invoices – read/write
the simplest way to get past this would be to just go ahead and build your integration in test mode, using your test secret and publishable keys
then when you have a list of the calls you're making/what resources you need to access, you can create a restricted key with the appropriate access
craggy fog
Thank you - Will be back if I continue to have any questions. I appreciate your time.
sharp blade
happy to help of course