#eliasao_api
shy marshBOT
đź‘‹ 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/1327337032711803064
đź“ť 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.
- eliasao_api, 1 day ago, 10 messages
short heron
Hi there
stone jetty
Hey 👋🏻
short heron
Including it for SetupIntents and Terminal makes sense. It should be included when you're creating a PI and saving payment method details for the first time with that PI (PI + setup_future_usage). No need to include it when creating a PI if you're passing a saved PM and using off_session
stone jetty
Thanks for the answer -
I can see that by using the stripe element it already shows the user a disclaimer saying that our provider will store the customer credit card for future purchases. But when using a hosted field form, do we need to include a disclaimer like that as well?
short heron
Checkout (in payment mode when using setup_future_usage and subscription mode) will show that disclaimer automatically
stone jetty
So all I need to do really is just send the allow_redisplay field through the API and it should be good? No other user interface work really needed. Can you confirm that?
short heron
Taking a step back, which integration flow are you using to display saved payment methods to your customers? Are you using Checkout or the PaymentElement?
stone jetty
payment element and a older integration with built in by hand hosted fields - no checkout.
short heron
Okay, got it. So once payment methods have been saved to a specific customer, there is some frontend work you'll need to do: https://docs.stripe.com/payments/accept-a-payment?platform=web&ui=elements#enable-saving-the-payment-method-in-the-payment-element
shy marshBOT
short heron
By that I mean you'll need to create a CustomerSession in the backend for that specific customer, then pass the CustomerSession client secret to your frontend so you render the PaymentElement for that specific customer (and display the saved payment methods that are eligible to be redisplayed)
stone jetty
My use case needs to work with off_session payments, not really on session. A customer purchases an activity through a widget in one of our partners website, then the partner can use the card later to do additional charges in a separate back-office system, for example using the customer card to buy an additional Water Bottle. The customer is always interacting only one time with the purchase. But the partner can interact with the saved card multiple times.
Lets take this example you've sent me. If I were to create only the payment intent, passing setup_future_usage: "off_session" to it, without creating the customer session, would it still work or would I need the allow_redisplay flag? that is currently what I'm doing but not passing the allow_redisplay flag.
pure nimbus
Hi, stepping in and catching up
pure nimbus
What does 'partner' mean on this case? Can you add more details?
To me, 'Lets take this example you've sent me. If I were to create only the payment intent, passing setup_future_usage: "off_session" to it, without creating the customer session, would it still work or would I need the allow_redisplay flag?' does not make sense. If it's off_session payments, why would display this data? You would just charge the customer with the payment method id
stone jetty
That's my question really, I must have misunderstood what allow_redisplay flag meant.
I thought it was supposed to be always included in any kind of off session payments. But it seems to not be the case, right?
I'm working with PEEK - our partners are any company that offers an experience, for example a Museum is our partner. You can book online tickets through our widget that the museum put on their website and then the museum operator could charge an additional water bottle or something like that directly with the card that was used to buy the experience, when the customer goes to visit the museum for example.
pure nimbus
Ah, yeah there is a misunderstanding here. To achieve what you'd like, you can pass https://docs.stripe.com/api/payment_intents/create#create_payment_intent-setup_future_usage
What you wrote in about is different. We document a bit more about it here: https://docs.stripe.com/changelog/acacia/2024-12-18/cards-sources-allow-redisplay
This field indicates whether this payment method can be shown again to its customer in a checkout flow. Stripe products such as Checkout and Elements use this field to determine whether a payment method can be shown as a saved payment method in a checkout flow.
Since the customer won't be there to see their card, you do not need to use it.
stone jetty
Ah, yeah there is a misunderstanding here. To achieve what you'd like, you can p...
Our understanding was that this would no longer work at all without the allow_redisplay flag together.
stone jetty
it was a compliance email that said:
-
When creating Terminal PaymentIntents, pass the setup_future_usage parameter, which informs Stripe that you would like to make future payments with the same card.
-
You’ll also need to pass allow_redisplay as always or limited via your Terminal SDK or server-driven integration (SDI). Pass always if you want the customer’s saved card to be presented to them in all future checkout flows, and limited if it can only be used in the context of the initially scoped use (e.g. a subscription). For more details on how to implement this, visit our docs.
and for setup intents:
Saving cards with SetupIntents
To ensure a consistent integration shape between SetupIntents and PaymentIntents, as well as in-person and online transactions, we’re removing the customer_consent_collected parameter previously required on all SetupIntents transactions, and replacing it with the allow_redisplay parameter.
You must add the new parameter to your SetupIntents integration and ensure that it’s set to always or limited on all SetupIntents transactions. Pass always if you want the customer’s saved card to be presented to them in all future checkout flows, and limited if it can only be used in the context of the initially scoped use (e.g. a subscription). For more details on how to implement this, visit our docs.
pure nimbus
It's Terminal.. In your flow, the customer would be present when making the purchase for the ticket. You saved that payment method and would use that to charge them in the meseum via Terminal? Or, are you running the charge on your server side?
stone jetty
The customer would be present to make the ticket by swiping the card. But we store the card off_session if the customer wants to book again another day or purchase additional items at the end of the experience.
pure nimbus
Ah, I see. I think I understand the flow now.
stone jetty
I guess internally we thought that this was related with any kind of setup_future_usage: off_session usage.
It seems that this is only going to be a break change only for Terminal and SetupIntents.
pure nimbus
Yeah this parameter wasn't required previously. We've updated the flow to meet the requirements of the supported regions and that means integrations using setup_future_usage parameter to save the cards with Terminal will also need to pass allow_redisplay parameter.
Then, when you're ready to charge, you should just be able to charge on your server-side.
Let me confirm this as well, hang tight
stone jetty
and for SetupIntents too, right? We have a very specific SetupIntents usage that allows the customer to "hold a spot" on an experience by filling their cc info online but not purchasing anything.
pure nimbus
Yes!
stone jetty
in this case, we would also need to pass allow_redisplay there right? and not worry about any kind of user experience change
pure nimbus
Trying to confirm if you're need to make any changes as you're just saving the card details, then making a server-side call to make another purchase
From looking at our guide, that should just work, https://docs.stripe.com/terminal/features/saving-cards/save-after-payment?terminal-sdk-platform=server-driven#access-generated-card. Given that you're making a call on the server-side to create the PaymentIntent it would work as that is what it is intended.
I recommend that you try this in test mode, and confirm as well
Please ensure that you're using the latest API version when you make these test requests
shy marshBOT
stone jetty
From looking at our guide, that should just work, https://docs.stripe.com/termin...
by just work you mean not even need the allow_redisplay flag at all for this use case?
pure nimbus
No, pass allow_redisplay and make the request on your server-side call to charge the customer with the payment method.
midnight hill
I just tested and we require some allow_redisplay value to be passed
You must specify `allow_redisplay` as `always` or `limited` when saving payment methods with Terminal.