shubh_api

[coarse field]

👋 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/1299393189890756608

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

[thorn gust]

Hi there 👋 are you able to see this doc and have you reviewed it if so?
https://docs.stripe.com/india-recurring-payments

[jolly prairie]

yes but still have confusion, on how should we manage both customer from US and India, as Indian customer will require 3DS verification and in addition going above limit it will have to go one time payment method

[thorn gust]

The gist is that we do it for you. Are you seeing problems when you test? How is your flow structured, do you get any insight on the customer's location before you start creating a Subscription for them?

[jolly prairie]

We are not getting customer location at the time of subscription. In frontend user is not getting 3DS verification screen while using the card issued from Indian Bank. So, not sure how to enable that.

I was also checking this part of doc https://docs.stripe.com/billing/subscriptions/webhooks#additional-action

Is there any code example available to refer?

[thin maple]

Hi 👋

I'm stepping in as my colleague needs to go.

Why would you need to get the customer's location? Stripe and Stripe.js handle the 3DS verification requirements for you.

[jolly prairie]

No, I've not asked that I need customer location. I think the previous question I've been asked for that so I mentioned we are not taking location of the user.

My concern is how to handle the user from US where they don't need 3DS verification let's say and customer from India requires NACH mandate as per RBI guidelines for recurring payment.

[thin maple]

My concern is how to handle the user from US where they don't need 3DS verification

Stripe also handles that automatically for you as well. As long as you are using Stripe.js on your front-end

[jolly prairie]

I think we're already using that

[thin maple]

Then you should not need to worry

[jolly prairie]

Is I am missing something in the backend? Could you plz. share an example code snippet of the payload.

[thin maple]

What errors are you seeing?

[jolly prairie]

no error, and no 3DS verification screen

is there anything else required apart from this?

or do we need this as well?

mandate_data: {

            customer_acceptance: {

                type: 'online' // Indicate online acceptance

            }

        }

[thin maple]

Can you specify which exact section of the docs you are referring to and what exact action you are taking?

[jolly prairie]

https://docs.stripe.com/india-recurring-payments?integration=subscriptions#predebit-notification

[thin maple]

This is the object returned to you by our webhook event. It isn't something you do

[jolly prairie]

I feel, I am answering same question in loop. Is there a better we can solve this issue? Maybe if there is a working example code snippet or demo we can refer to or you can share the exact flow and ref.

[jolly prairie]

oh ok.

can you share the exact workflow that I can follow

[thin maple]

I still don't understand what your actual question is.

You are asking about how to handle 3DS for both India and US customers without knowing the customer's country beforehand, right?

[jolly prairie]

My Question is:
We are based and incorporated in US and having customers from two different regions i.e. US and India.

• US customer doesn't required 3DS verification (an added verification step) for recurring payments.

• But for Indian customer they've to verify the 3DS verification as per the RBI guideline.

So, how should I handle both customers recurring payments using stripe?

[thin maple]

3DS is handled by the issuing bank behind the payment method request it in response to Stripe confirming the payment

Stripe will perform 3DS verification when requested

[jolly prairie]

I mean how to enable NACH e mandate required by RBI for Indian customer recurring payments and use just regular recurring payments for US customer.

In my current implementation, recurring payment is working fine for US based customer but for Indian customer they're not getting 3DS verification screen.

[jolly prairie]

How to enable that request?

[thin maple]

There is nothing to enable

Stripe does it for you

[jolly prairie]

it's not working for us, we have tried with multiple ways still we are not getting 3DS verification screen after adding card.

[thin maple]

Are you adding a card that requires 3DS?

How are you adding these cards?

[jolly prairie]

Yes I am adding a card that requires 3DS (an OTP verification) to enable the NACH e mandate for recurring auto-charge payments.

We have integrated stripe to our backend and are using stripe client in the frontend.

[thin maple]

What Stripe element?

[jolly prairie]

We use Stripe element. First user add their card, in this process user is getting 3DS verification screen as we do authorize for $10 and then we expire that authorization. This process we do to check whether the card is active and works with us.

then at this flow user create a subscription for their account, but at this flow user is not getting 3DS verification screen. we tried many things but it didn't worked.

[thin maple]

How are you saving the card?

Are you using a Setup Intent?

[jolly prairie]

no, we are using paymentIntents

[thin maple]

You are putting a temporary hold on the card and then releasing it?

[jolly prairie]

Yes, to verify the Card. And at this step user is able to verify the 3DS as we create a paymentIntents.

However, at the subscription, 3DS verification screen somehow doesn't come. So, user is unable to subscribe.

[thin maple]

The 3DS that is performed when you first collect the card details is kept and used with the Subscription

If you want to create the 3DS flow when you collect funds for the subscription, don't do the auth step

That is also a bad practice that can get your account flagged by card networks

So you may experience high rates of declines

[jolly prairie]

I didn't understand auth setup, what's that?

[jolly prairie]

could you plz. explain this in details

[thin maple]

3DS is an authentication method

It is performed when you first collect payment for the card

That sets up the card to be used later, so we don't re-request 3DS

As for the bad practice, you will need to write in to Support for more details

https://support.stripe.com/contact

[jolly prairie]

so, we don't need to do that verification again? If that's the case then how should the user will set the limit of recurring payment , let's say.

[thin maple]

We describe the defaults that are created in our doc here: https://docs.stripe.com/india-recurring-payments?integration=subscriptions#subscription-updates

[jolly prairie]

But why user is unable to subscribe even without 3DS verification at the time of subscribing to the plan?

[thin maple]

What code runs and what error is produced when you attempt it?

[jolly prairie]

let me run that again, sharing error in a minute

this is the Payment ID we just created for testing pi_3QDquxJrW4qoE0zy04ZVgsOC

[thin maple]

Okay, taking a look

[jolly prairie]

And here it is saying The customer failed 3D Secure authentication. So, we are thinking we might need to do the 3DS verification and that's why we are looking for 3DS verification screen again.

[thin maple]

Okay so the invoice did go into a state of requires_action

[jolly prairie]

We might be doing something wrong, maybe you can navigate us.

[thin maple]

This means that you need to bring the user back on-session and use Stripe.js to confirm the payment intent

That will trigger the 3DS flow

[jolly prairie]

As you know our flow, my first question here would be, should we use the state of requires_action here or not?

[jolly prairie]

how, from frontend?

[thin maple]

Yes, from front-end

Your UI, where the customer uses their saved payment method, needs to call confirmPayment using the Payment Intent that is in a state of requires_action

this will trigger 3DS

[jolly prairie]

noted, checking this

[jolly prairie]

and how about this?

[thin maple]

That sentence doesn't make any sense to me, sorry

[jolly prairie]

I was referring to your comment. As you mentioned that we don't need to re-request for 3DS verification as it's a bad practice. So, I was asking do we need this in the flow or not. That thing I wanted to confirm first.

[thin maple]

As you can see, your invoices will fail if you don't

Any time a payment intent is in a state of requires_action, then you must re-confirm with the customer present

[jolly prairie]

That I understood. I was asking do we need requires_action for recurring payment? I think we won't be able to auto-charge with this, right? How should we enable auto-charge for the recurring payments?

[thin maple]

I was asking do we need require_action for recurring payment?
That statement still makes no sense. It isn't something you implement, it's a state the payment intent can end up in.

This can occur at any time if the issuing bank decides they want to re-auth the payments. Your integration needs to be able to respond to it whenever it occurs.

[jolly prairie]

noted, do we've to do something for auto-charge the payment method for recurring payments? And in case it requires to be 3DS verification at every invoice then how should we send notification to the customer at early, so that they should not fail to complete the 3DS verification for their upcoming recurring invoice.

[sleek prawn]

👋 stepping in for my teammate

This is mentioned here: https://docs.stripe.com/india-recurring-payments

Auto charging should proceed as normal as long as there's a valid mandate in place. If there is no mandate, a new mandate needs to be created, which requires 3DS authentication. You can turn on a setting in your Stripe Dashboard to have Stripe automatically send customer emails whenever authentication is required

[jolly prairie]

got it, I will try the suggested fix and comeback in case issue still persist.

can you share the link of the dashboard, where I have to anable that

[sleek prawn]

It's in the doc as well: https://dashboard.stripe.com/settings/billing/automatic

Look for the setting "Send a Stripe-hosted link for customers to confirm their payments when required"

[jolly prairie]

Also, I have enabled card only in the payment method, however I am not getting any option to enable just Credit Card as an option in the dashboard. Do we have to handle it through API for this?

[sleek prawn]

enabled card only in the payment method
What do you mean by this exactly?

[jolly prairie]

And what's the best practice to create a subscription product catalog? One product with tiered pricing or Different product with different pricing?

[sleek prawn]

option to enable just Credit Card as an option in the dashboard
Where are you looking?

[jolly prairie]

How should we enable to accept credit card only as a payment method?

[jolly prairie]

https://dashboard.stripe.com/settings/payment_methods
here

[sleek prawn]

If we're talking about Subscriptions, you can do this a couple of ways:

• pass payment_settings.payment_method_types: ['card'] when creating the Subscription: https://docs.stripe.com/api/subscriptions/create#create_subscription-payment_settings-payment_method_types

• If you don't pass payment_settings.payment_method_types when creating the Subscription, we'll default to using the payment methods you've enabled for Invoices specifically. This is configured in a different area of the Dashboard: https://dashboard.stripe.com/settings/billing/invoice

[sleek prawn]

That's really up to you and how you want to model this

[jolly prairie]

I see the enum is only available for card only not the type of card like debit or credit. Is it not available? I wonder how other company like GitHub, Vercel accepts only Credit Card as payment method using Stripe.

I have checked the link, however it redirects to the same page once I click on this link https://dashboard.stripe.com/settings/billing/invoice

[jolly prairie]

Is there any best practice for this? If I am creating a plan like GitHub https://github.com/pricing let's say?

[sleek prawn]

Right, that's fine. You'll likely notice that, when you're redirected, the dropdown menu on the top right now reads "billing payments".

[sleek prawn]

You're right, card includes both debit and credit. If you only wanted to accept credit, you would need to collect payment details and create the PaymentMethod first, then inspect the PaymentMethod to understand whether funding is credit or debit, then decide whether to continue with payment or prompt the customer to provide different payment details. This kind of flow is outlined here, where your logic would happen after step 4: https://docs.stripe.com/payments/build-a-two-step-confirmation

You could model this by creating three Products (one each for "Free", "Team", and "Enterprise), with Prices underneath them (e.g., Team could have a $4/user/month Price and a $75/user/year Price)

[jolly prairie]

Noted, three different products?

[jolly prairie]

So, at the time when we are asking user to add card we should use this payment_method_preview.card.funding and check whether it is credit or not and if it's not credit then we should decline to save? https://docs.stripe.com/api/confirmation_tokens/object#confirmation_token_object-payment_method_preview

In this part of code I should add the payment_method_preview.card.funding ?

Is this how GitHub and other similar companies uses to verify the Credit Card only payment method?

[sleek prawn]

That's one way to do it, yes

[sleek prawn]

I recommend testing this out. You would inspect the confirmation token prior to creating the PaymentIntent

I don't know if this is exactly how Github does it but this is the recommended approach if you need to "inspect" the PaymentMethod details before proceeding

[jolly prairie]

Thank you for answering all my queries, I am trying all the suggested changes. And in case if there is any issue still persist I will comeback here with my queries.

Thanks!