#devangbhuva97-3ds

1 messages · Page 1 of 1 (latest)

raw blaze
#

@mellow tartan hi! yes you need to complete the payment on the frontend.

#

Want to confirm every transaction from server side.
that's impossible I'm afraid! 3D Secure is a client-side action and you need to handle it on the frontend, you should follow https://stripe.com/docs/billing/subscriptions/elements and use our stripe.js library to collect the card details and complete 3D Secure with confirmCardPayment.

mellow tartan
#

Yes 3D secure is a client side action but is there any way to confirm payment from server side because we need to perform some action action before & after

#

Our flow is little dynamic. Customer can choose recurring or one time products & we are using setupIntent for off session payment

#

For one time products, we are able to figure out. There is confirm payment intent API to confirm payment from server side. So after 3D secure verification, we are calling that when we want to charge

raw blaze
mellow tartan
#

but not able to find similar way for subscription

raw blaze
#

we don't really support that in the Subscription API though.

#

yep we don't support it, that way of integrating is more of an 'escape hatch' for legacy integrations; you should build things according to our docs where the payment actions all happen client side instead and then use webhooks for any server-side actions, sorry!

mellow tartan
#

If customer will choose 2 subscription products, then it's required authentication for both subscription for card 4000002500003155?

#

I'm little bit confused on setupIntent & paymentIntent use case. When actually setupIntent is really required? Can you also help me to more idea on that? So we can use it in proper direction.

#

Right now in every flow, we are creating first setup intent.

#

I read doc - setup intent will be used for off session payments

raw blaze
#

When actually setupIntent is really required
when you accept the card from the customer now, but won't charge it until later(hours/days later)

mellow tartan
#

So if we create subscription, then setup intent is required before that? or it'll manage automatically in next billing cycle?

raw blaze
#

you don't really need a SetupIntent, since confirming the PaymentIntent of the first invoice is all you need to do to save the card.

#

if you're processing a payment now and saving the card, you use a PaymentIntent(it has setup_future_usage field which controls if the card is saved as well; and if you use the Subscriptions API it creates the correct PaymentIntent for you); you only use a SetupIntent if you're saving the card now without charging it and will charge it hours/days later.

mellow tartan
#

Thanks @raw blaze for clear clarification on setup intent. In our case, we are always charging while collecting the card. So not needed setup intent.

#

4000002500003155 - This card requires authentication on all transactions, regardless of how the card is set up

#

What is meaning of regardless of how the card is set up ?

#

How I can setup card, not needed any further verification from customer for next billing cycle or any other payment?

raw blaze
#

" This card requires authentication on all transactions, regardless of how the card is set up" that's not the description of the 3155 card

#

it's the description of a different one

mellow tartan
#

yes.. my bad - 4000002760003184

raw blaze
#

what it means is that even if you use a SetupIntent or a PaymentIntent with setup_future_usage, the card still requires authentication on future off_session payments

#

whereas the 3155 card lets you test the "happy path" where you authenticate it once, when the customer enters their details, and then future off-session payments process without 3DS.

mellow tartan
#

Yuppp that I got it.. what about 4000002760003184?

raw blaze
#

what about it?

mellow tartan
#

And when we talk about future off-session payments what is actual meaning?

raw blaze
#

it means for example the recurring payments of the subscription.

mellow tartan
#

I mean if someone subscribe product using 4000002760003184, in every billing cycle, we need authentication. Right?

raw blaze
#

yes

mellow tartan
#

One thing I noticed, from stripe dashboard, I can charge from existing saved card 4000002760003184 without authentication

raw blaze
#

yeah the dashboard gets an exemption

#

this is the exemption that the 3155 card simulates, and in practise you should get it. The other cards help you test for cases where it doesn't work.

mellow tartan
mellow tartan
#

& for 4000002760003184 this type of card, stripe will send email to authentication or we need to handle it from our side. Like listen webhook & send authentication url to customer through email?

raw blaze
mellow tartan
raw blaze
#

then that is multiple separate payments and they'd need separate authentications yes

#

so I'd really attempt to change your business model to avoid that requirement if you can as it will just cause a lot of difficulty and complexity in the integration

mellow tartan
#

Yes.. we have also same feeling now. It's not that much scalable solution which we have right now.

#

Thank you so much @raw blaze for clearing doubts within short time. Feel great to talk with you! Have a good day

#

Hey @raw blaze one more question on indian stripe account

#

How to identify it's services or goods?

#

It's part for stripe account onboarding?

raw blaze
#

AFAIK if you pass a shipping address it is a good, otherwise it's a service.

mellow tartan
#

Ohhh that's case 😃

mellow tartan
#

Hey @raw blaze I'm passing billing address in customer & not passing shipping address in payment. But still getting error for indian stripe account

#

As per Indian regulations, goods export transactions require a billing and a shipping address. More info here: https://stripe.com/docs/india-exports

raw blaze
mellow tartan
#

Payment Intent: req_ryMoJVfxOIQprd

#

Customer: req_i4sLUD8xniQBV3

mellow tartan
raw blaze
#

well you're charging in USD which makes this an export transaction

#

therefore it's going to to require a billing address at least(the error message is probably just generic).

mellow tartan
#

But how we can identify that which account requires shipping address in SetupIntent/PaymentIntent?

#

I saw international payment success without shipping address in couple of indian accounts

raw blaze
#

I know very little about this part of the API unfortunately. Either way you're not passing a billing address in the example you shared so I'd start by doing that and seeing what changes. The billing address is always needed, you can look at the shipping address later if you still get errors.

civic wedge
#

@mellow tartan When you mention that you saw some successes, do you have the ids of those PaymentIntents and the ids of ones that fail?

#

As karllekko said, it's probably the requirements specific to India but we can confirm from examples

mellow tartan
#

@civic wedge success payment intent: pi_1JUsiDLQ5NLthNrHu5UvYsDe

mellow tartan
#

failed payment intent: pi_3JXl3kSBOGpc6PMH0DLjreQ6

mellow tartan
civic wedge
#

Is that an international payment? I see the merchant in IN and then the address of the customer is also in IN

#

(the successful one)

mellow tartan
#

no... success one pi_1JUsiDLQ5NLthNrHu5UvYsDe is $1 payment

#

merchant is IN but address of the customer is US

#

Let me clear some confusion here

#

We have 2 merchants & both merchants are IN & accept international payments

#

For one merchant, if we pass only address in customer creation, payment will be success

#

but for second merchant, it will be failed

#

So we are trying to find different between 2 indian accounts. We will guide our users

civic wedge
#

The general rule here is "if the address of the Customer is not in India, you have to provide both a billing and shipping address".

#

So if you're seeing a case where a payment succeeded when the Customer's address was not in India, that's where I'm wondering what's going on.

mellow tartan
#

Ok... let me create new request with new customer

civic wedge
#

👍 For that request the most recent update in that Customer's logs set the address to that India address ~2 minutes before the payment

#

(the Customer later was updated to have a US address, but that was after the payment)

mellow tartan
#

----------------------------new request------------------

#

Payment intent: pi_1JXlYYLQ5NLthNrHlw0qKAis
Customer: cus_KC9r9RGRpSBai5

civic wedge
#

I'm pretty unfamiliar with how we set up Indian merchants, but do you know if your account is specified as goods or services? That payment would succeed if it was for services, but I'd expect it to fail for goods.

mellow tartan
#

Yes.. it looks like it's failed for goods

#

How to check that?

civic wedge
#

It should fail for Goods because you need a billing address on the card, yeah.

mellow tartan
#

Yess

#

How we can identify that account is setup for services or goods?

civic wedge
#

Checking how we indicate that, not sure yet.

#

One sec

mellow tartan
#

Sure..

#

Also share some onboarding doc where customer has to select it's services or goods? Because our almost all customers accept payment for services but due to not aware about this, they by mistake select goods option during onboarding. So we will guide them on that as well how to create stripe account for services

civic wedge
#

As far as I'm aware, when you onboard in India you go through the export classification steps in https://support.stripe.com/questions/accepting-international-payments-from-stripe-accounts-in-india and the Transaction purpose code there indicates to Stripe whether you're doing Goods or Services. However, we wouldn't know here on the engineering side how that translates to a specific classification. You'd want to contact the support team via https://support.stripe.com/contact to get a definitive answer to how to make sure it's specifically Goods or Services.

#

(We definitely classify based on that as there are differences between the merchants used in those two requests that succeeded or failed)

mellow tartan
#

Can we get account Transaction purpose code using API?

#

So based on that, we will pass shipping address in payment intent. We don't want to pass for everyone

civic wedge
#

I'm not aware of anywhere that you'd see that code in the API.

#

Looking, though.

#

We expose MCC (which isn't the same as India TPC) but I'd suggest asking the support team as well. They may have a cheatsheet you can use to map from one to Goods/Services.

mellow tartan
#

Sure.. let me know once you will get mapping cheatsheet from your team

civic wedge
#

To be clear, I don't have those answers here. You'll need to contact the support team directly via https://support.stripe.com/contact

#

They will know the exact answers for your account

mellow tartan
#

Ok.. but how will get code from API? I checked account API but there is not that type of data

civic wedge
#

We don't expose it directly. The support team will be able to answer if there is a way to derive it or get it from the Dashboard, etc.

mellow tartan
#

Ok got it

civic wedge
#

That may be added to the API down the road but today, it doesn't show.

mellow tartan
#

Thanks @civic wedge for your support!!

mellow tartan
#

@civic wedge How can I pass shipping address in subscription?

#

Subscription: pi_3JXmelSBOGpc6PMH1g6vJFzD