#ZakMcKraken
1 messages · Page 1 of 1 (latest)
The test mode toggle in the dashboard is just a UI toggle, the account will exist in both modes either way. Are you looking for how to differentiate whether webhooks are from live mode or test mode? Or something else?
Does that mean there is a way to push "test" mode transaction as the "connected to" account?
I'm trying to find a workflow for connected accounts that wish to make test transactions
with minimum work on the side of my app
Yes, you can make test mode payments, you would just use your test mode key
Oh are you connecting to these accounts with OAuth? I forget if a test key is passed along with that
yeah the app uses OAuth
I've never really looked into it, someone from the product team was saying it makes a difference if they connected while in test mode or prod mode
something around the lines of "if in prod mode then we have access to test mode but not the other way around"
I was trying to get some clarity from the doc but not really finding what I need
essentially I'm trying to assess if we could do something like
force them to connect in prod mode, but allow them to have a "use the test mode key" thing to try transactions/their integrations
I believe so. Checking in to this now...
So as far as I know the OAuth link you give out should only be for live or test mode. The user shouldn't be able to choose which they connect in. Are you seeing users that only connect in test mode?
I have to test
but he was saying that if they connect in test mode we don't have access to live unless they disconnect/reconnect
may be an implementation issue on our side though
For test mode that sounds right though I am not as familiar with OAuth so I can't immediately speak to the connecting/disconnecting being necessary. I do see that our docs reference using the refresh token you get when connecting in live mode to get test mode access tokens but I am not finding the exact steps for that specified at the moment
https://stripe.com/docs/connect/oauth-standard-accounts#:~:text=The refresh_token can be used to generate test access tokens for a production client_id or to roll your access token. You should hold on to this value%2C too%2C as you’re only able to get it after this initial POST request.
I have to step out but my colleague @drifting loom is stepping in and should be able to help going forward once they are caught up
alright, thank you!
@drifting loom please let me know if you have anything else to add 🙂
Apologies for the delay. Server is mighty busy. Getting caught up now
yeah no rush
I seem to recall the disconnect/reconnect requirement for this workflow being a workaround. Is there an outstanding question here? Or are you just looking for additional verification that this is the correct approach?