#kbjohnson90-checkout-redirect

1 messages ยท Page 1 of 1 (latest)

weary condor
#

@frank badger that almost always happens because you are mixing up API keys. You're using the Secret API key of one account to create the session and then you redirect with the Publishable API key of another ccount

#

If you use Connect it's likely because you don't initialize Stripe.js properly

#

If you share a bit more details I should be able to help

frank badger
#

Does the Account ID substitute for the secret key in this case? I'm not seeing the secret key being used.

#
\Stripe\Checkout\Session::create(
  $args,
  [
    "stripe_account" => "acct_*********",
  ]
);
#

I've tried refactoring to use the secret key of the connected account directly, but am getting the same error.

$stripe = new \Stripe\StripeClient(SECRET);
$stripe->checkout
       ->sessions
       ->create($args);

I've confirmed that the secret key is the value that I expect and have confirmed that the session ID created matches the sessions ID used in the Checkout Redirect for the payment page.

#

Is there some way in my Stripe account that I can check the secret key of the Connect account? I am assuming that the secret that I have is correct, but I also don't see how to confirm that assumption in my account.

craggy plaza
#

Does the Account ID substitute for the secret key in this case? I'm not seeing the secret key being used.
you're setting your secret key (presumably) when you initialize Stripe PHP in your backed

the acct_123 Connect account ID allows you to make API requests on that Connect account, it isn't a substitute for the API key

#

I've tried refactoring to use the secret key of the connected account directly

please don't do that

#

that is highly not recommended and will only give you more trouble down the line

frank badger
#

I'll roll that change back then ๐Ÿ˜…

craggy plaza
#

Is there some way in my Stripe account that I can check the secret key of the Connect account?
so yeah you're going down a rabbit hole you should not, your actual issue is somewhere else to fix, let me explain

#

let's start here

#

how are you redirecting to Checkout?

frank badger
#

Using stripe.redirectToCheckout() method, passing the session ID.

#

Inspecting the network requests, I was able to confirm that the secret key returned during the Connect process is the same secret key being used in initializing Stripe.

craggy plaza
#

ok so

#

how are you initializing Stripe.js on your webpage

#

that is what I think is the problem here

#

alternatively

#

you dont' need to use redirectToCheckout

#

when you create the CheckoutSession, it has a url field

#

so you can just redirect to it there

frank badger
#

Stripe JS is initialized using an inline script, passing the publishable key and the account ID.

stripe = Stripe( '<?php echo $publishable_key; ?>', {
  'stripeAccount': '<?php echo $stripe_account_id; ?>'
} );

and then redirecting

stripe.redirectToCheckout({
  sessionId: '<?php echo $session_id; ?>'
})
craggy plaza
#

is the publishable key of the Platform account?

frank badger
#

The publishable key matches the value returned during the Stripe Connect flow (stripe_publishable_key_test)

#

The https://checkout.stripe.com/pay/ url listed in a dump of the session doesn't match the real URL redirected to. The session ID matches in both versions of the URL, but the value after the # is different.

craggy plaza
#

yeah that is the incorrect part

#

you're using the Connect acct key

#

that is wrong

#

you need the Platform's publishable key

#

basically, ignore the keys you get in Stripe OAuth flow

#

also

The https://checkout.stripe.com/pay/ url listed in a dump of the session doesn't match the real URL redirected to. The session ID matches in both versions of the URL, but the value after the # is different.
them being diff is fine

#

just use the url you get back in the Session object

frank badger
#

Hm... Not recognizing a platform publishable key.

#

I'll mention that this is a distributed codebase (WordPress plugin) and a partner account.

#

Does that change anything?

craggy plaza
#

ah well.... it does and does not

frank badger
#

๐Ÿ™‚

craggy plaza
#

what is your plugin approach, you're using OAuth to connect to new Stripe accounts right

frank badger
#

Correct.

#

We have a "Connect to Stripe" button within the admin interface.

craggy plaza
#

now to your most recent question

#

Hm... Not recognizing a platform publishable key.
what does that mean? like any errors? what is the issue

#

and

#

why won't you go with my easier advice lol

#

just use the url you get back in the Session object
just saying

frank badger
#

Using the url returned by the session, instead of using redirectToCheckout() with the session ID, would be a significant refactor for this codebase.

craggy plaza
#

ok so

#

DM me how you initialized Stripe.js with full unredacted publishable key and Stripe Account ID

#

they are public so fine to share but still don't paste here

#

just DM me

#

so I can look

#

ok so can you share a test mode CheckoutSession ID?

#

looked at the two you sent, those look fine

#

wondering if you're using the "Connect OAuth" API keys in your CheckoutSession creation

frank badger
#

cs_test_a1kAPC0omFgZPyMHedU22FNt2nWsd7FSfyOPRdVnZEjDLMbQD5IWnBaLh9

craggy plaza
#

ok so your server-side code and client-side code seems to be initialized correctly

I'm gonna talk through some stuff to see if there is something I missed

#

is there a request ID from when you call redirectToCheckout() ?? and what is the error you get?

frank badger
#

stripe.redirectToCheckout (JS) returns a promise with a state of pending.

craggy plaza
#

are you await 'ing that promise

#

or chaining a then() to it

frank badger
#

Chaining a then().

craggy plaza
#

I'll be stepping away but a colleague is joining
feel free to ask them qs

frank badger
#

Thank you for your time - I very much appreciate it.

foggy spoke
#

Hello! Catching up...

frank badger
#

To clarify, this is a solution that we have been using for a while now. We process a lot of transactions through Stripe.

#

We haven't made any changes in the past couple of months, but are now getting reports that the Checkout Redirect is resulting in an error.

foggy spoke
#

When exactly did this start to happen?

frank badger
#

The report came in about 6 hours ago.

#

Looking at GitHub, I don't think that we have touched this part of the codebase in 4 months.

foggy spoke
#

Is it happening for every Checkout Session or just some?

frank badger
#

As far I can tell all Checkout Sessions. We have a customer report and I have been able to reproduce the issue locally, consistently.

foggy spoke
#

Is this happening in test mode only, or also in live mode?

frank badger
#

Just tried Live for the first time, which works as expected. Therefor, I would say it has only been using Test keys.

foggy spoke
#

Does that link work for you?

frank badger
#

No. No request log found with the specified ID.

foggy spoke
#

Ah, you must be logged in to a different account.

#

Can you switch to the account with the ID ending in oXI and try the link again?

frank badger
#

Looks like the correct account, as far as I can tell.

foggy spoke
#

It does look like you're using the wrong publishable key, which belongs to a completely different account which ends with usL.

frank badger
#

Are you able to see an account name on that? Or is there a place in the dashboard that lists the account ID?

foggy spoke
frank badger
#

Ah, ok. Thanks.

#

I'm not seeing an account ending in usL.

#

Also, I can confirm that I was attempting to view the log using the account ending in oXI.

foggy spoke
frank badger
#

Yes, I can see that one.

foggy spoke
#

Hm, I guess we don't show these requests in the Dashboard... probably because they come from Checkout itself I suppose. Hang on...

#

So the publishable key you're using is the one that ends with xE1i, correct?

frank badger
#

Correct. The publishable key that I am using ends with xE1i.

foggy spoke
#

That publishable key belongs to the account ending in usL, which is why it's not working.

frank badger
#

Ah, ok. Hm... That is the publishable key returned by the OAuth connection request.

#

Or perhaps it is coming from our own connect server? Hm.

#

I'll have to look into that.

foggy spoke
#

That is the publishable key returned by the OAuth connection request.

I do not think this is the case.

#

If it was the case I think it would work.

frank badger
#

Then perhaps there is an issue with our connect server.

#

That is the key that I'm getting, but it may be what is sent by the middle man.

foggy spoke
#

Yeah, I think whatever is sending you that key is sending the wrong thing.

frank badger
#

Thanks for your help! I really appreciate it.