#xaositect_code
1 messages ยท Page 1 of 1 (latest)
๐ 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/1399505411714973850
๐ Have more to share? Add more details, code, screenshots, videos, etc. below.
Hi there
Hello ๐
So you are saying you still the option to verify with microdeposits?
Or manually enter account details?
I want to disable the option to verify with microdeposits.
Oh sorry you are using Payment Intents so that's this doc: https://docs.stripe.com/payments/ach-direct-debit/accept-a-payment?web-or-mobile=web&payments-ui-type=direct-api#instant-only-verification
huh, I tried that, didn't seem to have any effect.
~Ahhh I have to specify payment_method_types to get it to work~ lies
Yeah that doesn't seem to work for me.
Can you share the Payment Intent ID?
pi_3RpysUG2avTULfw30S8giTYj
I'm using a customer session though, not a checkout session
Sorry what is the context for this?
We are using a secret from a customerSession and a secret from a paymentIntent to instantiate <Elements ... /> and its child <PaymentElement ... />
This was as a result of a conversation with our acct manager James Matheson and his colleague Solutions Engineers Savannah & Sofia, after our continued difficulties displaying previously saved payment methods using a checkoutSession and a custom checkout element.
Okay hmmm... let me test something out here
Okay without the Customer Session, I don't see the option to manually enter bank details when I create a similar Payment Intent.
Let me test with a customer + session
my customerSession code is like this:
const customerSession = await stripe.customerSessions.create( {
customer: contact.customer.stripeCustomerId,
components: {
payment_element: {
enabled: true,
features: {
payment_method_redisplay: ctx.jwt?.id ? 'enabled' : 'disabled',
},
},
},
} );
I just tested again and I don't see the manual details link
I added more features but I wouldn't expect that to change the behavior
session = stripe.CustomerSession.create(
customer=CARD_CUSTOOMER,
components={
"payment_element": {
"features": {
"payment_method_allow_redisplay_filters": ["always", "limited"],
"payment_method_redisplay": "enabled",
"payment_method_save": "enabled",
"payment_method_save_usage": "off_session",
},
"enabled": True,
}
},
)
hmmm, the params in the frontend look like this:
<Elements
stripe={ stripePromise }
options={ {
clientSecret: embeddedCheckoutClientSecret,
customerSessionClientSecret: embeddedCheckoutCustomerSecret,
...stripeTheme,
} }
>
stripeTheme is just styling stuff
and
<PaymentElement
onChange={ onChange }
onReady={ onReady }
options={ {
layout: {
type: 'tabs',
defaultCollapsed: true,
},
defaultValues: {
billingDetails: {
name: `${ contact.firstName } ${ contact.lastName }`,
email: contact.customer?.email,
},
},
} }
/>
I'll see if altering my session to be like yours does anything
When I attempt to add payment_method_save_usage i get an api error req_N2tPAj7QuC6eUl
fyi i'm taking over the thread! catching up now
that specific error is because you're passing in payment_method_save_usage without enabling payment_method_save
try adding components.payment_element.features.payment_method_save: "enabled" to your request
Oh yeah, duh silly me. Sorry, I'm feeling increasingly, wildly over my time budget and... that never does anyone any favors.
hahahahaha no worries ๐
Sadly, however, I'm still seeing the 'Enter Bank details manually' option ๐
hmmmmmmmmmm
i am a little bit baffled on this
any chance you have a publically accessible link where i can reproduce the frontend flow?
could it be an api version later than the one I'm using?
It would take about 20 minutes for my push to propagate
i tried this on the same API version you're using and i'm also not able to reproduce
let me try a few more things
can you try just stripping your integration down to the very basics real quick? just create a payment intent with these options and render that in a payment element, no customer session or anything:
amount: 1099, // integer
currency: "usd",
payment_method_options: {
us_bank_account: {
verification_method: "instant"
}
},
payment_method_types: ["us_bank_account"]
}
Yup, I've also just started a push of my latest code
okay, passing in only those params to my paymentINtent pi_3RpzpOG2avTULfw300qe6saC
๐ฅ drumroll
in the f/e:
<Elements
stripe={ stripePromise }
options={ {
clientSecret: embeddedCheckoutClientSecret,
// customerSessionClientSecret: embeddedCheckoutCustomerSecret,
// ...stripeTheme,
} }
>
no options on the payment element
still the same business
:sigh:
f/e package versions:
"@stripe/react-stripe-js": "3.7.0",
"@stripe/stripe-js": "7.4.0",
It is weird because my colleague can get it to not show, but he's using 'setup' mode
hmm yep, even if i use the same frontend versions i'm seeing the expected behavior
just to throw all the spaghetti at the wall, you're not doing anything odd like hardcoding your client secret for testing purposes? you're 100% sure that the same payment intent being generated by your backend is the one being displayed in the payment element?
Oh I only ever hard code my secret in the backend when I'm local-testing webhooks ๐คฃ
But the client secret is an interesting question, could Apollo be the problem?
are we talking the state management library or something else?
yeah the state mgmt library, let me add a clog or two
we've had caching issues before without ids
you could try to log out the client secret to the console just to check it matches
it's prefixed with the payment intent ID so you can use that to make sure it lines up
yeah, they both match what is being generated in the backend
backend is still building, between Cursor's enthusiastic autocompletion and typescript, I feel like a bullied child. Should be a few more minutes.
if we can get the barebones version running in a publically accessible site that would be ideal
like snufkin said earlier none of the other things you're doing (customer session etc) should make a difference but it's nice to simplify variables still
Okay that may be okay, the latest build was a reversion of barebones in the backend...
let me check
also just to throw more spaghetti at the wall, have you tried loading the page in an incognito window or a new browser?
nah incognito doesn't make a diff in firefox, lemme try chrome
nope chrome is not the answer either
i figured it wouldn't help but it was worth a shot ๐คท
The deployed f/e version is not barebones... wanna wait for that?
let me give it a shot as is
do you have an ip address I can add to our WAF IP lists so you can get through the wall?
https://charlie.rockpapercoin.com/quickPayment/cmdnpws9g0001qh1atduwl6m9I assume if you go here you'll get nothing or errors without that.
yeah i'm getting a 404, 1 second on IP address
yay the walls are working!
If you don't have an IP address to share I can probably disable for a moment.
yeah try disabling for a bit
Okay I have opened the floodgates try again here in a second
still getting the 404
Sorry there were some weird negations in there... I just updated... again
Disregard the amounts that show at the top of the qp, I didn't update the frontend gui for the hardcoded values
hmmm i'm still getting the 404
:frantic_squirrel:
Okay, I deleted the rule, I'll just have to recreate it later.
have you tried doing a setupintent to see if you're able to get it to display properly there? you said your colleague was able to get that working properly?
I haven't yet. In fact I was just thinking that I should go look at his PRs and see if there is some other trick to what he's doing. How about we call this a draw and if I am still stuck in the AM I'll come back and complain some more?
I feel like I'm just adrenaline-reacting stupidly at this point.
yep that sounds reasonable to me!
i still think it's extremely likely that there's just something small that we're missing
I entirely agree. There's probably some tiny thing I've overlooked.
If everyone else can get it to work... the problem is me.
hahaha
or it's a problem with us and we just haven't been able to isolate the variable that's causing the problem
Well, lets hope the problem is me and late afternoon brain.
๐ค
Have a lovely evening, and thanks for your help
you too! sorry we weren't able to get to the bottom of it, hopefully you'll be able to find some little thing with a fresh brain in the morning
๐
i might also run this by some colleagues just to get their thoughts on it, so i'm going to keep the thread open for just a bit longer. if i do find anything of interest i'll drop updates here
Thank you!
Could it be related to this console error?
I'm not submitting an deferred intent
looking now! sorry, got caught up in another issue
you said you're not passing any options in with the payment element options right?
i guess it's possible that maybe you are and the element is operating in deferred intent mode, ignoring the client secret?
perhaps. Sorry I'd been troubled by that console error for some days
error { message: "You may only specify one of these parameters: client_secret, deferred_intent.", param: "client_secret", type: "invalid_request_error" }
Hi @urban gorge I'm taking over this thread. Give me a sec to catch up
It is looOOoooong.
Ok, looks like you specified both clientSecret and deferred_intent options like amount and currency
Are you doing a deferred intent integration (https://docs.stripe.com/payments/accept-a-payment-deferred) ? e.g., render the payment element first before creating a PaymentIntent ?
No I'm passing in both a payment intent secret and a customer session secret, but I do have a useEffect which attempts to change the amount paid depending on the payment method selected:
useEffect( () => {
if ( ready ) {
elements?.update( {
amount: paymentAmount,
mode: 'payment',
currency: 'usd',
} );
}
// not including elements in the dependency array because it causes a loop
// eslint-disable-next-line react-hooks/exhaustive-deps
}, [ paymentAmount, ready ] );
Lets see what happens when I disable it. I hope this isn't the source of the problem.
Yup, we found the problem!
ugh.
How might one preserve this functionality and not create the error ( which is the source of the reason why I opened the thread, apparently )
https://docs.stripe.com/js/elements_object/fetch_updates#elements_fetch_updates Since you are not using non-deferred intent flow, you should update the amount on the PaymentIntent, and call elemenets.fetchUpdates() to reflect the changes on the PaymentElement.
so... call the backend, update the payment intent, and then fetchUpdates();
Well that's ponderous. Thank you for helping me get to the bottom of this.
alright that's me signing of for the night. ๐
Happy to help!