cnguyen-pi-cancel | Stripe Developers | Page 1

covert knot Sep 21, 2021, 3:44 PM

#

what do you mean by void here?

#

you can /cancel a PI

#

https://stripe.com/docs/api/payment_intents/cancel

untold spade Sep 21, 2021, 3:44 PM

#

Yes but it's possible to cancel after a capture ?

covert knot Sep 21, 2021, 3:44 PM

#

in the case like your auth/capture before, this will lead to a refund of the authorized amount

#

not after capture, no

untold spade Sep 21, 2021, 3:45 PM

#

Or what's the name for a cancellation before capture ? and after capture ?

covert knot Sep 21, 2021, 3:45 PM

#

that would be a refund

#

before capture is cancel in the api (but it appears like a refund to the customer)

#

after capture is a refund request in the api

sick rock Sep 21, 2021, 4:09 PM

#

@untold spade any other questions?

untold spade Sep 21, 2021, 4:21 PM

#

Yes. I have few questions. Do I need to open a new thread?

sick rock Sep 21, 2021, 4:22 PM

#

no just ask here!

untold spade Sep 21, 2021, 4:39 PM

#

Thank you 😄 I will try to start from the start.

We have two options according to our business, what's the best? We have to make 2 transactions. We want to be sure that the shopper has enough money for the 2 transactions. They have to be 2 separate transactions.

Option1:

Do an authorize and capture with 3DS on the transaction 1 (T1) (on-session) (and flag the card with the off-session). Then, on the payment.successful of T1, I make the transaction 2 (T2) with an off-session with an authorize (I will capture 7 days later). If T2 is KO, I refund T1 and I cancel T2.

Option2:

Authorize with 3DS for T1 (and flagged off-session). Then an authorize T2 off-session. If T2 is KO, I cancel the both authorize.

sick rock Sep 21, 2021, 4:47 PM

#

Well I would say neither of those really. T2 is not off session the customer is right there. You're trying to optimize against 3DS and you should not
So just do T1 and T2 sequentially, don't capture T1 (just authorize) so that if T2 is declined you just have to reverse it (it's a refund but doesn't come with a fee)

untold spade Sep 21, 2021, 4:52 PM

#

Mmmmmm, I thought that if I force the 3DS and an authorize with T1 (with a customer and payment method), then I will have more chance to avoid the 3DS for T2 if I use the same cus_id/pm_id (not sure I suppose).

sick rock Sep 21, 2021, 4:52 PM

#

sure, you ahve more chance to avoid it

#

but you should not pass off_session: true

#

the customer is still in your app at that point, it's not true that they are not on session

#

that doesn't mean you will have to do 3DS, since you just did it you likely won't have to (unless you always require it) but you might (depends on the bank)

untold spade Sep 21, 2021, 4:54 PM

#

And if I authorize T1 only, and then make just an auth on T2 => if T2 is declined, I just have to remove the auth on T1. For you it's a reverse. Correct?

sick rock Sep 21, 2021, 4:54 PM

#

Correct. It's still a refund in our API, but it releases the authorization which is a better experience

untold spade Sep 21, 2021, 4:54 PM

#

sick rock but you should **not** pass `off_session: true`

For T1 or T2?

sick rock Sep 21, 2021, 4:54 PM

#

For both.

#

When you create T1 you can do setup_future_usage: 'off_session' which allows you to basically set up the card to be used off session later. But T2 should not pass off_session: true (which is a different parameter) since the customer is not off session

untold spade Sep 21, 2021, 4:55 PM

#

Yes but if I need to use it later (off-session), I need to flag it at least on the 2nde one. Even if T2 will be on-session. Right?

#

Ah ok

#

So I need to do the option 2 but ON-SESSION only for T1 and T2.

sick rock Sep 21, 2021, 4:56 PM

#

yeah sorry, the parameter have similar names so it's confusing

untold spade Sep 21, 2021, 4:56 PM

#

Yes I was confused b y off_session!

sick rock Sep 21, 2021, 4:57 PM

#

setup_future_usage allows you to save the card and tell us if the customer will always be back in your app or not to pay

#

usually you want setup_future_usage: 'off_session' so that you can charge them async in a week if needed

#

and then there's off_session: true | false which is "is the customer currently in your app right now or not?" to know whether to do 3DS or ask for an exemption

untold spade Sep 21, 2021, 5:01 PM

#

OK so I will do:

Create customer and attach the payment method
Create the pi_XXX for T1 (force 3DS and do a setup_future_usage: 'off_session') but with an off_session: true and only make au authorize.
Then, if it's OK (what event I have to check to know if the auth T1 is OK?) I create the payment intent for T2 (with off_session: true and with the same cus_id and pm_id)
- If it's OK, I capture the T1 (which event?) and I will capture the T2 X days later
- If it's KO, no need to cancel the auth of T2 because it's KO, but I have to revert T1

#

(thanksss a lllootttttt four your help)

#

@sick rock

sick rock Sep 21, 2021, 5:13 PM

#

(give me a few minutes)

#

sorry, had to step into a meeting

#

the flow is a bit incorrect, you shouldn't attach (or create) a PaymentMethod

#

The flow should be
1/ Create the Customer
2/ Create the PI for T1 and associated customer with it and pass setup_future_usage: 'off_session' (and not off_session: true), and capture_method: 'manual' to do an authorization
3/ Confirm the PI client-side and do 3DS as needed
4/ If #3 succeeds, now you have a PM attached to the customer and you can now create the second PI for T2 (same options except setup_future_usage is not needed there

untold spade Sep 21, 2021, 5:28 PM

#

You don't speak at all about the pm_XXX before #4 ? We need it to make a 3DS on T1

sick rock Sep 21, 2021, 5:28 PM

#

you don't, you likely think this because you're mixing things up

#

the way PaymentIntents work is 1/ Create the PI server-side with all the options. 2/ Client-side confirm the PI with Elements/card details

untold spade Sep 21, 2021, 5:29 PM

#

Ah ok. For me, when I do Element/card details, I thought that we create a PM.

#

OK I see! Thanks a lot. I have 2 questions lefts :p

For this : If my e-commerce website accept payment and upsell post payment. The shopper is on-session. What do you advise for the best acceptation rate? The upsell is done is less than 5 seconds.
=> The answer is the response juste above.

sick rock Sep 21, 2021, 5:32 PM

#

We usually strongly recommend deferring payment until after the upsell, which I know is tricky. But since you can't "increase" the amount authorized for now, you would have to do a separate charge for the upsell otherwise. Basically the flow you describe with T1 and T2 I assume

untold spade Sep 21, 2021, 5:33 PM

#

Perfect. Yes we know that is very tricky. That's why I ask to you the best option.

#

And just to know : If I do a refund (after a capture), one minute after the payment, does the customer see it on his bank statement?

sick rock Sep 21, 2021, 5:34 PM

#

they might, it's really up to the bank

untold spade Sep 21, 2021, 5:36 PM

#

Now, I can officially say to you : TTHHHAANNKKK YYYOUUUUUU

#cnguyen-pi-cancel