#Matt11-off session
1 messages ยท Page 1 of 1 (latest)
๐ happy to help
that's a really great question
setup_future_usage is telling the PaymentIntent API that you would love to save the card details for future usage
this usage might be on_session meaning that the customer would be on your app while the payment will subsequently happen, or off_session meaning that you will be doing the payment obo the customer
the off_session parameter on the other hand tells the PaymentIntent API that you are doing the payment obo the customer
so the setup_future_usage: 'off_session' is used on the PaymentIntent(PI) that would save the PaymentMethod(PM) and in the subsequent PIs the off_session: true is used to use that saved PM knowing that the customer isn't around to authenticate
it also tells the issuing bank that the customer isn't present and might give the possibility of SCA exemption
Ok, can I try to explain to you my current platform situation?
so maybe you can address me to the best solution?
yes sure
Thanks!
So, in this platform we have two types of plans:
1- one with 7 days trial period + 365 days subscription
2- with only 365 days of subscription
At the signup the customer can pick one of these and enter the card data into the stripe elements form.
If he select the 'trial' plan I create a SetupIntent with this API and parameters:
setup_intent = ::Stripe::SetupIntent.create({
customer: user.stripe_customer_id,
payment_method_types: ['card'],
usage: 'off_session',
payment_method: payment_method_id
})
::Stripe::SetupIntent.confirm(
setup_intent.id,
{ payment_method: payment_method_id }
)
otherwise for the other plan he need to pay immediately and I do like this:
payment_intent = ::Stripe::PaymentIntent.create({
amount: amount,
customer: user.stripe_customer_id,
currency: 'eur',
payment_method_types: ['card'],
setup_future_usage: 'off_session',
payment_method: payment_method_id
})
::Stripe::PaymentIntent.confirm(
payment_intent.id,
{ payment_method: payment_method_id }
)
I'm doing 'off_session' logic because when the 'trial' or the actual 'subscription' expires, we have an automatic nightly script that creates the first payment_intent for those coming from 'trial' or another payment_intent for those coming from a full 'subscription'.
So the user if of course off-session
I don't see the reason behind you doing that to be honest
there's a simpler solution
you can create the subscription with payment_settings.save_default_payment_method: "on_subscription" (https://stripe.com/docs/api/subscriptions/create#create_subscription-payment_settings-save_default_payment_method) and expand on latest_invoice.payment_intent get the client_secret of that payment intent and send it to the front-end where you would use a PaymentElement or CardElement to gather the Payment Method data. once that is done everything would be setup for you
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
the customer don't want to use Subscriptions, we just switched from Subscriptions to one-shot payments ๐
I'm doing 'off_session' logic because when the 'trial' or the actual 'subscription' expires
I'm lost
are you or aren't you using Subscriptions?
if you're not there is no notion of trial
nor time
Sorry, I have the notion of trial and subscriptions inside my database.
I have this table with "from" and "to" dates that determine if a customer is active or not and the boolean "trial" that determine if the customer is inside the trial period or not
so there's nothing to do with Stripe Subscriptions
our platform has the logic and decide if a customer need to collect data or create a payment on stripe
so there will never be a recurring payment?
yes, when a "from-to" period expire the automatic script creates year "subscription" (for our database) and creates another payment
but the customer don't want stripe subscriptions because he wants all the data inside our database to share them with our others payment methods
actually the ultimate way of doing this is to use Stripe Subscriptions and listen to the webhook events we send and update your database accordingly
sorry but it is not a way we can take ๐
ok I can hear that, but it's really a waste of time/money/resources to reinvent the wheel
I will help you out
and will guide you through whatever integration that you want to implement
but unfortunately I need to find a solution with payment_intents
I was just a bit upset for you, that you would have to build a scheduler and cron jobs and a lot of unnecessary things to accomplish something you already have access to
yes we will
just give me a sec
thanks ๐ it was a lot of work of course
but I tell you, everything is already working but I need to understand if I can improve it a little bit. Because, rarely, we face a weird behaviour with 3DS
yes I understand
let me take a few minutes then to write my detailed answer for you
wait, I'll tell you one more thing
the "3DS issue" is that I see a lot of payments with "requires_actions" even if the card was already linked to customer, and I would like to minimize them. This is why I asked about off_session: true and setup_future_usage: 'off_session'
yes I knew you were going to say that
this happens when the issuing bank decides that the "off_session" payment method is not "safe" and requires the authentication of the customer
in that case you'd have to ask your customer to come back to your platform and do the payment "on_session"
this is why you are a Stripe expert ๐
no
it's the most common use case when it comes to 3DS and off_session
I think that after this mega refactor I can work in Stripe too ๐
it's really up to the issuing bank's discretion to either permit or not the payment without 3DS
ok but why with stripe subscriptions this problem did not exist? or exited less times than now?
or maybe I didn't noticed because I cannot see payments but only invoices from dashboard?
It's not related to the product