#dave_docs
topaz yokeBOT
👋 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/1243576824605179946
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
mortal pebble
Hi there 👋 it sounds like you may be trying to set up a Nested Connect flow, where your Platform tries to also control Platforms, which isn't supported. Does it sounds like I'm grasping that right, is your entity structure?
Twilio (the root platform)
|
\/
ISV (Connected Account of Twilio, and Platform of it's own merchants)
|
\/
Merchant
urban mauve
Hey Toby, that's exactly right
If it's not supported, is there anything possible as a workaround? Or not really
mortal pebble
Hm, building a Stripe App that uses a RAK (restricted key) authentication pattern is the only approach readily coming to mind that might allow what you're after:
https://docs.stripe.com/stripe-apps/api-authentication/rak
urban mauve
I think we already do something like that
I can provide screenshots to show you what I mean
urban mauve
No, you are correct
I guess I saw that RAK generates a permissioned restricted API key. That sounds like a "scoped key" to me, which is what we get through Stripe connect
mortal pebble
With Connect, you're either linking the accounts you can use the stripe-account header to make requests on behalf of your Connected Accounts, or you're getting keys generated by the OAuth token that do that for you using a key. RAKs are different, they're keys directly on the Connected Account, and as far as I know that holds true for extensions. It may also be worth aligning with your Stripe contact to see if there's anything in the works or non-public that could help you accomplish what you're after.
urban mauve
Thanks Toby, that is helpful.
So with RAK, we could have a Twilio ISV customer generate a permission restricted API key. They could do this one time. Then, they send us the RAK whenever they want to use the transfer_data parameter. Am I understanding it correctly?
mortal pebble
I believe so, yes
urban mauve
Ok great. Looks like the customer can generate this RAK on their own, right? And they can send it to us (Twilio), and Twilio doesn't really care what the RAK is. We just act as a middleman and forward the transfer_data request with RAK to stripe
topaz yokeBOT
mortal pebble
Yes, but typically we discourage sharing keys since they're sensitive. Restricted keys make that a bit safer by letting the account owner control what permissions the key has. I think I'd recommend looking at the RAK extension (I believe this generates the keys automatically) rather than asking users to generate their own and share them. That should help minimize the risk that they generate a key with insufficient permissions for your flow, that you would need to be ready to catch and handle.
urban mauve
so in the original link you sent, I see this "The user copies the generated keys and provides them to your site.": https://docs.stripe.com/stripe-apps/api-authentication/rak So the RAK extension is different right? The key difference being the user doesn't copy anything. We are ultimately the ones who generate the RAK and so they don't need to give it to us because we actually created it.
inner moon
I think they still need to copy/paste the key into your site, since RAK uses a hosted page to generate keys and there's no way for you to programmatically pull that key out
urban mauve
Got it. Can I backtrack and revisit another possible solution - what if instead the user just passed us their actual api key? Then we could do the original payment intent with transfer_data parameter. Is that right?
inner moon
yeah, but like toby said, that's a really risky way to handle this problem. We don't recommend sharing account-level API keys.
urban mauve
Ok got it. So let's switch back to the RAK extension solution that was proposed earlier. You mentioned "I think they still need to copy/paste the key into your site". Is there any way to avoid having the customer copy/paste the key into our site? Since Toby mentioned " typically we discourage sharing keys since they're sensitive"