#crisnoecom_api

1 messages ¡ Page 1 of 1 (latest)

pale kayakBOT
#

👋 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/1420374730090872873

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

deep sentinel
#

hi there! looking into your request now

#

a restricted key is typically the approach we recommend if you want to allow a service to have limited access to make requests to Stripe for your account - for this use case, a key that only has 'write' access to the Subscriptions resources is what would be needed

this would allow the provider to post data to Stripe for Subscription objects (i.e. creating, updating, and deleting subscriptions)
https://docs.stripe.com/api/subscriptions

would you mind sharing a little more about how you'd like to further restrict the access granted to your provider, to minimise the security risk?

elfin marlin
#

Here is some information we received from chargeback provider:
''This is an expected behavior for subscription cancellation. The owning platform can collect the application fee from the connected account, which is the agreement between the owning platform and connected account. Third party platform is not authorised to cancel the subscription unless the connected account or owning platform initiates the cancellation themselves''

**They also said: **
We need application key to your account (which is a bit of a security risk on your side) then we'd have perms to do this I think.

We also received info about:
if you were making the subs on your own stripe via your own API key and not a third party the sub cancel would work. Its solely because another third party created the sub that we (as another third party) cannot cancel it

So we're looking for the most secure workaround on our end.

#

Also wondering if it would be safer to set up a n8n or Make automation for this, if possible, instead of providing sensitive details in hand to a third party

deep sentinel
#

yes this all makes sense, as a third-party platform cannot cancel subscriptions created by another platform

the only workarounds to that are:

(a) provide the third-party platform with your secret API key (granting full access to control your account, so high security risk), or
(b) create a restricted API key to provide the third-party with (reducing security risk by limiting permissions, but still not 0 risk as it does allow access to certain operations within your account)

#

I'm afraid it's not possible to restrict permissions more granularly than the RAK option, or to grant access in another way, so the RAK option is generally considered the 'safer' option

#

the only other alternative would be to handle the subscription cancellation from your end, in response to the alert from your provider

#

if you were making the subs on your own stripe via your own API key and not a third party the sub cancel would work

this is true, though creating a RAK for subscriptions would have the same effect (allowing access to create/modify/delete all subscriptions on your account)

elfin marlin
#

alrighty, is the safest option then to build the automation internally with something like n8n or Make? that would probably keep the API key stored securely, perhaps make or n8n would be able to cancel with the restricted key

deep sentinel
#

we're not deeply familiar with those services I'm afraid, so we're unable to comment on that from a security standpoint

#

ultimately, providing an API key to any third-party service requires trust in that service's security procedures

elfin marlin
#

thanks for helping