#obo-test-3ds

1 messages ยท Page 1 of 1 (latest)

midnight ember
austere shell
#

@midnight ember how do I test the user authorization piece of this though?

midnight ember
#

not sure what you would mean by that

austere shell
#

From reading through the RBI mandate documentation, it appears that the bank reaches out to users to "authorize" transactions before they can be made

midnight ember
#

okay sorry you never mentioned RBI in your original message

#

Are you specifically working with customers based out of India?

austere shell
#

about 10-15% of our customers are indian based

midnight ember
#

Okay so are you specifically asking about just that one flow, or are you asking about all of 3DS, or both

austere shell
#

both I guess

#

sorry this is all kind of confusing for me

midnight ember
#

All good, but I guess it's important to start with what you are really asking

#

if you're not the developers it might be easier to send your developers to this Discord server directly instead

austere shell
#

unfortunately i am the developer here

midnight ember
#

so what is blocking you with that part of the question?

austere shell
#

I guess we may not need to actually test the authorize part of things?

#

stripe just kind of handles that

#

and the test cards mock that part out?

midnight ember
#

let's ignore India for a sec

#

they are completely different

austere shell
#

gotcha

midnight ember
#

So step 1: have you tried 3D Secure (without thinking about India). Did you test any of this in Test mode?

austere shell
#

I haven't explicitly tested 3DS yet

#

would that be a good first step?

midnight ember
#

yes for sure

#

If you do, you will see how it works in the UI, what Stripe handles, how the confirmation works afterwards, and test your code end to end

austere shell
#

in other words we need to have 3ds support in order to support india

#

so might as well start with 3ds

midnight ember
#

yes

#

and separately, India is a bit different because it requires "asynchronous approval of a payment" which is subtly different/more complex and https://stripe.com/docs/india-recurring-payments also covers this in details with its own test card numbers too

austere shell
#

got it, that's helpful

#

thank you

midnight ember
#

Sure!

austere shell
#

So I'm going through our card add page right now, and I entered in a 3DS card

#

should I be expecting something to happen here?

midnight ember
#

I mean it depends on so many different things

#

What does "I add a card" mean? What exact APIs are you using?

austere shell
#

let me get you that info

#

which gets us a source ID after the user enters in their info

#

and then we pass that in to our API, which then calls the stripe.customers.createSource api endpoint

midnight ember
#

yeah okay so you use an extremely old API that doesn't really work with India-based card

#

Sorry, you're going to have to evolve your entire integration with our newer API that shipped 3/4 years ago

#

Are you doing recurring payments or just one-time payments?

austere shell
#

recurring unfortunately

midnight ember
#

okay and when you do recurring do you accept a payment upfront?

austere shell
#

We don't right now, but we plan to

#

up until this point we've always billed on the 3rd of the month using a billing anchor

midnight ember
#

yeah okay so the better approach would be to rebuild most of your integration on our newer APIs really

austere shell
#

gotcha. And are we able to migrate old payment sources onto your new API?

midnight ember
#

you don't need to migrate old payment sources they will keep working

austere shell
#

We're in the midst of building new subscriptions with your "price" product paradigm

#

I see

#

can you elaborate a bit what you mean by rebuild our integration?

#

what specific parts do we need to be moving over here?

midnight ember
#

SetupIntents or PaymentIntents to collect card details client-side mostly

#

In theory the newer integration is
1/ Create a Customer
2/ Create a Subscription to the right Price with payment_behavior: 'default_incomplete'
3/ Get the Subscription's underlying PaymentIntent for the latest invoice (if upfront payment) or SetupIntent (if no payment upfront)
4/ Get that confirmed client-side as you collect card details to get all the information set up properly for future payments, including RBI regulations

austere shell
#

Got it

#

thanks for the info

#

Does stripe offer any dedicated webpages for purely handling the billing info?

#

that we can basically farm out to stripe to make it easier for us?

midnight ember
#

yes and no

austere shell
#

this is looking to be quite an upheaval, so ideally if there's anything that we can just "plug and play" and then users can add / remove cards for their account

midnight ember
#

But the problem is that you use billing_cycle_anchor which we don't support (on Checkout)

austere shell
#

hmm

#

good to know

#

and there's nothing like that for purely entering in card info onto an account?

midnight ember
#

there is, still. Checkout does all of that

#

it's just not what you want for RBI

#

Are you charging a prorated amount for now until the 3rd? or does the payment really start on the 3rd of next month?

austere shell
#

it's prorated

#

this is all current stuff though

#

we're moving to a system where we basically sign up for subscriptions on the day they sign up

#

with the exception of the 29th, 30th, and 31st (those get anchored to the 28th of the month)

#

the new system is what I'm really curious about here

#

because in a few months we'll have ideally switched everybody over

small ravine
#

hey there, stepping in since koopajah has to head off, gimme a couple of minutes to get caught up on what was discussed previously

austere shell
#

no worries, thanks for your help so far @midnight ember

small ravine
#

to clarify, are you still planning to make use of Checkout? I wouldn't neccessarily worry overly much about using Checkout for subscriptions with India issued cards. If you use Billing (a.k.a Subscriptions) Stripe will automatically create the e-mandate for India issued cards if one doesn't already exist

austere shell
#

So I'm not really sure at this point what we want to use

#

let me clarify our use case a bit

#

Our current system:

  • SAAS product where people are charged a $20 subscription every month and then $0.15 per unit used on top of that. All billing is currently anchored to the 3rd of the month.

New system:

  • SAAS product where people will sign up for a $20, $50, or $100 subscription which will start on the date they're subscribing. (The exception here will be for items on the 29th, 30th, and 31st, which we will anchor to the 28th of the month for various reasons unique to our system and how it keeps metrics).
#

Our issue is that about 10-15% of our customers are indian based and can currently not pay for our product, even though they want to

#

and we're open to using whatever system allows us to do that

small ravine
#

can you elaborate more on "can currently not pay for our product even though they want to"?

austere shell
#

indian users can not sign up for recurring subscriptions on us right now

#

their payments wont go through

small ravine
#

because of the RBI regulation

austere shell
#

exactly

small ravine
#

ah okay, so Stripe will allow you to accept India issued cards for recurring payments

#

If you use Stripe Billing i.e. Subscriptions, then our product will automatically create an e-mandate for the PaymentMethod that is using India issued cards

#

If you choose to create your own recurring payments using our PaymentIntents API (and not use our Billing i.e. Subscription product), you can also accept India issued cards. You would need to create the e-mandate using the appropriate parameters with our API

#

tldr : yes, Stripe does support recurring payments with India issued cards.

austere shell
#

Can you clarify what you mean by Stripe Billing

#

just so we're on the same page

small ravine
#

if i were to simplify it - using Subscriptions on Stripe

austere shell
#

this may seem like a dumb question, but is there a way to tell if we're doing tha tnow

small ravine
austere shell
#

do you mind if I private message you any account details

#

if the account detail isn't that private, I can send it here as well

small ravine
#

the account id isn't private, you can send it here

austere shell
#

acct_1DARuzEUqHBlqQXG is the account id

small ravine
#

yes you're using Stripe Billing cause i see you're using Subscriptions. I see the problem here, like what koopajah mentioned before, right now you're creating and using Tokens which doesn't support the creation of an India e-mandate. You need to upgrade your integration to use PaymentMethods

austere shell
#

So I've spent the past hour or so reading through the docs there

#

is there a way to set up a paymentMethod without knowing the amount that will be charged?

#

so basically the user adds in a CC, but then they may want to pay us $20, $50, or $100 depending on the plan they choose later

#

and they may want to upgrade at a later point

small ravine
#

onesec, let me find a doc for you

#

sorry just give a while more to get back to you. Need to handle something else for now

austere shell
#

no worries. I appreciate your time so far

small ravine
#

yes, there is a way to set up a paymentMethod without knowing the amount that will be charged, but wouldn't it be easier for the user to add a CC only when they choose the plan? or are you offering a trial to your customers?

austere shell
#

We're running a SAAS platform where uptime is important, so we currently offer users the ability to have a backup card on file

#

in case one of their cards fails

#

(Sorry for all the curveballs, it's frustrating for me too)

small ravine
#

no worries, and we're here to help. The more details i know the better i can help too.

#

so you can add a card without an amount to the customer by using SetupIntents

austere shell
#

brief question here for that

#

will setupIntents work for RBI?

small ravine
#

yes, SetupIntents will work for creating e-mandates. But the way this works is a bit complex

#

so if the default card fails payment for a subscription

#

you can attempt to charge the backup card, but you're going to need to be prepared to have your customer come back on session to authenticate the first payment

#

even if you create an e-mandate on a SetupIntent separately for the backup card beforehand

#

the Subscription object won't read the e-mandate from that separate SetupIntent

austere shell
#

hmm

#

I see one to enable 3d secure

#

but not for the emails

small ravine
#

the emails one is already enabled on your account

austere shell
#

Oh my

#

sorry it's late here

#

I saw that as one section

#

my apologies

small ravine
#

honestly this is all a bit difficult to understand when talking things out. I found it difficult to wrap my head around also until i tried things out.

I think if i were to summarize your topmost important action item, it would be switching to using PaymentMethods

austere shell
#

yup, I've been going through all this and prototyping as I've been talking with you

#

I think I have a pretty good path forward now honestly

#

One final thing I wanted to ask before I head out here.

#

is there anything we should be aware of for pre-existing payment sources that we've added over time?

#

I know some of them no longer work due to RBI (that's expected), but for the ones that do still work, are there any gotchas we should be aware of when switching our API stuff up?

small ravine
#

you can still continue to use them. It's just that for India issued cards, you absolutely have to switch to PaymentMethods for it to work with e-mandates

austere shell
#

for example will we need to query for both sources / payment methods?

small ravine
#

btw, a workaround for India cards is to use send_invoices instead of charge_automatically for subscriptions

austere shell
#

I'll have to let the team know about that

small ravine
#

it's just that you're pretty much dependant on the end customer remembering to pay ๐Ÿ˜… via the sent invoice if you use send_invoice

austere shell
#

yeah I know how that works out lol

#

did you see my question above though

#

will there be an API endpoint we can use to return both sources / PaymentMethods?

small ravine
#

iirc, if you query the PaymentMethods API it should return both Sources and Payment Methods.

austere shell
#

okay cool, that's good to know

small ravine
#

but i'm going to need to test to make sure i remember this correctly

#

if you want to head off to rest first, you can go ahead and i'll reply once i test it against a customer in my own test account that has both a Source and PaymentMethod.

austere shell
#

I'll be on for awhile, that was just my last question ๐Ÿ™‚

#

I appreciate your help!

small ravine
#

alright, i'll let you know once I've tested (I have way too many in my test account).

austere shell
#

you remind me of our QA guy lol. accounts for everything

small ravine
#

occupational hazard ๐Ÿ˜†

#

yep it works

austere shell
#

awesome, that's great to hear