#nobody_code
stark cairnBOT
👋 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/1270432487134331001
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
fluid river
If you scroll through these images you can see the problem. The message at the bottom doesn't go away when the setupFutureUsage option is re-disabled
<Elements stripe={stripePromise} options={options}>
<StripePaymentElement setCreateConfirmationToken={setCreateConfirmationToken}/>
</Elements>
return (
<PaymentElement />
);
This is the payment element i'm using
crude gust
Hi, it looks like you're passing 'setupFutureUsage': https://docs.stripe.com/payments/accept-a-payment-deferred?platform=web&type=payment#additional-options which enables you to save payment methods for future use. What do you mean by 're-disabled'?
fluid river
Yes. So you can see here, I'm passing setupFutureUsage based on a variable.
Initially it's passed as undefined, and no message shows on the payment element.
If i change the options to "on_session", a message warning the customer appears.
If I toggle it to undefined again, it still shows the warning message to the customer
crude gust
Are you reloading the element when you make these changes?
fluid river
Like i said in the post, I can reload it, but it wipes the credit card info.
Unless stripe supports a soft reload i'm not aware of.
crude gust
No, there is not. I think the better way here is to offer a UI where they can toggle this before you present the Element. Then, you can pass the desired behavior on 'setupFutureUsage'
fluid river
But fiverr uses stripe and they don't have that problem
It doesn't feel right to ask someone to save their card for later before they're on the payment screen.
crude gust
If they can toggle that off, why are you trying to get that message to disappear? I'm testing this on my end as well
fluid river
Well the message is saying "you allow <company> to use your credit card for future payments". So if the user has un-checked the "save for future payments" box, then that message definitely shouldn't appear anymore
I think this is a bug in the stripe element, it never un-renders the message
crude gust
Well, as a customer, if I untoggled it and then I decided to change my mind, I would want that option present.
I do not think it's supposed to un-render.
fluid river
It's not an option man, it's the message
It's the warning message embedded on the element
As a customer when you click "I no longer want my card saved by stripe" the message still says "you're saving your card in stripe"
crude gust
Where do you see this 'I no longer want my card saved by stripe'?
I think we're talking passed each other.
fluid river
Probably
fluid river
Did you pan through these images? Click on the big one and then press the right arrow to see the user flow as they click "save payment for later" and then they toggle "unsave payment for later"
You can see originally the message wasn't there, because the user wasn't saving their payment for later, but when they unclick the box, the message remains
crude gust
I think that is how it is supposed to work. You're referring to the 'Save this card for future payments' message right?
fluid river
Yes
But from the user's perspective it feels like it's still saving the card for the future, even when the option is no longer toggled
Why else would the message not appear initially
stark cairnBOT
night skiff
Hello
catching up here
fluid river
Hey man sounds good
night skiff
I haven't tested this myself but one workaround could be to call element.update(...) and set terms to never
The other screenshot you shared from fiver makes me think they don't render terms at all
fluid river
its strange, i dont see the option to disable terms here
night skiff
I think you're looking as the parent Element object.
element obj in the docs I shared above, refers to PaymentElement itself
did that help? @fluid river
fluid river
Sorry I'm trying to test it out but I'm having a bit of trouble, I'm not sure what to pass into "getElement"?
'payment' was the example on the docs but i'm not convinced it's working
night skiff
Ah since you're using react, it might be a bit different
fluid river
I printed the element and maybe it retrieved the right element actually? This is the value of paymentElement
I thought it hadn't because i can't get the .update function to visibly change the element
night skiff
IS that working?
fluid river
No, nothing is changed at the moment
night skiff
What happens if you set
<PaymentElement options={{ terms: { card: 'never' } }} />
That worked!! Thank you
night skiff
Great! You can also place that as conditional I think..
<PaymentElement options={{ terms: { card: someVar } }} />
where someVar is a state variable that changes to auto if the checkbox to save payment method is selected and never if checkbox is unselected
fluid river
Ahh yeah that's perfect thanks man i appreciate it
Could i still ask some other random (not coding) questions here or is it best to make new threads for those?
They're not big so i feel weird making a whole thread
night skiff
This discord is for Stripe APIs/SDKs coding related qs so I don't know how much I can help 😅 but sure
fluid river
Fair enough no worries if not!
I just noticed, on this calculator on the docs, it doesn't let you select the recipient service agreement when your platform country AND account country are in the US
Yet this example in the docs literally uses US recipient in their example:
I intend for all my connected accounts to be recipient. So I just want to make sure it's the calculator which is wrong
night skiff
I don't think the calculator is wrong. I believe it is this: https://docs.stripe.com/connect/cross-border-payouts#:~:text=US connected accounts don’t support cross-border payouts%3B onboard US connected accounts using the full terms of service
The example is wrong
fluid river
I don't think the calculator is wrong. I believe it is this: https://docs.stripe...
You're saying: since cross-border payouts doesn't list united states, therefore united states doesn't offer recipient agreement?
night skiff
Correct, US connected accounts don’t support cross-border payouts. So they need to have full ToS agreement.
night skiff
To reword the docs, connected accounts created in the United states do not support recipient ToS agreement. If you try to create an account like the docs say, you'd receive an API error (just tried it myself)
I don't know if there are any exceptions here though (like if your platform only creates connected accounts in the US and does not use cross border payouts).. I'd recommend checking with our support team to see if there are any exceptions/workarounds:
https://support.stripe.com/?contact=true