#ebellotpu6_api

1 messages · Page 1 of 1 (latest)

rare vaporBOT
#

đź‘‹ 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/1497154347539365908

đź“ť Have more to share? Add more details, code, screenshots, videos, etc. below.

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

turbid summit
#

??

#

hello!

crimson condor
#

hey there, thanks for waiting - looking into your question now

#

quite a few things can affect RBI mandate creation, such as issuer support, but just want to confirm your integration flow for India subscriptions

turbid summit
#

We use a two-step flow:

Step 1 (current page /contratacion): We create a SetupIntent to collect the customer's card details, confirm the SetupIntent, and obtain a payment_method_id. We then redirect the customer to sign a contract.

Step 2 (page /confirmacion-pago): After signing, we call our MakePayment endpoint which creates the Stripe Subscription (and a separate PaymentIntent for a one-time deposit). We pass the payment_method_id obtained in Step 1 to the Subscription.

Our reason for using a manual SetupIntent first is that we need the payment_method_id before creating the subscription, because the contract signing happens between the two steps.

Question: Should we skip mandate creation in the SetupIntent entirely, and instead let the Subscription creation (Step 2) handle the RBI mandate automatically? If so, do we need to pass any special parameters when creating the Subscription for Indian cards?

rare vaporBOT
blazing grove
#

đź‘‹ Hi there! I'm taking over for my colleague. Let me take a look

turbid summit
#

??

#

Any news?

blazing grove
#

Do you have an example of a Setup Intent where it's successful, and there is no mandate? The example you shared above (seti_1TPetAJ9rnA1s2dmjAKqxOrX) is incomplete.

#

I tested with the India card, and was able to create a Setup Intent and Payment Method that had a mandate. So it would be good to see an example

turbid summit
#

does it works for you?

blazing grove
#

OK, that looks like a PaymentIntent, which uses a PaymentMethod, which was created via the CardElement, and then you confirmed a SetupIntent with that PaymentMethod — with no India mandate information?

#

I think you should create a SetupIntent, with the payment_method_options[card][mandate_options] that you had in an earlier request you shared. Then use that SetupIntent and confirm the card setup on the frontend — though you may need to upgrade from the legacy CardElement to the PaymentElement, so that you can get the user's authorization

#

Ah no, the legacy CardElement will also support the necessary 3DS flow

turbid summit
#

We want to support recurring payments from Indian cardholders (RBI mandates) alongside our existing European card flow. Currently our system has no mandate support at all — Indian cards can reach the payment step but the transaction fails or doesn't comply with RBI regulations.

Current system (before our pending changes):

We have a two-step checkout flow:

Step 1 — /contratacion (card collection page):

A SetupIntent is created server-side (no payment_method_options.card.mandate_options in the original code).
The frontend initialises Stripe Elements in deferred mode (no clientSecret passed), so no mandate acceptance UI is shown.
The customer enters their card. On submit, stripe.confirmSetup() is called from the frontend with the clientSecret, which confirms the SetupIntent and returns a payment_method_id.
The customer then signs a rental contract via a third-party e-signature service (Signable). This signing step happens between card collection and payment.
Step 2 — /confirmacion-pago (payment page):

#

After the contract is signed, MakePayment is called on our backend.
This creates a one-time PaymentIntent (deposit) and a Subscription (monthly rent), both using the payment_method_id from Step 1.
No mandate or mandate_data is passed to either object.
What we've tried so far (pending changes, not yet deployed):

Added payment_method_options.card.mandate_options (with supported_types: ["india"], amount_type: "maximum", interval: "month") to CreateSetupIntent.
For logged-in users: pre-create the SetupIntent at page load and initialise Elements with the clientSecret so Stripe can show mandate acceptance UI.
Replaced the frontend stripe.confirmSetup() call with stripe.createPaymentMethod({elements}) + a new backend endpoint ConfirmCardSetupIntent that calls SetupIntentService.Confirm() with mandate_data.customer_acceptance.type = "offline".
Pass the returned mandateId to the PaymentIntent (deposit) via createOptions.Mandate.
Block Indian cards without a mandate at the MakePayment step (error 1020).
Current result: The SetupIntent confirms successfully and returns a payment_method_id, but mandate is null even when testing with card 4000003560000123.

Question: Given our two-step flow (card collection → contract signing → payment), should we skip manual mandate creation via SetupIntent entirely, and instead create the mandate as part of the Subscription creation in Step 2? If so, what parameters does the Subscription need for Indian cards, and how do we handle the case where the card is Indian without knowing it until MakePayment?

blazing grove
#

Why are you creating the SetupIntent, but then not passing the client secret to the frontend?

turbid summit
#

Originally, the SetupIntent was created lazily — only after the customer filled in their personal data form and submitted it. Since the Elements had to be rendered before that, they were initialised in deferred mode without a clientSecret.

As part of the changes we're working on now, we've started pre-creating the SetupIntent at page load (for logged-in users) and passing the clientSecret to stripe.elements({ clientSecret }). This way Elements knows the SetupIntent context.

However, for new users (not yet registered), we still can't pre-create the SetupIntent at page load because the Stripe Customer doesn't exist yet — it's created when the user submits the form. In that case, the Elements are still initialised in deferred mode, and the clientSecret is only available after createCustomer returns.

Is the correct approach to reinitialise Elements with the clientSecret after createCustomer returns (before showing the card validation step)? And is that what's needed for the mandate acceptance UI to appear for Indian cardholders?

blazing grove
#

I just tested the overall flow, and it looked fine to me. Let me double-check your point about the deferred SetupIntent. But it sounds reasonable

#

To give the flow I tested just now:

  1. Create Elements in setup mode, without an intent
  2. Create Customer
  3. Create SetupIntent with Customer and payment_method_options[card][mandate_options]
  4. The customer enters the test card number, and the frontend calls confirmSetup with the client secret
  5. 3DS validation is shown to the customer

The SetupIntent is successful, and has a payment_method and mandate.
I then create a subscription using the customer and default_payment_method — the India mandate seems to be created as the docs mention.

turbid summit
#

seams it worked

#

tanks

blazing grove
#

You got it to work as expected?

turbid summit
#

yes

#

are there any other countries that have this problem?