#rsacksteder-setup-future-usage
wild wind
prisma pine
Hi there! Jumping in for Alex, hope you don't mind 🙂
setup_future_usage only takes the values of off_session and on_session, as these are enum values defined when creating this field on our end: https://stripe.com/docs/api/payment_intents/object#payment_intent_object-setup_future_usage
It does not accept a value of null, when you don't want the payment method to be saved and set up for future use, you could simply leave out the field entirely 🙂
some text is shown about the merchant saving card details
Please let me check
Is the following text what you are referring to?
By providing your card information, you allow <name_of_your_account> to charge your card for future payments in accordance with their terms.
prisma pine
I recommend setting the terms[card] to never, this will never show the text mentioned above.
terms: {
card: "never",
},
});```
Then implement within your UI the message you would like to display when the customers check and uncheck the box.
distant scroll
@lunar onyx I've unarchived the thread
lunar onyx
Thanks @distant scroll!
distant scroll
I'll just need to catch up on the context
lunar onyx
Sure thing
Pasting my other message here so that everything is in one place...
My first follow-up question: Does the value of setup_future_usage ever effect anything besides terms? For example, are there cases where having a particular setup_future_usage value results in an additional input in the Payment Method Element? I'm asking because I want to determine if it is safe for us to wait until payment confirmation to set the value of setup_future_usage when a customer has checked our "save payment method" checkbox, or if there are gotcha's with using this particular flow. To summarize from previous conversation, we would create the Payment Intent initially with no setup_future_usage value, and then use a checkbox on our side to let the customer inform us whether they want their payment method saved, and finally upon payment confirmation, we would set the value of setup_future_usage to off_session if that checkbox is checked. We're trying to identify if this is the "best practice" flow for what we are trying to accomplish.
distant scroll
Hmmm.... 🤔
Let me test this, just a sec
Okay I can confirm that the actual inputs rendered will change depending on the setup_future_usage parameter.
In your use case, it may be a pain in the behind, but I would make an AJAX call when the user toggles the checkbox to re-create the payment intent and re-render the Payment element so you get the proper inputs.
lunar onyx
Say as a user you enter the payment inputs and then check the "save payment method" checkbox that is provided under the Payment Element. I am assuming re-rendering the Payment Element would result in the current input values being wiped out, is that correct?
lunar onyx
From a user experience perspective that seems wrong. It seems the user would want to evaluate the question "do I want to save this payment method" after they've entered their payment information, not before.
Is there a way to post events to the Payment Element iframe to inform it of changes that have occurred on our side (for example, the value of setup_future_usage changing via our checkbox, and then have it re-render itself in a way that doesn't lose information?
Also, can you give me an example of cases where the inputs change based on setup_future_usage?
distant scroll
Unfortunately not that I'm aware of.
Wait wait wait....
That was just because I had my account set up to accept ALL payment methods for USD
lunar onyx
Can you expand? I'm not sure what you're getting at has quite clicked for me?
distant scroll
The inputs don't change, I had my Payment Element set up to handle payment methods other than cards and only in those cases did the inputs change
(because those other payment methods don't support setup_for_future_usage)
lunar onyx
Can you give me an example of a payment method where that was the case? Also, is there documentation on which payment methods do and don't support setup_future_usage?
distant scroll
In my, admittedly very brief, testing I have found that only card methods appear to accept this parameter. I toggled back to the following PI configuration:
currency="usd",
automatic_payment_methods={
'enabled': True
},
setup_future_usage="off_session",
And I only saw card input options
lunar onyx
Okay, I think I understand. So you are saying you were configured to handle all payment methods and were seeing many methods presented with the Payment Element, then you updated your Payment Intent to set setup_future_usage to off_session and observed all non-card payment methods disappear from those displayed with the Payment Element. Is that correct?
distant scroll
That is what I observed in my own testing.
When I comment out the setup_future_usage parameter, the non-card payment methods are rendered within the Payment Element
lunar onyx
Okay, so based on your own testing, you are not aware of a user-facing impact that results from setting setup_future_usage to off_session aside from the presence of the terms statement? There don't appear to be changes to the card inputs (adding or removing an input) based on the value of setup_future_usage. Is that correct?
distant scroll
That is correct.
lunar onyx
Do you know if there is any official documentation on what payment methods support a setup_future_usage value of off_session? Likewise, is there a way for us to determine when terms are necessary based on the state of the Payment Intent?
plush ruin
The support for setup_future_usage is documented for each payment method type here: https://stripe.com/docs/payments/payment-methods/integration-options#additional-api-supportability
lunar onyx
Thank you @plush ruin! I'm assuming there isn't documentation on when legal terms are required based on the state of setup_future_usage?
plush ruin
You'd need to review the requirements of each payment method for that, but if you use the payment element these terms should be included in the UI for you (though you must confirm in your own test integration)
lunar onyx
@plush ruin We will check those out. In general, do you think we are following best practices for the flow we are trying to achieve with saving a payment method based on the customer's preference, or would you suggest another flow? Based on the conversation here our current plan is to generate a Payment Intent that does not set a value for setup_future_usage, then render the Payment Element (we may need to hardcode the list of payment methods to only include those that support setup_future_usage, allow the user to enter their payment details in the Payment Element inputs, allow them to check our "save payment method" checkbox if they want to have us save their payment method, and then we will set setup_future_usage to off_session at the time of confirming the payment if the customer checked the "save" checkbox. Pros: We don't have to re-render the Payment Element based on checkbox value, which could wipe out payment details that were entered and we still end up with the correct "save" state in the end. Cons: The Payment Element will not present terms or other content changes that would appear when the Payment Intent has setup_future_usage set to off_session when creating the Payment Element. For terms at least, we could accomplish something similar by presenting our own terms based on the value of our "save" checkbox.
plush ruin
Hmm after thinking about this, I don't think that will currently work with the Payment Element, which does not currently expose a setup_future_usage argument like the individual element confirmations do
However, you can make this decision for each PM type when you create the PI, choosing which to set to enable future usage when supported, eg:
https://stripe.com/docs/api/payment_intents/create#create_payment_intent-payment_method_options-card-setup_future_usage
https://stripe.com/docs/api/payment_intents/create#create_payment_intent-payment_method_options-ideal-setup_future_usage
lunar onyx
The challenge there is we want the save to be driven by the user's choice (as a result of the checkbox value), so we can set a default value for setup_future_usage upfront when creating the PI, but we need the ability to change the value of setup_future_usage if the customer changed the value of our "save payment method" checkbox. Does that make sense?
Rather than setting setup_future_usage on confirmation, I suppose we could update the Payment Intent before confirming payment. So imagine the user clicks our "Pay" button, we then read the value of our "save payment method" checkbox and if the customer wants us to save their payment method, we update the Payment Intent to have setup_future_usage set to off_session and if not, we leave the Payment Intent as is, and then after that we confirm our payment. It does feel a bit hacky, which is why I was hoping there might be a better solution we just aren't thinking of.
plush ruin
It is a bit difficult with that option and the payment element, so unfortunately there may not be another option hat this time, so we are working to make the Payment Element ore flexible to support more use cases.
lunar onyx
Are you aware of any way that we can post an event to the Payment Element iframe to have it refresh it's content accordingly, but without losing payment details that have already been entered? For example, one possible solution here would be for us to post an event that setup_future_usage has changed (whenever the "save payment method" checkbox is changed), allowing the Payment Element to handle how its content should change (terms, inputs, payment methods, etc.).
plush ruin
No, unfortunately that's not an integration pattern that's currently supported, though we are working on features related to this to make using the Payment Element easier & have more flows like yours supported.
lunar onyx
Okay, so what I've laid out (though a little hacky) is probably our best approach, and isn't inherently wrong given the uniqueness of our flow and lack of current support for it from the Payment Element?