stripe_connect_platform-legacy-checkout | Stripe Developers | Page 1

alpine gorge Sep 21, 2021, 11:01 PM

#

versed spoke Sep 21, 2021, 11:02 PM

#

I know. We are trying to move customers to our v2, but we still have people making v1 and I want to clean things up in the codebase

alpine gorge Sep 21, 2021, 11:02 PM

#

Let me double check this - I don't have a lot of experience integrating with the legacy checkout flow so bear with me

versed spoke Sep 21, 2021, 11:03 PM

#

Check this out:

#

https://stripe.com/docs/legacy-checkout

Checkout Reference (legacy)

#

You still list the data-key in there .

#

My question is will the form still function if we pull the data-key attr?

#

And given that best practice is to use v2, if we do have v1 customers, should we pull that line from embedded forms?

alpine gorge Sep 21, 2021, 11:06 PM

#

Just tried it out on my end - removing data-key won't work.

versed spoke Sep 21, 2021, 11:21 PM

#

OK, so given the v1 issue (that we still have customers on v1) it is OK to expose the pk_test key?

#

Sounds like it is required

alpine gorge Sep 21, 2021, 11:26 PM

#

Yeah, that's really the only way

versed spoke Sep 21, 2021, 11:26 PM

#

ok. cleaning up where i can.

#

Question about dev mode testing

#

If someone uses our ca_ to Connect in livemode, does that automatically connect them in testmode too? Or do we have to make both connections with our livemode ca_ and our testmode-ca?

#

And the issue is the reverse, we would like to be able to Connect an account in testmode but that leaves us stuck since it seems that connecting them in testmode doesn't let us make live api calls.

#

So for the development mode connection what strategy do you recommend?

#

Pass in one key and then the other? Or is there a better way?

#

I am confused about this flow and want to clean things up.

alpine gorge Sep 21, 2021, 11:31 PM

#

If you connect in live mode, that will automatically get you test mode access as well. As you mentioned, the reverse isn't true - if you connect in test mode you need to connect them in live mode as well (you don't get a live mode connection as part of the test mode one)

#

Personally, I would suggest just connecting them in live mode from the onset, unless you know it's a connect account that will only ever be used in a development/testing context

versed spoke Sep 21, 2021, 11:57 PM

#

Sorry. Laptop died.

#

Right! That's what i was thinking. OK. I agree.

#

Thank you!

alpine gorge Sep 22, 2021, 12:32 AM

#

@versed spoke Feel free to ask your question here!

versed spoke Sep 22, 2021, 12:32 AM

#

sk_live storage for Connect account. Is there ever any circumstance where we need to use that key or has it all been replaced with the new method of using the platform keys?

#

As in, if we totally delete all the db keys is there really no circumstance whatsoever that we will need these sk_live keys?

#

For example, we just realized that we do in fact need pk_ keys since some customers are on v1 still.

#

*Also, on a side note. Just clarifying things. When we get an "sk_live" key in the Connect flow....

#

Is that the same "sk_live" the standard Stripe customer would see in her account or is it a special key that uniquely identifies our connected relationship?

#

*sorry for the hard questions, we have had the app for a while and are trying to clean things up. 🙂

alpine gorge Sep 22, 2021, 12:43 AM

#

I'm fairly certain that there shouldn't be any need for you to keep these sk_live keys as long as your integration has been updated to correctly handle making calls with the stripe-account header. Let me just think if there are any edge cases though...

versed spoke Sep 22, 2021, 12:43 AM

#

ok

#

Customer Portal etc?

#

No need for sk_live right?

alpine gorge Sep 22, 2021, 12:44 AM

#

Nah, definitely don't need them for customer portal

versed spoke Sep 22, 2021, 12:45 AM

#

OK and is the sk_live key given to us in the flow identical to the one visually seen by the Stripe account holder, or do you spin up a new one just for us?

#

I just wanted to clarify that one since it has been a long time and I am not 100% clear.

#

You spin up a different one for us right? That is unique to us?

alpine gorge Sep 22, 2021, 12:47 AM

#

The keys that you get as part of the oauth process are different from the ones that they can see on their own dashboard

versed spoke Sep 22, 2021, 12:47 AM

#

Perfect. That's what I remembered. OK great. So you can disable it without rolling their key if they deauth us.

#

And I imagine same with pk_test and pk_live - the ones we get as part of oauth process are different.

#

So if a customer has pk_abc and makes a payment button in v1, that button will have pk_abc even though the Stripe account holder may look at the button code and it won't match their account pk_efg

alpine gorge Sep 22, 2021, 12:50 AM

#

Yup!

versed spoke Sep 22, 2021, 12:50 AM

#

Last question. If a customer deuathorizes us and they have buttons with pk_abc still. They would have to replace those buttons if they re-auth. (This happens if they don't pay us and we disconnect them.) lol

#

They have to not only re-connect, but also replace pk_abc since when they oauth again, you spin out a new pk_123 to replace the pk_abc, is that right?

#

i.e. if a customer deauthorizes us and then re-connects us, you spin up a new pk_ and sk_ etc different from the 1st time they oauth'd to us.

#

We have embed code that would not automatically update, they have to replace it if the keys are wrong.

alpine gorge Sep 22, 2021, 12:53 AM

#

That's also correct - when they reconnect we would give back a new set of keys that won't match the first set

versed spoke Sep 22, 2021, 12:53 AM

#

perfect. got it. Thank you so much! OK, cleaning the codebase up now! Thank you!!!!!!!

alpine gorge Sep 22, 2021, 12:53 AM

#

happy to help!

#stripe_connect_platform-legacy-checkout