#mesudev -auth & capture

1 messages · Page 1 of 1 (latest)

bronze storm
#

Hello! Just starting a thread for you -- I'll review and respond as soon as I can 🙂

#

Hey there, what do you need help with about this?

wind path
#

Hi there, cheers!

#

So my business is an online platform that connects teachers with students and vice-versa.

I've integrated your system to enable payments through my platform via authorize and capture. The logic is that a student:

A) stores a payment method
B) when booking a lesson with a teachers, authorizes a payment
C) authorized payments are captured as soon as a lesson has been carried out

The only drawback in this system is: Due to the authorization max time of 7 days, students can only book their lessons 6 days in advance.

My solution for this, after going through your API docs multiple times, and talking with your support etc. multiple times, is the following. I would like to know how far you think my solution makes sense / if you see any problem with it, or a better approach.

#

My solution:

  1. Store payment method upon account creation for later usage. Here, we set the usage parameter of the API call used to store the payment method (https://stripe.com/docs/api/setup_intents/createhttps://stripe.com/docs/api/setup_intents/create ) to off_session (https://stripe.com/docs/api/setup_intents/create#create_setup_intent-usagehttps://stripe.com/docs/api/setup_intents/create#create_setup_intent-usage ), according to https://stripe.com/docs/payments/setup-intents#durch-spezifizierung-der-nutzung-die-erfolgsquote-steigernhttps://stripe.com/docs/payments/setup-intents#durch-spezifizierung-der-nutzung-die-erfolgsquote-steigern

  2. When creating a payment intent via your API (https://stripe.com/docs/api/payment_intents/createhttps://stripe.com/docs/api/payment_intents/create ), we would then set the setup_future_usage parameter to „off_session“, to make step 3), proposed by one of your developers, as smooth as possible

#
  1. We could implement a cronjob schedule on our server-side, which checks the days expired since a payment has been initially authorized (which occurs at step 2), and at that moment, the customer is ALWAYS online, and able to authenticate via 3D - secure). As the maximum amount of days of authorization is limited to 7, that cronjob could check every 12 hours if any payment lies back more than 6 days.
    For every authorized payment X where that’s the case, the solution your developer proposed comes in: we trigger the following server-side code (hence not using any 3D-secure authorization features, as the client is offline at this stage):

a) we create a new payment intent authorization (https://stripe.com/docs/api/payment_intents/create#create_payment_intent-setup_future_usagehttps://stripe.com/docs/api/payment_intents/create#create_payment_intent-setup_future_usage) with the same payment method, but this time by setting the off_session (https://stripe.com/docs/api/payment_intents/create#create_payment_intent-off_sessionhttps://stripe.com/docs/api/payment_intents/create#create_payment_intent-off_session ) as well as the confirm (https://stripe.com/docs/api/payment_intents/create#create_payment_intent-confirmhttps://stripe.com/docs/api/payment_intents/create#create_payment_intent-confirm ) parameters to true, as this occurs on the server-side only, and 3D-secure authentication will be impossible.

b) if the authorization succeeds, we release the previous authorization related to payment X, and associate the new authorization orginiating from a) to the related service of our platform. When the service is then completed, the payment authorized in a) will be captured.

c) if b) does not succeed, we will internally decide if we captured the payment of the thus yet-not cancelled authorization, or cancel it. Except you have a better proposition here.

#

Thanks already in advance for your help!

bronze storm
#

What you're describing is chained holds, ie try to get a new hold before the previous one expires

#

you can do this, but i want to share an alternative

wind path
#

yes plz, and btw I'm using stripe connect express accounts with destination charges

bronze storm
#

If the appointment is < 7 days away, take the payment and hold to capture at the lesson time

#

If the lesson is > 7 days away, do the setup intent but take no payment (unless you want to take a deposit, eg, captured right away).

#

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.

#

If it fails or needs auth, you have some time to contact your customer/student and have them authenticate or provide new payment details before the lesson.

#

But this is a business decision for you to make

wind path
wind path
bronze storm
#

Yes - you do the payment off session initially. If auth is needed to email them to come online later and you try the payment again with them online.

wind path
bronze storm
#
  1. They can fail the same way anyways, you'd need the customer online to authenticate
  2. You can cause multiple charges on the customer account that are not released promptly by the bank, this might lead to insufficient funds if their limit is reached or confused customers disputing duplicate charges
wind path
#

which is actually the reason why I'd prefer chained holds for the moment

bronze storm
wind path
#

which is your preferred solution

bronze storm
#

Pretty much -- that's how i'd do it, it's also simpler/less work that juggling those holds, in my view

wind path
#

so you can create a setup intent for a payment for which you use a payment method that you've stored with an initial setup intent??

bronze storm
#

This guide is the "future payment" path

#
  1. Create setup intent and complete auth
  2. Later, create payment intent and confirm (commonly off-session)
  3. Handle recovery if the payment intent is declined
wind path
bronze storm
#

(when confirming off session, the charge will be declined if the bank wants the customer to authenticate again)

wind path
bronze storm
#

OK then i think the change might just be doing the payment with auth & capture a few days before the lesson instead of waiting until after, if that's what you do currently

wind path
#

That's why I hoped that when specifying off_session when storing the payment method with the setup intent, I could authorize the payment without the client coming online

bronze storm
#

Hopefully, yes, that's the idea. You authenticate with the setup intent to allow the off session payment.

#

But banks will still sometimes ask for authentication again

#

That's entirely at their discretion, for any payment

wind path
bronze storm
#

Ideally this is not frequent if you'd already had them authenticate, but there is no guarantee

#

This is a very common flow for future bookings, yes

wind path
bronze storm
#

or eg for pre-ordered items when delivery is happening soon

#

For recovery, if it happens, yes

#

Understand, that is not the default/expected flow. The expected flow is for the payment to complete off session without customer interaction.

#

But you must be prepared to handle the extra authentication if the bank asks for it.

wind path
#

Yup got it

#

And you're saying that sending an e-mail to the client to ask him to authorize the payment few days before the service is a common thing then?

#

Sorry, just sounds very uncommon to me

bronze storm
#

or afterwords, it depends on the service, fulfillment cost/risk, customer relationship etc

#

take for example a streaming music service

#

when my renewal comes up normally its fine

#

sometimes my bank declines

#

they don't cut off my service, i can still use it

#

but they email me or show an app notification saying "hey we had a problem with your payment, we need a new card" etc

#

I bet you've had an email like that from somewhere before

wind path
#

yes, but rather rarely

bronze storm
#

similar to "hey you card is expired, you need to set up a new one before your renewal or we'll cut you off"

#

yes, ideally rarely 🙂

#

but it happens

wind path
#

I'm just worried that you know let's say your bank declined the off_session authorization once, you get the e-mail about the issue, must go online and confirm. I mean that's okay

bronze storm
#

Like i said, it's up to you to pick your customer UX

wind path
#

But I'm thinking, could a bank theoretically decline every authorization? In that case, the customer would get the email notification every single time? Then that's weird

bronze storm
#

weight that against potential confusion about duplicate charges (the second hold would certainly appear before the previous one was released, its not instant)

wind path
bronze storm
wind path
#

with real CC

wind path
bronze storm
#

That's a bit of a black box, and every bank makes their own decision

wind path
#

hmm alrigt

#

alright*

#

so from what I understand, you strongly advise against chaining holds

#

due to the double-auth issue

bronze storm
#

For use cases like you describe, I think its not the ideal choice, but its up to you

wind path
#

alright. Does stripe have some kind of API to generate "payment authorization" URLs? Or would I explicitely need the customer to come online, click on a button, get the data from my internal DB, call your API to trigger the authorization, then send the payment intent secret to the FE for authentication?

bronze storm
#

Like i said you could also charge a deposit for the lesson booking up front (20%? 50%), and have the balance only be off session+recovery. But then you're got two payments, two fees, etc. It's all about your preferred model and customer flow.

wind path
#

What I mean concretey is: If I could send e notification email to the customer saying "authorize your payment now", and that email would hold a link directly triggering the authentication for the payment, that would be ideal

bronze storm
wind path
#

yup sth like that sounds great, such that customers do not have to explicitly login to the platform first every single time, just to confirm a payment

bronze storm
#

Yep, exactly -- you can test out the flow in test mode to see how it suits your needs. But this link can be emailed, texted, etc -- however you interact with customers.

wind path
#

hmm but it sounds really complicated, I need to do multiple API calls (create price object, etc.)

#

Guess its easier to create a custom payment link internally with attached GET authentication tokens

#

Don't you think?

#

create a product object, then create a price object, then create a payment link, etc. sounds like overkill to me to just generate a payment link

#

Guess I'll do it internally

bronze storm
#

You can also have your own secure page with a secret link that can be used for payment without login, but you'd have to build that too

#

its just choices to make about flow/work

wind path
#

okay thank you so much!

bronze storm
#

Quite welcome, fun working through these challenges 🙂

#

Good luck with it 👍

tepid rapids
#

@wind path - in a similar situation (i.e. deferred payment) in the case of a payment failure, I send an email including a link to a page on my website for the user to resolve the card issue...

wind path