lucia-sharpei_best-practices

[brisk quiver]

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1271396774220791830

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

[topaz urchin]

👋 happy to help

this is not the recommended integration path

https://docs.stripe.com/billing/subscriptions/build-subscriptions

please read through this doc

[wooden matrix]

I already have, but my business logic doesnt support this, we need to accept the orders depending on risk, and i cant begin a subscription until the customer has received a product physically. So i need to make a first payment when the order is accepted and start a subscription afterwards.

[topaz urchin]

you can give a free trial until the customer receives the shipment

and for the first payment you can use the add_invoice_items to the subscriptions which are basically a one-off payment added to the first invoice

[wooden matrix]

but the customer will have to pay when they do the checkout

And if its not approved by risk it will have to refund the charge

theres no other way of storing their card

we cant refund charges all the time, and we cant use capture as sometimes the acceptance may take over a week.

[topaz urchin]

https://docs.stripe.com/payments/extended-authorization

[wooden matrix]

okay thanks let me check that

so this would be: 1. create payment intent with the first payment as capture, then extend it if the card allows us to do so.

2. Create the subscription once it arrives

question is, when the subscription makes the first payment is it still going to ask for 3ds authentication?

[topaz urchin]

yes it might

that's why I suggested the approach above

[wooden matrix]

will it not if its a scheduled subscription and we add_invoice_item?

[last prawn]

Any payment is potentially subect to 3DS/auth requests at the banks discretion. Assuming you save/setup the payment method correctly, we optimise to reduce the chances of that but it can still occur

[wooden matrix]

And what should we do if that is the case?

is the bank automatically sending that over to the customer?

or should we send the invoice

through email

[last prawn]

You'd need to bring the customer back on-session to re-confirm/attempt the payment again, or you can configure emails for failing recurring payments: https://docs.stripe.com/billing/revenue-recovery/customer-emails#failed-payment-notifications

[wooden matrix]

thanks ill check this out.

last question, is there a way to not allow 3ds cards to use the service?

[last prawn]

That sounds like an ill informed decision given that the majority of cards now in Europe support 3DS

[wooden matrix]

ok so not possible then

[last prawn]

You can configure Radar to block any payments where the card supports 3DS I think: https://docs.stripe.com/radar/rules/supported-attributes#3d-secure

But as I said, that would not be recommended

[wooden matrix]

so i guess the best flow considering what is the best practice in stripe would be:

1. We create a scheduled subscription that starts in + 1 year

2. We create a add_invoice_item to that subscription once its accepted

3. Once the customer receives the product we change the subscription start date

If anything fails we send an email to the customers to accept the 3ds

Or option 2:

1. Create a payment intent as captured and extend the capture period

2. Once it receives the product create a subscription

if anything fails we will send an email for 3ds

[last prawn]

I'd probably go with 1 as there's no guarantee you can extend the auth (it might not be supported for your MCC, it's an IC+ pricing feature only, not all cards support it)

[wooden matrix]

I guess the difference here is the customer is accepting a transaction of type subscription for the bank therefore less possible it will ask 3ds again. is that correct?

[last prawn]

Not really no

[wooden matrix]

so really option 1 and option 2 would be the same for 3ds (ignoring the capture limitation)

[last prawn]

The chances of 3DS being requested in both scenarios would be roughly the same yes