#obo-test-3ds
1 messages ยท Page 1 of 1 (latest)
Yes you can test all of this in Test mode easily. We have numerous test card numbers including for 3DS https://stripe.com/docs/testing#regulatory-cards
@midnight ember how do I test the user authorization piece of this though?
not sure what you would mean by that
From reading through the RBI mandate documentation, it appears that the bank reaches out to users to "authorize" transactions before they can be made
okay sorry you never mentioned RBI in your original message
Are you specifically working with customers based out of India?
about 10-15% of our customers are indian based
Okay so are you specifically asking about just that one flow, or are you asking about all of 3DS, or both
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
But for testing 3D Secure payments, https://stripe.com/docs/testing#regulatory-cards has all the test cards you want/need
unfortunately i am the developer here
so what is blocking you with that part of the question?
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?
gotcha
So step 1: have you tried 3D Secure (without thinking about India). Did you test any of this in Test mode?
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
in other words we need to have 3ds support in order to support india
so might as well start with 3ds
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
Sure!
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?
(we're not using Stripe Billing, we're using this: https://github.com/stripe/react-stripe-js)
I mean it depends on so many different things
What does "I add a card" mean? What exact APIs are you using?
let me get you that info
I apologize, it looks like we're actually using: https://github.com/stripe-archive/react-stripe-elements#react-stripe-elements
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
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
You likely want to read https://stripe.com/docs/india-recurring-payments and start fresh
Are you doing recurring payments or just one-time payments?
recurring unfortunately
okay and when you do recurring do you accept a payment upfront?
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
yeah okay so the better approach would be to rebuild most of your integration on our newer APIs really
gotcha. And are we able to migrate old payment sources onto your new API?
you don't need to migrate old payment sources they will keep working
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?
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
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?
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
But the problem is that you use billing_cycle_anchor which we don't support (on Checkout)
hmm
good to know
and there's nothing like that for purely entering in card info onto an account?
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?
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
hey there, stepping in since koopajah has to head off, gimme a couple of minutes to get caught up on what was discussed previously
no worries, thanks for your help so far @midnight ember
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
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
can you elaborate more on "can currently not pay for our product even though they want to"?
indian users can not sign up for recurring subscriptions on us right now
their payments wont go through
because of the RBI regulation
exactly
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.
here you go : https://stripe.com/en-sg/billing
if i were to simplify it - using Subscriptions on Stripe
this may seem like a dumb question, but is there a way to tell if we're doing tha tnow
Can you share your account id? You can find your account id by logging in to https://dashboard.stripe.com/settings/account. It'll be in the upper right hand corner and looks like acct_123
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
the account id isn't private, you can send it here
acct_1DARuzEUqHBlqQXG is the account id
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
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
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
no worries. I appreciate your time so far
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?
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)
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
This provides a guide : https://stripe.com/docs/payments/save-and-reuse
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
usually what we suggest is to make sure that you enable should ensure that the below two settings are enabled in https://dashboard.stripe.com/settings/billing/automatic so that Stripe will automatically send an email for the user to authenticate (and hence create the mandate).
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
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?
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
for example will we need to query for both sources / payment methods?
btw, a workaround for India cards is to use send_invoices instead of charge_automatically for subscriptions
I'll have to let the team know about that
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
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?
iirc, if you query the PaymentMethods API it should return both Sources and Payment Methods.
okay cool, that's good to know
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.
I'll be on for awhile, that was just my last question ๐
I appreciate your help!
alright, i'll let you know once I've tested (I have way too many in my test account).
you remind me of our QA guy lol. accounts for everything
awesome, that's great to hear