donklitschko_api

[lost minnow]

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

📝 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.

• donklitschko_api, 2 days ago, 6 messages

[split kraken]

Hi there 👋 most of our guides for this kind of flow include a step showing how to charge the saved payment method later, like this one:
https://docs.stripe.com/payments/save-during-payment?lang=node#charge-saved-payment-method

The key thing to indicate typically is whether or not the customer is on-session (actively on your webpage) or not, which is done via the off_session parameter.

[fervent bramble]

most of these payments will be off-session.

we just wanted to clarify that if we run a one-off payment or we create a repeat payment schedule for the customer, that we wouldnt need to flag those differently

on the same train of thought, are off-sessions transactions more likely to result in subsequent declines when trying to run a new payment than on-session?

i.e. is an on-session payment more likely to allow future off-session payments,?

[split kraken]

Generally no. The only thing coming to mind where that may not be the case, is if you're accepting a type of payment method where you have to specify the terms of the future payments when beginning the transaction, so the Mandate can include those details.

[split kraken]

Generally, requesting the ability to process future payments will trigger customer authentication (maybe not if you're mostly operating in the US), which the customer will need to be on-session to complete.

With regards to overall auth rates, that's not insight that I have.

[fervent bramble]

we are only working on card payment methods currently.. what exactly do you mean by "where you have to specify the terms of the future payments when beginning the transaction, so the Mandate can include those details."?

[split kraken]

It doesn't matter if you're only working with cards.

[fervent bramble]

is it possible to save card payment details for a future payment when the customer is not making the payment?
i.e. are you saying that the first payment needs to be an ecom payment (and cant be a moto payment)?

[split kraken]

Yes, one of our guides for that is here:
https://docs.stripe.com/payments/save-and-reuse

[fervent bramble]

oh.. is this just referring to the compliance that the customer needs to be made aware that the details will be stored?

[split kraken]

Yup.

[fervent bramble]

thanks for the help!