shashank_error | Stripe Developers | Page 1

oblique joltBOT May 6, 2026, 8:32 PM

#

👋 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/1501683079436173332

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

shashank_error, 16 minutes ago, 10 messages

#

dire thorn May 6, 2026, 8:34 PM

#

Hey @jagged jetty ,
can you please help me out with this

jagged jetty May 6, 2026, 8:36 PM

#

Hello
Can you answer the questions my colleague asked in your previous thread?

this payment intent is created by your platform on a standard connected account using the stripe account header: https://dashboard.stripe.com/acct_1T40VCIfcsoWdUZW/test/logs/req_NRxxcdaY2cbqpy
Stripe Login | Sign in to the Stripe Dashboard
Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.
Are you also initializing the SDK with that stripe account context?
Like this:
import {StripeProvider} from '@stripe/stripe-react-native';

function App() {
return (
<StripeProvider
publishableKey="pk_test_51_platform_456"
stripeAccountId="acct_123"
>
{/* Your app code here */}
</StripeProvider>
);
}

https://docs.stripe.com/connect/authentication?create-client=react-native#add-the-connected-account-id-to-a-client-side-application

dire thorn May 6, 2026, 8:38 PM

#

yup sure

#

here is my initialization at root level
<StripeProvider
publishableKey={Config.STRIPEPUBKEY}
merchantIdentifier={Config.MERCHANT_ID}
>

#

@jagged jetty

oblique joltBOT May 6, 2026, 8:46 PM

#

jagged jetty May 6, 2026, 8:46 PM

#

You need to set the Connected Account ID in the Stripe Provider like my colleague suggested earlier since the PaymentIntent belongs to a connected account

dire thorn May 6, 2026, 8:47 PM

#

Can I share my updated function so that you can have quick glance?

blazing mesa May 6, 2026, 8:48 PM

#

hi! taking over for hanzo, feel free to share it

dire thorn May 6, 2026, 8:48 PM

#

sure sharing it in a moment

#

The issue I’m facing is during card payment testing.

On the simulator, when I use the test card 4000002500003155 (requires authentication), as per doc -> Stripe triggers an authentication modal and I receive an alert/error.

However, when I use the test card 4242424242424242 (successful payment flow), the payment is processed successfully without any issues.

📎 message.txt

blazing mesa May 6, 2026, 8:54 PM

#

are you including the stripeAccountId property when you initialize StripeProvider? also can you share a PaymentIntent ID for each of the examples, one for where you use 4242424242424242 and it works and another where you use 4000002500003155 and it fails?

dire thorn May 6, 2026, 8:55 PM

#

Okay I am sharing PaymentIntent ID for each

#

hey @blazing mesa ,

No, stripeAccountId is NOT currently included in our StripeProvider - that's what we believe is causing the issue, right? Is it mandatory to have stripeAccountId?

Our StripeProvider is initialized like this:

jsx
<StripeProvider
publishableKey={Config.STRIPEPUBKEY}
merchantIdentifier={Config.MERCHANT_ID}
// stripeAccountId is missing ← the problem

Query 1 -> Why 4242 4242 4242 4242 works: I believe That card doesn't require 3DS - our backend processes it off-session, creates the charge directly, and returns a full booking response. The Stripe SDK on the client is never invoked for handleNextAction, so the missing stripeAccountId never matters.
Please let me know if I am correct here ?

Query 2 ->Why 4000 0025 0000 3155 fails: That card requires 3DS, so our backend returns requires_action: true + client_secret. The client then calls handleNextAction(client_secret) at which point the SDK tries to look up the PaymentIntent using only the platform publishable key (no stripeAccountId). Since the PI was created on a connected account via the Stripe-Account header, Stripe returns resource_missing.

PaymentIntent IDs:

Our fix so far: Before calling handleNextAction, we now call initStripe with the connected account ID that the backend returns in the requires_action response.
I am also asking our backend team to include stripe_account_id in the requires_action response body.

Does this confirm the diagnosis? And should initStripe with stripeAccountId be sufficient, or do we need to set stripeAccountId on the top-level StripeProvider as well?

blazing mesa May 6, 2026, 9:03 PM

#

it looks like you forgot to include the PayementIntent IDs, can you share those? they should look like pi_XXXXXXXX

dire thorn May 6, 2026, 9:03 PM

#

Noted i am sharing it in a moment

blazing mesa May 6, 2026, 9:05 PM

#

i realized you shared an example earlier
pi_3TUASaIfcsoWdUZW0lw4QHUr

#

i was confused why the 4242424242424242 case worked, but it looks like you're doing server side confirmation so no publishable key is needed

#

so yes adding stripeAccountId and setting it to the connected account ID is 100% what will fix this 🙂

dire thorn May 6, 2026, 9:06 PM

#

4000002500003155 ->

[Checkout] Raw API response: {
"payment_intent_id": "pi_3TUCbpIfcsoWdUZW2K3QHJYR",
"payment_method_id": "pm_1TN763EYnepMuPVweR0jtVSt",
"client_secret": "pi_3TUCbpIfcsoWdUZW2K3QHJYR_secret_4xEKnhehshDndvnNnukFwLe1t",
"requires_action": true
}

blazing mesa May 6, 2026, 9:07 PM

#

what's happening is

you're creating the PaymentIntent using your secret key + the Stripe-Account header (which makes the PaymentIntent directly on the Connected account)
you're confirming the PaymentIntent using your secret key + the Stripe-Account header (which works)
you're attempting to handle 3Ds using your platform's publishable key with no Stripe-Account header

#

adding stripeAccountId to StripeProvider will fix step 3

#

the 4242 example works because you only do step 1 and 2

dire thorn May 6, 2026, 9:08 PM

#

Thanks , just needed one more confirmation here

#

@blazing mesa I have a couple of follow-up questions on the backend dependency side:

Q1 Static vs dynamic stripeAccountId: In our platform, different venues can have different Stripe connected accounts. The stripeAccountId is not always the same it depends on which venue the booking is for.

Should we:

(a) Ask our backend to return the stripe_account_id in the requires_action response body, and call initStripe({ publishableKey, stripeAccountId }) dynamically per transaction before handleNextAction?
(b) Or is there a better pattern for multi-account Connect platforms in React Native?

Q2 Re-confirmation after 3DS: Per the Stripe docs for the synchronous flow, after handleNextAction returns paymentIntent.status === 'RequiresConfirmation', we must call our backend to re-confirm the PaymentIntent (POST /v1/payment_intents/{id}/confirm).

Is this re-confirmation step still required on our backend? Or does Stripe's SDK automatically finalize it after handleNextAction completes?
If required: does the re-confirmation backend call also need the Stripe-Account header (connected account context), or just the platform secret key?

Q3 booking_id in response: We're creating the booking record server-side at the time of the initial POST /bookings. When requires_action: true is returned, is it standard practice for the backend to include the booking_id in that response so the frontend can fetch the confirmed booking after 3DS completes?

#

Waiting for your response

blazing mesa May 6, 2026, 9:23 PM

#

hello! sorry got distracted by some things

#

looking at this now

dire thorn May 6, 2026, 9:24 PM

#

no worries take your time

blazing mesa May 6, 2026, 9:31 PM

#

can you share the docs you're referring to in Q2?

dire thorn May 6, 2026, 9:32 PM

#

sure

#

https://docs.stripe.com/payments/accept-a-payment-synchronously?platform=react-native

Accept card payments without webhooks

Learn how to confirm a card payment on your server and handle card authentication requests.

blazing mesa May 6, 2026, 9:33 PM

#

ah yes then for Q2 the answer is yes this is required, and you should include the stripe-account header

#

for Q3 i think that's entirely up to you, you could do that or you could also return it when you do the second confirmation call

dire thorn May 6, 2026, 9:36 PM

#

Understood
Waiting for Q1

#

@blazing mesa 😬

blazing mesa May 6, 2026, 9:40 PM

#

sorry for the slow response, juggling a few things

#

for Q1 i think this is the right move:

Ask our backend to return the stripe_account_id in the requires_action response body, and call initStripe({ publishableKey, stripeAccountId }) dynamically per transaction before handleNextAction?
but i want to double check some things

dire thorn May 6, 2026, 9:45 PM

#

yes ,pls

blazing mesa May 6, 2026, 9:48 PM

#

just double checking, are you required to use direct charges (the stripe account header) for your use case?

#

if you were using destination charges then you could create the payment intents directly on your platform and do away with all of the Stripe-Account overhead

#

if not then calling initStripe again should work just fine

#

you should also be able to just update the stripeAccountId prop

#

depending on when you're initializing StripeProvider

dire thorn May 6, 2026, 9:58 PM

#

From what I can see on the frontend, yes our backend appears to be using direct charges.

Evidence: The PaymentIntent pi_3TUASaIfcsoWdUZW0lw4QHUr lives on connected account acct_1T40VCIfcsoWdUZW, which means the backend is creating PIs using the Stripe-Account header directly on the venue's account.

However, I'm frontend developer I didn't make this architectural decision and aren't sure if direct charges are a hard requirement for our use case (marketplace for Irish sauna venues).

Could you quickly explain:

If we switched to destination charges, what would change on the backend? (i.e., transfer_data[destination]=acct_xxx instead of the Stripe-Account header?)
Are there any regulatory or SCA implications for Ireland/EU when using destination charges vs direct charges?
If direct charges ARE required and we stick with initStripe() per-transaction — is calling initStripe again mid-session safe? Any concerns about race conditions or stale state if multiple transactions happen?
In the meantime, I;ll flag this to our backend team to confirm whether direct charges are a business requirement. I'll come back with a confirmed answer.

But I believe they won't change the architectural decision now.

blazing mesa May 6, 2026, 10:01 PM

#

yeah i would imagine that that's already baked in, just wanted to see if you knew off the top of your head 🙂 there are lots of implications for changing funds flows so i wouldn't stress too much about that path

#

but yes calling initStripe multiple times should be just fine, i know we've recommended it before for other users with similar integration patterns

dire thorn May 6, 2026, 10:07 PM

#

Perfect, means a lot
thank you for having your time .

Have a good day

#shashank_error