#mike-webhook

1 messages · Page 1 of 1 (latest)

calm otter
calm otter
#

Hi there, by design the Standard connected accounts fire webhook endpoints in the live mode.

cobalt gull
#

Oh ok...

So if I have a master Stripe account (MSA) which is connected to a standard connected account (SCA)...

And I go through payment intent flow to create + confirm payment, the payment_intent.succeeded will be sent to MSA's live webhook, by design

#

And is there no way to send it to test, as well?

#

Otherwise, we are just crossing fingers that it will work in prod when we promote our code from test to prod. 🤔

pallid marsh
#

AFAIK it's supposed to be sent to test mode endpoints as well. I'd need to look at the specific evt_xxx ID you're working with.

cobalt gull
#

Sure, evt_3KJG7vFLUcfESlJy14VT0lXT

pallid marsh
#

yeah so here it's because it's a real livemode Standard account you connected to using OAuth

#

and you used your livemode ca_xxx ID during that. So you only have a livemode connection to this account. You can still make test mode API requests, but the events don't go to your platform's test mode endpoints. I know it's weird and makes no sense, but it's just legacy behaviour to do with this type of integration

#

the way you're supposed to test this is create an explicitly test mode only account (https://stripe.com/docs/connect/standard-accounts using your test mode platform API keys) and then the events work the way you expect; using OAuth to connect to real existing Stripe accounts and use their test mode has some quirks like that one you're seeing

#

here you're using some account that's been connected to your platform since 2018, which is fine but yeah

cobalt gull
#

Hm ok. I am kind of following, let me ask my teammates.

Also, is this why I'm seeing an error when trying to use Google Pay in "connect" way?

The code is doing the following https://stripe.com/docs/stripe-js/elements/payment-request-button:

  1. It initializes Stripe: loadStripe('<MAIN_STRIPE_ACCOUNT_PUBLISHABLE_KEY>', { account: '<CONNECT_STRIPE_ACCOUNT_ID>' })
  2. const paymentRequest = stripe.paymentRequest(...)
  3. paymentRequest.canMakePayment -> returns { googlePay: true, applePay: false }
  4. Rendering <PaymentRequestButtonElement onClick={validatePayment} options={{ paymentRequest }} /> where paymentRequest is from step #3
  5. On click -> opens Google Pay, which is fine, but then Google Pay fails eventually with this error:
"DEVELOPER_ERROR in loadPaymentData: Invalid stripe:publishableKey for current environment. Make sure you are using Stripe's test key."
#

The only way I got it working is by initializing Stripe in non-connect way (by supplying the pk and account id from the same account):

loadStripe('<CONNECT_STRIPE_ACCOUNT_PUBLISHABLE_KEY>', { account: '<CONNECT_STRIPE_ACCOUNT_ID>' })

pallid marsh
#

yeah it's because you do not have a test mode connection to that connected account, which also breaks this Google Pay integration since it expects one to exist when using test mode API calls

#

it's the same thing, it's a quirk because you use some existing real Stripe account as your testing account for Connect instead of creating a new, test mode only one

#

alternatively you can fix both problems by creating a test mode connection to the account, which you'd do by running https://stripe.com/docs/connect/oauth-standard-accounts , using your test mode client ID ca_xxx from your Connect settings(https://dashboard.stripe.com/account/applications/settings) and having the owner of the account authorise it. But usually it's easier to do what I said above and create a new testmode only account. Since presumably that is what you will be doing in livemode (creating accounts through the API) and won't be using OAuth.

grand swan
#

Would this be an alternative?
loadStripe('<MAIN_STRIPE_ACCOUNT_PUBLISHABLE_KEY>')

Then pass:
{
stripeAccount: <acct_connect_id>
} with each call

Would that work?

#

Also, are you saying that since the accounts are older, the connect account is connected to the platform account using oauth and not some newer method?

pallid marsh
pallid marsh
grand swan
#

How do we check what kind of account we have? from settings in dashboard?

#

So for a connect account which is
standard account: the front end client can make test mode and live calls to
oauth-standard-account: the front end client can make only live mode calls to
Is that correct?

pallid marsh
pallid marsh
# grand swan So for a connect account which is standard account: the front end client can mak...

I would say :
standard account: you create the account either in test mode or live, depending on your environment. All test mode things(Google Pay on the frontend, webhooks), work as expected using test mode keys and endpoints.

oauth-standard-account: you can connect to an account using either your livemode or test mode ca_xxx OAuth credential. If you connect in livemode, you can make testmode API requests but get quirks like the GPay/Event issues in this thread. IF you connect in tesmode, then everything works as expected. Note if you have only a livemode connection(which is the case for that account we talked about earlier), you can do OAuth a second time to get a testmode one as well.

#

there's really no reason to use OAuth, nowadays it's only for "extensions" that want read-only access to existing Stripe accounts, if you're doing actual payments you should just what our guides say, which is https://stripe.com/docs/connect/standard-accounts .

grand swan
#

so, our existing accounts are old, which enables us to use them in both live mode and test mode ( depending on which ca_xxx we pass ).
We're getting the quirk because we connected in live mode but are trying to make a test mode API request?
So this won't be a problem if we connect in test mode instead and then make a test mode API request?

#

Does this sound right?

pallid marsh
#

yes

grand swan
#

Also, are accounts which are as old as 2018 likely to be oauth-standard-accounts and not standard-accounts?

pallid marsh
#

they have to be, since the ability to create Standard Accounts via the API was only released in I think late 2020

#

if you were using Connect before then, you were using OAuth

#

but nowadays it's only for "extensions" that want read-only access to existing Stripe accounts

grand swan
#

And migrating an old oauth-standard-account to a standard account is possible/desired?

#

Also is it an issue if there's a:
A Platform Account (OSA) <---> 2 Connected Accounts(OSA) + New Connected Account(SA)?

Where OSA = Oauth standard account
SA = Standard account

pallid marsh
grand swan
#

Is this correct:
ca_xxx determines whether the client is in live or test mode?

pallid marsh
pallid marsh
# grand swan Is this correct: ca_xxx determines whether the client is in live or test mode?

not really. Sorry, this is complicated.

When you use OAuth, you connect to an existing Stripe account(or we might create one if the user doesn't have one). That is a full, real Stripe account, the user can add information to it and use it to process real payments one day. Let's call it a "production" account.
There's then a separate concept of a "connection" between your platform and that real Stripe account. If you use your testmode ca_xxx from https://dashboard.stripe.com/account/applications/settings during OAuth, you get a test mode connection. If you use the livemode ca_xxx you get a livemode connection.

The testmode connection lets you call the API in test mode for that account, and things like events/GPay work as expected in testmode.
The livemode connection lets you all the API in live mode and test mode for that account, but because you don't also have a testmode connection, things like events/GPay don't work.

When you use the API to create an account(https://stripe.com/docs/connect/standard-accounts) with a testmode key, that is not a real account, it's not "production", it can never go live. You just use it with test mode API keys and everything in test mode works.
When you use the API to create an account(https://stripe.com/docs/connect/standard-accounts) with a livemode key, that is a real account, it is "production", it can go live. You use it with livemode API keys and everything in livemode works.

You really should not be connecting to a real account in livemode and then calling the testmode API, although it was common in the past. Really it's quite simple, as I said earlier, just create new test mode accounts (using the API, or OAuth with test mode ca_xxx, whichever) and use that for your testing today(since the whole point is you want to test how you will onboard and use accounts today when you go live?), don't just rely on this old account you happen to have connected to your platform.

grand swan
#

So, you're suggesting we try the standard account way of connecting during our testing since the likely new account would be standard account?

#

However, for now, if we were to use the existing OSA connect account and have the client send a test mode call what do we need to change?

pallid marsh
pallid marsh
#

i..e you create another OAuth link and visit it while logged into that connected account. I personally think it's much easier to just create brand new accounts and test that way and just ignore all this, we're overcomplicating something that is really quite simple.

#

I have to go, my colleague @lone bobcat will help if you have any questions after you've reviewed what we discussed above

grand swan
#

Thanks for all the help