#hendie_api

1 messages ¡ Page 1 of 1 (latest)

plain saddleBOT
inner cragBOT
#

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.

plain saddleBOT
#

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

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

blissful mica
river fable
#

but surely the future usage intent has to be stored on the payment method somewhere? I guess it's just not exposed. Our problem is we have existing tokens which have not been set up for off_session use. For those, if we specify off_session: true when we use them, we get SCA action required as an error.

#

so if we can see that a pm has NOT been set up for off_session, then we can omit the off_session: true flag

blissful mica
#

It's not exposed in the API. Note, however, that it's possible for authentication to be required even when a Payment Method has been set up for future use. You always need to account for that case.

#

If the payment is happening off-session you should always set off_session to true regardless.

river fable
#

what we've found is that with an "old" token, if we omit off_session: true, it works. If we ask for off_session: true, it fails,

#

is there a way to update payment method tokens to tag them for future_usage: off_session, if it was not done initially?

inner cragBOT
river fable
#

Also, on the topic of setup_future_usage, I can only see mention of it in payment intents docs. We set up pm tokens with setup intents - does THAT allow for setup_future_usage? Like through Elements or terminal (which is where we capture cards atm).

blissful mica
#

You can use a Setup Intent or Payment Intent with setup_future_usage while the Customer is on-session to set up an existing Payment Method for future use, even one that's already attached to the Customer.

#

Setup Intents perform the same set up as Payment Intents with setup_future_usage.

#

A Setup Intent is for when you want to set up a Payment Method for future use without taking a payment at that time.

river fable
#

cool, thanks

#

yup, that's why we use it

blissful mica
#

A Payment Intent with setup_future_usage is for when you want to set it up for future use and take a payment at the same time.

river fable
#

"even one that's already attached to the Customer." what do you mean here?

blissful mica
#

If a Customer already has a Payment Method attached.

#

Meaning you attached it in the past.

river fable
#

I mean waht API call would you use for that?

#

we don't keep record of the setup intent with which we first tokenized the card, so once it's on the customer, that's what I need to know: how do we update it then

blissful mica
#

Using a Setup Intent or a Payment Intent with setup_future_usage will attach the Payment Method to the Customer. You can also directly attach a Payment Method to a customer without setting it up for future use, but we don't recommend doing that: https://docs.stripe.com/api/payment_methods/attach

#

Again, you can set up Payment Methods for future use that have already been set up or attached previously.

river fable
#

so if I set setup_future_use: off_session with the setup intent, but don't attach it to a customer immediately, but after with pm/attach - does that retain future_use for that pm?

blissful mica
#

Yes.

#

That's an unusual flow, but it works fine.

river fable
#

still not sure how, if I have a customer with an "old" pm attached, how I would update that for future_use

#

without a sale necessarily

#

and would I need the customer present for that?>

blissful mica
#

Let's say you have a Customer with pm_abc which was attached two months ago. Today (or at any point) you can create a Setup Intent and specify that Customer and Payment Method, then confirm it.

#

The Customer should be present for this, yes.

river fable
#

hmm, ok

#

I guess they will ahve to answer an SCA challenge

blissful mica
#

They might as part of the setup process, yep.

river fable
#

I still think it would be very useful to know whether a pm was set up for future use or not

blissful mica
#

Yep, I hear you. That's a known feature request, which I'll bump internally for you.

river fable
#

I'd appreciate that

#

we'll have to work out some workaround in the mean time

blissful mica
#

Done!

#

Really the thing you want to do is set up a system that notices when you get an authentication_required decline code for an off-session payment and, when you do, your system should reach out to the Customer and bring them on-session to complete the payment and setup for future use.

river fable
#

good idea