#cnguyen-payments

1 messages · Page 1 of 1 (latest)

knotty aurora
worn moth
#

To give more details, ideally, on the front part, I would like to make an authorize on the first payment with 3DS. If the 3DS is validated and the authorize too, I would like to launch an other authorize. And if it's OK, I want to capture them.

knotty aurora
#

Sure, you can do that . I'd start by building the flow in https://stripe.com/docs/payments/save-during-payment to get started.

But do you really mean you want to charge the customer, then charge them again a few seconds later? That's generally not a great idea(it can lead to doing 3D Secure twice in a row, or the bank declining the transactions as they look like duplicates/mistakes/fraud).

#

depending on the use case it's usually better to do one big upfront payment rather than multiple smaller ones at the same time.

worn moth
#

yes ofc but it's because I can't do one big upfront.

#

And I want to authorize the both before. Not charge (if it mean "capture")

#

I think that if I authorize on the first one transaction with 3DS (create the customer and payment method). And if I make a 2nd authorize with the same customer and payment method, the probability to have another 3DS is very very weak no?

#

And ideally, you give me the flow to make an off-session for the 2nd transaction. But I would like to make it on-session to avoid to use the off-session right now.

knotty aurora
knotty aurora
worn moth
#

Because one payment is for the merchant (throught the connect account) and the other one is for us (the platform)

knotty aurora
worn moth
#

And for you, it means that on-session or off-session transaction is the same probability to work?

knotty aurora
worn moth
#

I see. That's why I want to do an on-session for the both.

#

But the problem is that I want to authorize and capture the first transaction. But the 2nde one, I want to authorize and capture later

#

Is it possible to make a big upfront with two different rules?

knotty aurora
#

no, it's not. But there are maybe other options, like do the payment(and capture it) without creating a transfer, and then make a transfer later at the time that you would have captured the second payment(https://stripe.com/docs/connect/charges-transfers) to have the same effect

#

I'd really try to take a step back and re-model the requirements here to avoid duplicate-charging the customer. If you look at businesses that do multi-merchant-baskets or whatever the setup is that you're trying to do here, usually the platform/main business charges the end-customer and splits the funds(which we support via Destination Charges and Separate Charges and Transfers) so I'd really try to model your business that way.

worn moth
#

If I do this, I want capture 7 days later or cancel it. Possible?

knotty aurora
#

well in what I suggested you're not using auth-and-capture, you're just transferring money internally between your platform and connected account

#

like whatever criteria you had for capturing(like capture after the connected account provides the service or whatever it is you do(I have no context here so I have to guess)), instead of capturing an authorised charge, make a transfer of funds at that time instead.

#

any model where you charge the customer twice in succession is not a great one, it incurs risks of declines, or chargebacks when the customer sees two payments in their bank account and doesn't recognise them , plus the 3D Secure angle.

#

so I can't emphasise enough that I think you should take a step back and redesign.

worn moth
#

To give you the context, the shopper buys a merchant product (first transaction). Then, he can buy a "product platform" (one of our product).

The purchase is validated only if he has enough money to pay the both (that's why I want to check the validation of the both authorize).

And if he has enough money, one payment need to go directly to the merchant (auth and capture). And the 2nd payment, it's for us, but we want to capture hos money only 7 days later.

knotty aurora
#

I see no reason you can't just model that as a destination charge personally, so you could experiment with that. The only limitation is this "wanting to capture the money 7 days later". Why is that important to you?

worn moth
knotty aurora
#

yes

worn moth
#

And the only problem with that, it's because I want to capture 7 days later? If I remove it, it works

knotty aurora
#

I would think so

jagged spade
#

hey there, just catch up here

worn moth
#

The problem is that I have to keep the 7 days later because the shopper can "cancel" it during 7 days. That's why we need to auth and capture later.

#

Hi @jagged spade

#

And we don't want to make a big upfront payment because we don't want to display the total amount for the 3DS and the other part (for us) is a "pre-order". So it's not a real purchase. We don't want to stop the shopper on his first transaction.

jagged spade
#

it's still a real payment, even if its captured later. you need to decide on what you want as a business and customer experience, because you're asking for two different things.

worn moth
#

We already choose the best solution for us. And I have to validate with you if it's possible. But the solution that we choose is :

  • Transaction 1 => Authorize with 3DS
    • If OK, authorize Transaction 2
      • If NOK, we cancel transaction 1 and 2
      • If OK, capture transaction 1 and we will capture the transaction 2, 7 days later.
jagged spade
#

Yes, that's possible but as @knotty aurora mentioned your customer may encounter 3DS twice and not have a great experience with that approach. It sounds like you'd cancel tx1 if tx2 failed which to me means it's really one transaction. You should probably do a single payment and collect either now or later and split the funds as described in the destination charges flow.

worn moth
#

I tried to purpose that ofc but the business doesn't want it ^^ Even if I said that it will be possible to have 2 3DS. They said that it's an edge case.

jagged spade
#

That's your decision. As we said it will work, but it's not optimal.

worn moth
#

Yes. So for that, just to be sure, what is the good things (the good link) to do?

jagged spade
#

what do you mean?

worn moth
#

If I split it in 2 transactions. I have 2 choices:

  • Make the both one after one on the front. I will force the first one to have 3DS. And I will do the 2nd one automatically (because I have already the information from the 1rst transaction) but in front (with the possibility to have a 2nde 3DS
jagged spade
#

is that one option or both of them?

worn moth
#

It's like an upsell. It's 2 purchases one by one.

#
  • I can do the 1rst transaction with 3DS, and flag to off-session. And make the 2nde (auth and capture 7 days later) one with the off-session flagged
#

But we want to avoid the 2nde option because we don't want to manage all the problems around the off-session.

jagged spade
#

if the customer is actually on session (ie if you do it right after the first one) off-session is also inappropriate to use

#

But this is really up to you to decide -- you should test the potential flows in test mode and figure out how you want to proceed

worn moth
#

thank you

jagged spade
#

you're welcome 🙂