#supreeth_code

1 messages ¡ Page 1 of 1 (latest)

river grailBOT
#

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

📝 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.

mossy parcel
#

I don't understand the question exactly

#

You said you got a suggestion to save during payment

#

What's the issue with that?

gritty gazelle
#

we have 2 flows by which a user can add payment methods

#

1 is by using our UI - where we create a stripe customer initially and our UI will load the payment intent secret to accept the payment method - only if the 2$ hold succeeds

#

2 - by using No code Customer portal where user can add/delete payment methods - which doesnt do any hold on the card. How do we accept the card using No code Customer portal only 2$ hold on customer card goes through

mossy parcel
#

How do we accept the card using No code Customer portal only 2$ hold on customer card goes through
You can't

#

The customer portal is no code and has limited functionality

gritty gazelle
#

I was thinking of a way where we piggyback on the webhook call payment_method.attached - create payment intent there with 2$ hold, if the payment intent fails - detach the payment method ?

mossy parcel
#

You could do that

#

One thing to note though is the customer portal uses a setupintent I believe

#

SetupIntents sometimes do a $0 or $1 auth on the card (where you'll be charged auth fees)

#

So you could do what you're saying but you'll be racking up double auth fees

gritty gazelle
#

auth fees are charged to customers ?

#

I havent seen any auth done for setup intent so far and thats why its been a leaky bucket for us

#

and thats the reason we had to resort to these 2$ holds on the cards

mossy parcel
#

I'm double checking to make sure if customer portal does setupintent

#

Not 100% sure it does

gritty gazelle
#

too many fraud users coming in with fraud cards and the transactions dont go through

mossy parcel
#

But with setupintents it's an internal optimization whether or not we do the auth

#

It's not every setupintent

gritty gazelle
#

though the cards always gets accepted by setup intents

mossy parcel
#

What you're doing is the only way to make sure an auth is performed

#

With SetupIntents it's optimized on stripe's end before we talk to the issuer

gritty gazelle
#

ok

#

what I am suggesting is valid option right ?

#

Any concerns with that ?

mossy parcel
#

Yes you can do it

#

From a technical perspective

#

From a compliance perspective I can't comment

gritty gazelle
#

Other then it might be slighly confusing for end-users that their payment method disappeared because hold failed

mossy parcel
#

Yes it might be confusing to them

#

And they might not realize you're going to auth their card

#

The customer portal doesn't have language around that

#

And again i can't speak to the legal/compliance portion

#

But from a technical perspective it's doable

gritty gazelle
#

yeah we will document the auth/hold process

mossy parcel
#

The other thing you need to make sure to take into account is the customer's default payment selection

#

There's a checkbox in the customer portal that lets the customer select if they want the newly added payment method to be the default

#

If you detach it if the auth fails then they will no longer have a default one set

gritty gazelle
#

Also is there a way for me to avoid double auth, where users going with option 1 already would have their hold done.

#

Is there a metadata I can attach to payment intent - so I check that in payment_method.attached and not create one more payment intent on that

#

If you detach it if the auth fails then they will no longer have a default one set - thats ok, our system is smart enough to not give them our services if they dont have any payment methods

mossy parcel
#

Can they have more than 1 payment method? I just bring this up because you may want to fallback and reset their previous payment method as the default if adding the new one fails auth

#

That way you can avoid failed payments

mossy parcel
#

You can set metadata on the payment intent to indicate it was done through the elements flow

gritty gazelle
#

and we can see this metadata in the webhook call payment_method.attached ?

mossy parcel
#

yes if you set it within payment_method_data it'll be set on the payment method object

gritty gazelle
#

ah awesome

#

yeah they can have more than 1 payment method

#

and they can set what do they want as default

#

but all we want to make sure is whatever card they add to stripe - we want that to be vetted with 2$ hold

#

what happens if we delete a payment method and that was set as default ? stripe doesnt set the previous one as default back ?

mossy parcel
#

We do not

#

That was my point

#

You'd need to have logic to preserve the previous default

gritty gazelle
#

ok got it

#

I will keep that in mind!

#

thanks

mossy parcel
#

No problem

#

Like say for example the customer has 1 card already and it's set as default. Say they go into the no code customer portal, add a new card, and select the box to set the new one as the default. Then, say you create a 2 dollar auth on the new card and it fails and you detach the new card. The old card is no longer the default. The customer will have no default set.

gritty gazelle
#

yeah got it

#

and I had a follow up to this

#

this will work fine for redirect-based cards as well right ?

mossy parcel
#

Like a card that requires 3ds auth?

gritty gazelle
#

yes

mossy parcel
#

So that's the issue with confirming a payment intent serverside

#

If the intent requires 3ds auth, you need a way to bring the customer online and have them complete the auth

river grailBOT
mossy parcel
#

There's no way around that

#

Banks decide when a card needs auth

gritty gazelle
#

how does off_session payments work ?

#

if we want to charge the customer by raising invoices later

mossy parcel
#

In theory you properly set up the payment method for future use

#

Either via a setupintent or via a payment intent with the setup_future_usage param

#

That should allow you to charge them off session with minimal 3ds issues

#

3ds is still possible but unlikely

gritty gazelle
#

ok

#

doesnt customer portal payment method do that with setup_future_usage param ?

mossy parcel
#

Customer portal uses a setupintent

#

So in theory you should have minimal issues with the server-side payment intent confirmation off-session

#

But it's still possible

gritty gazelle
#

so most likely it should work - for off_session payments ?

mossy parcel
#

Most likely, yes

gritty gazelle
#

In case it fails, we just wont accept the payment method - which I think is ok

#

because we need the off_session payments to go through for all our invoices anyways right ?

mossy parcel
#

You would

#

But if it's due to 3ds, you can just bring the customer to the hosted invoice link to complete auth

gritty gazelle
#

ok cool, in that case this payment intent can be a good thing only

mossy parcel
#

Up to you. If it's only requiring 3ds, you can bring them online to complete it

gritty gazelle
#

how do we bring them online for server side payment intent ?

mossy parcel
#

To a page on your site where you call confirmPayment client-side and use stripe.js to complete auth with the payment method id

gritty gazelle
#

by passing the secret ?

mossy parcel
#

yes

gritty gazelle
#

Is there a way to know how many payment methods of our current customers requires 3ds auth like this ?

mossy parcel
#

So you should be able to filter those events

#

Assuming you didn't pass off_session=true

gritty gazelle
#

oh events is the only way ? nothing will be set in payment method attribute ?

mossy parcel
#

If you passed off_session=true, then we just generate payment_intent.payment_failed

mossy parcel
#

There's not a real easy way to check this

gritty gazelle
#

off_session=true while creating payment intent ?

gritty gazelle
mossy parcel
#

Because that indicates to us that the customer isn't in the flow to complete auth

#

So we just decline

#

If customer is in the flow, instead we transition payment intent to requires_action

gritty gazelle
#

is it also same if we set off_session=true while creating invoice ?

mossy parcel
#

And expect customer to complete the auth

#

Where do you see that param on an invoice?

#

And is this a subscription invoice or one-off?

gritty gazelle
#

This is one-off invoices

#

I dont think we set anything, how does 3ds work for invoices ?

#

I am not even sure how its working now

mossy parcel
#

So default is off_session=true

#

Assuming you call the pay endpoint

#

But I don't know how your integration works

#

There's multiple ways to integrate this

#

Invoices are easier though

#

You just bring the customer to the hosted invoice page to complete the auth if it's an off-session 3ds failure

gritty gazelle
# 
        // Insufficient balance on the payment method will fail the payment.
        Forgive: stripe.Bool(false),
    })```
#

we do this

#

and this happens in backend

mossy parcel
#

Yeah so that would be off_session=true by default

gritty gazelle
#

completely detached from UI

#

ok in that case, backend off_session payment intent would basically validate this right ?

mossy parcel
#

Validate what?

#

3ds can happen at any time up to the discretion of the bank

gritty gazelle
#

sorry Validate that off_session payments will work

mossy parcel
#

Payment Intent may not require it but a later invoice might

gritty gazelle
#

without redirects

mossy parcel
#

Completely unpredictable

gritty gazelle
#

oh

mossy parcel
#

This isn't something you can predict. Your integration needs to be able to handle it if it happens

gritty gazelle
#

ah ok

#

If its a invoice, then if we disable off_session - do we still need our own UI integration the payment to work ?

mossy parcel
#

No

gritty gazelle
#

ok

#

thank you

#

Do you know if there are test cards to test 3dsecure cases and our integrations ?

odd scarab