mesudev

[gritty verge]

Sure, could you elaborate?

[dusty thicket]

sure thing

so the main issue is that auth and capture only works with a time lapse of max 7 days. In my platform, it is however that services are booked 3 weeks before they will be provided; meaning I cannot always trigger the authorization the day of the booking, as that would lead to chained holds, which your colleagues recommended me not to do.

After a few chats, I've now setup a flow that is described in a flowchart I've drawn in a miroboard; would you mind having a look at it? Guess that would be the easiest way to go

up to 3 weeks *

[rich frost]

Hey! Taking over for my colleague. Yes of course feel free to share the flow

[dusty thicket]

cheers!

I'm particularly wondering about the mentioned key-value pairs I set for setup and payment intent creations; wherever they're written

but yeah, you may enlighten me on whatever is not good in your opinion

[rich frost]

Thanks for sharing,
It looks like you are following this guide:
https://stripe.com/docs/payments/save-and-reuse?platform=web
To resume you need to save the PaymentMethod using SetupIntent and then charge it off_session using PaymentIntents

[dusty thicket]

but using off_session means you have to use confirm => true

meaning I cannot capture manually / auth & capt, no?

[rich frost]

but using off_session means you have to use confirm => true
Yes as mentioned here
https://stripe.com/docs/payments/save-and-reuse?platform=web#charge-saved-payment-method

meaning I cannot capture manually / auth & capt, no?
As you mentioned in your explanation, you can use Separate authorization and manual capture no more that 7 days time lapse

[dusty thicket]

I'd still like to use auth and capture according to my flowchart

still there?

[rich frost]

Yes I'm, you can't do auth and capture above 3 weeks, sorry but again, if you the delay isn't enough for you, then you need to use SetupIntent

and off_session payments without manual capture

[dusty thicket]

Which is what I'm doing, as the flow says I'm using

1. Create Setup Intent with usage => "off_session"

2. If service takes place within 6 days; immediately (hence on session) try to authorize payment by creating a payment intent with:

confirm = false
off_session = false
setup_future_usage = off_session
capture_method = manual

Then capture after service has been provided.

3. If service takes place within more than 6 days, store a record in the DB that informs that payment of service must still be authorized. Once the day 6 times before the booked service is reached, try to authorize the payment off session (as this authorization is triggered server-side, via cronjob schedule), using:

confirm = false
off_session = false
setup_future_usage = off_session
capture_method = manual

You mention that I must create the payment intent using:

confirm = true
off_session = true

But isn't that incompatible with

capture_method = manual?

I though that

confirm = true

would immediately capture the payment intent?

[rich frost]

I want to mention that the delay 7 days it vares from bank to bank but it's up to 7 days, the 6 day limit is not accurate because you may have some case where the authorization could just last 3 days for example
https://stripe.com/docs/payments/place-a-hold-on-a-payment-method#:~:text=For card payments%2C the amount is on hold for up to 7 days

If you have cases where the delay can be more than the authorization periode, then I recommend you to unify the process and simply just use the save and use for future payments

You can simplify your flow and make it more accurate by following this guide
https://stripe.com/docs/payments/save-and-reuse?platform=web#charge-saved-payment-method

[dusty thicket]

Hmm but my platform only allows cc payments and Apple Pay and Google Pay; there it's always 7 days, no?

[dusty thicket]

yup I'm doing exactly this as you can see in my flowchart. What I wonder though is if I can authorize a payment intent that has

confirm = true
off_session = true

Hence create a payment intent with

confirm = true
off_session = true
setup_future_usage = off_session
capture_method = manual

?

[rich frost]

Hmm but my platform only allows cc payments and Apple Pay and Google Pay; there it's always 7 days, no?
Google Pay or Apple pay, are using bank card behind, so the delay may still varies and depends on those banks

[rich frost]

Why do you want to do a manual capture ? capture_method = manual is when placing a hold on the card, you can't combine the two logics

[dusty thicket]

To assure a few days before the service that the customer is actually able to pay and freeze the according amount

What does confirm = true actually do? Does it immediately capture the payment?

Because according to this here: https://stripe.com/docs/payments/intents the confirmation of a payment intent + its authoization and capture do not seem to be incompatible??

[rich frost]

What does confirm = true actually do? Does it immediately capture the payment?
that means when creating the PaymentIntent, it'll be confirmed directly assuming that that PaymentMethod is already authenticated

[dusty thicket]

but that can still result in an authorization if capture_method is set to manual, correct?

Meaning it is possible to create a payment intent that uses:

confirm = true
off_session = true
setup_future_usage = off_session
capture_method = manual

It will just fail if the payment requires 3D authentication. But to reduce that risk, I'm setting

usage = off_session

When creating the setup intent to store the payment method to be used for that payment

[rich frost]

but that can still result in an authorization if capture_method is set to manual, correct?
No that won't result an authorization

Again you are trying to combine two logics that's not possible

[dusty thicket]

but in an immediate capture?

[rich frost]

You can't combine confirm = true and capture_method = manual.

It will just fail if the payment requires 3D authentication. But to reduce that risk, I'm setting usage = off_session
that won't reduce the risk, the PayamentMethod need to be authenticated before in order to use it off_Session

[dusty thicket]

I'm just a little confused now as that's part of the model your colleague recommended me to implement

[rich frost]

If it fails or need auths, you have some time to contact your customer/student and have them authenticate or provide new payment details
This doesn't mean to create a PaymentIntent off_session, this mean to create an on_session payment.

[dusty thicket]

yes, but only if the previously attempted off-session payment authorization failed

[rich frost]

He didn't suggest you to use off_session to reduce the risk of the 3ds

[dusty thicket]

that's also totally not what I'm saying

[rich frost]

Sorry then I didn't understand this message:
#1031475761770659860 message

[dusty thicket]

Basically, the question is: Can I authorize a payment with the customer being off session, based on the assumption that I've stored the payment method used for that authorization via setup intent that uses "usage => off_session" ?

[rich frost]

Can I authorize a payment with the customer being off session
No, you can't.
Again, you can just simplify the flow and follow just theis guide:
https://stripe.com/docs/payments/save-and-reuse?platform=web#charge-saved-payment-method
Also because the 7 days limit is not accurate,

[dusty thicket]

but it's what your colleague said here

"Then when enough time passes so the lesson is < 7 days away, do the payment then. If it succeeds, great, and you hold until lesson time."

I've also been told that the 7 days limit is accurate in case of credit card payments only. You're now telling me that that's not the case?

[rich frost]

do the payment then
that means capture the funds not doing an off_session payments

[dusty thicket]

He's saying in the second part of the sentence "and you hold until lesson time"

so we're not talking about a capture here

[rich frost]

The capture is available up to 7 days

[dusty thicket]

Can you maybe connect me with one of your colleagues? No offense; I just feel that we're misunderstanding each other

[tacit night]

Hi! I'm taking over this thread.

Can you try to summarize your question, while I catchup with this thread?

[dusty thicket]

Hi, sure

So:

• I have a platform that connects service providers with customers
• Payments should always be authorized at the moment the booking of the service is made, and captured after the service has been provided
• The platform only accepts credit card / Apple Pay / Google Pay payments
• Services may be booked up to 3 weeks before they are provided, and that's the main issue for the following workaround:

1. New customers save payment method for later use according to https://stripe.com/docs/payments/save-and-reuse?platform=web#charge-saved-payment-method

2. As a payment may be authorized on OR off session, and capture is always off session, I specify usage => off_session when creating the setup intent.

3. When the service is booked, I check if the time of the service is max. 6 days in advance.

-> If yes, I authorize the payment via on session (stripe.js).

-> If not, authorization may expire before the service will be provided. Hence, I store a record in my DB which holds that services for which the payment must still be authorized. A cronjob then checks on a regular schedule if there are such payments yet-to-be-authorized. As soon as the 6-day span is reached for these payments, I trigger the authorization of that respective payment with the client being off session.

That's the logic

I've setup a miroboard that illustrates the flowchart:

• Black = actions on my FE
• Blue = actions on my server / BE
• Purple = actions on the side of Stripe
• Yellow = conditions

You may check it too

The question is; is that possible?

Like; the blue "Create Payment Intent" box below the "Payment Authorization" Title represents an on session payment authorization. The blue "Create Payment Intent" box in the bottom left corner represents an off session payment authorization.

And the main question is if that implementation logic according to the FLowchart is possible

[tacit night]

So If I understand your flow:

1. Create a SetupIntent to save a card
2. Later create a PaymentIntent for that card, with capture_method: "manual"
3. And then later capture the funds (less than 7 days after creating the PaymentIntent)
   Technically this is possible, but you have to be aware that at step 2 the bank might require the customer to go though 3DS.

[dusty thicket]

Yes

And now imagine the two scenarios of my flowchart: If step 2 is triggered for an on session payment authorization (hence from the frontend), everything's fine and works, including 3D auth that will be triggered via stripe.js.

If step 2 i.e. the the creation of a new payment intent is triggered from the backend (via cronjob), the concerned customer is offline, hence the payment authorization would need to happen off session. In other words, if 3D authentication would be required here, that will fail; and I'm aware of that, which is why I've setup the workaround with the notification e-mail you see in the flowchart.

The question is; can I create a new payment intent authorization with the client being offline, if that payment won't trigger a 3D authentication?

And doing that authorization via my server-side + stripe API only

[tacit night]

When you create a PaymentIntent, it's completely up to the bank to request 3DS or not. So if the bank request 3DS, you have to ask your users to come back to your website/app to go though the flow, there's no other option.

[dusty thicket]

yup and I'm fine with that. It's also the reason why I'm saving the payment method via the setup intent parameter usage => off_session

According to your non-dev support; that will reduce the risk of requiring a 3D authentication on every subsequent payment authorization. Hence it reduces the risk of that roundtrip. Would you agree on that?

[tacit night]

Agree, but 3DS can still happen.

[dusty thicket]

Okay yes, clear.

But that means that payments can be authorized server-side only, correct?

(only being successful if 3D is not needed, as discussed)

[tacit night]

Yes you can create and confirm PaymentIntent only from the backend, assuming no 3DS will be required.

[dusty thicket]

ok excellent, in this case what I want to verify is

[tacit night]

You can see an example here, were we use a try/catch in case 3DS is required: https://stripe.com/docs/payments/save-and-reuse?platform=web#charge-saved-payment-method

[dusty thicket]

Yes I'd do exactly that on the server-side, just with one difference

[dusty thicket]

As stated here, I'd still like it to be a payment AUTHORIZATION, and NOT capture

[dusty thicket]

meaning that I would need to add capture_method = manual to this payment intent method

Your colleague now told me that this will not work with

confirm = true off_session = true setup_future_usage = off_session

?

[tacit night]

Yes that works, assuming you handle the case that require 3DS.

[dusty thicket]

Yes okay, puuuh my heart started beating for a moment, that would have messed up everything ^^

[tacit night]

But I would recommend you to run some test in test mode. We have some test cards that always request 3DS https://stripe.com/docs/testing#regulatory-cards

[dusty thicket]

stopped beating* hahah

Yes I will definitely do that

[tacit night]

No need to set setup_future_usage = off_session since you already saved the card with a setupintent, correct?

[dusty thicket]

I mean first I thought it's a horrible solution in terms of UX; but previous discussions with stripe devs told me that the case where the workaround with the notification asking the customer to come back online will be rather rare

[dusty thicket]

Well I don't know, I will always be using the same payment method and potentially off session as you see; that's why I also specified setup_future_usage = off_session for the payment intent. You say it would be better to omit that then, if usage = off_session is specified for the setup intent?

[dusty thicket]

If you see a better approach to avoid the extra round trip asking the customer to come back online + be able to authorize payments off session; just let me know 😄

[dusty thicket]

I was a little confused by this, because the docs say that the payment intent's status switches to "succeeded" upon success, if confirm => true is passed when creating the payment intent. But when I authorize the payment without capturing, I expect the status to be "requires_capture" and not "succeeded".

That's why I wondered if it is actually even possible to combine confirm => true with capture_method = manual, to authorize a payment with a saved payment method while the customer is offline.

[tacit night]

That's why I wondered if it is actually even possible to combine confirm => true with capture_method = manual, to authorize a payment with a saved payment method while the customer is offline.
Like I said earlier, I strongly recommend you to do some quick tests in test mode with our test cards to see exactly what happens. But I just tested that and it worked.

[dusty thicket]

Cool thanks so much

I really appreciate your support, you make Stripe awesome, your support really stands out compared to your competitors

So thanks a lot!

[tacit night]

Happy to help 🙂

[dusty thicket]

oh and

[dusty thicket]

you didn't answer on that yet; you would omit the setup_future_usage param when creating payment intents ?

[tacit night]

It depends. If you already created a PaymentMethod with a SetupIntent earlier usage: "off_session", then there's no need to set setup_future_usage when creating a PaymentIntent for that PaymentMethod.

[dusty thicket]

okok great then I'll omit it

Or, will it do some extra work / slow things down if I also provide setup_future_usage ?

[frank arch]

well it might give us a hint that we should ask for 3D Secure again. No reason to pass it, as mentioned, so not really a problem.