#Dooing - 3ds recurring

1 messages · Page 1 of 1 (latest)

azure scarab
#

Hi there,
it depends on what card are you using, for example:

  • if you are using this card 4000002760003184
    which requires always 3DS authentication => you need to ask the customer each time to confirm his card
  • if you are using this card 4000002500003155 which requires 3DS authentication unless set up, no need for further confirmation
#

Dooing - 3ds recurring

main pebble
#

Is that depending on the card type, or bank.. or country???

azure scarab
main pebble
#

This is the information I get on all kind of german portals:

#

When are there exceptions to the 3D Secure procedure?

The European Union Payment Directive allows some exceptions to the security rule. In this case, consumers do not necessarily have to identify themselves twice. This applies, among other things, to payments that do not exceed 30 euros.

--> Also, for recurring payments, such as subscriptions or invoices, there is usually no strong customer authentication. For standing orders, you only have to identify yourself twice at the beginning. Subsequently, the amount of money is debited without authentication.

#

so that says that for recurring payments (subscriptions!) there is only one initial authentication

azure scarab
#

Yes in most of the case if you well set up your payment flow,
(for subscription: https://stripe.com/docs/billing/subscriptions/build-subscriptions or for simple future reusage https://stripe.com/docs/payments/save-and-reuse )
no need for further authentication, but there is still some card that may requires always authentication like 4000002760003184
https://stripe.com/docs/testing#international-cards:~:text=This card requires authentication on all transactions%2C regardless of how the card is set up.

main pebble
#

so in this case, the automatic payment would fail, and I would receive a notification over an event that I would need to care of?

#

Is there any easier way?

azure scarab
#

Unfortunately no, for that specific card type ( like 4000002760003184) no you need to ask the user to authenticate him self on each payment

main pebble
#

yeah, but for a subcription, how would I be notified of the need... via a failed event, I assume

#

and then I would need to inform the offline customer async, e..g by sending an email, to log into my app and do 3D secure

azure scarab
main pebble
#

in the frotnend then, for every customer logging in, I would need to ask the backend if there is an open 3D secure payment that needs confirmation, and show the confimration UI in that case

#

ok. And now again - you said - you can. Is there a different and or easier way also?

inland dew
#

Yes, that would make sense to show this status to your users so that they can complete 3DS auth if need be.

#

ok. And now again - you said - you can. Is there a different and or easier way also?
Which of os4m37's messages are you talking about here? os4m37 had to step out but I can help see if there is an easier way

main pebble
#

os4m37
—
Today at 3:16 PM
Yes, you can listen to this webhook event invoice.payment_action_required

#

the question is - if in a later subscription cycle, a 3d secure re-confirmation is required, is there a different or easier way then listrening to the event - invoice.payment_action_required

inland dew
#

That event is the one to listen to if you are sending this email yourself

#

You can also change your settings so that Stripe sends out an email automatically instead of you having to listen and send one yourself

main pebble
#

and then the end-customer would be send to a stripe UI?

inland dew
#

Correct, that would send them to a Stripe hosted page to complete 3DS

main pebble
#

ok. Now a different question. Losely related. So one flow that I used in t he past - might not be the best, but I would like to start with it since I have it working in a different app -
for 3d Secure, setting up a client with credit card and then starting a recurring subscription - there is flow of events..
Since I currentyl dont have access to my UI (or better to say the dev behind in 😉 it is a bit difficult to decyper the flow of events.
I have a method in the backend to set up a payment method setup intent - and a method to add a credit card.
What is first?? Adding the credit card, and then with the stripe payment id that i receive, ask for a payment setup intent / secret, that I send back to the frontend so the fronend confirms adding the credit card... or does the frontend somehow add the credit card directly with stripe, and then call the setup intent method to receive the secret to again do the confirmation.. and add payment method in the backend is only for adding payment methods later?
Interestingly.. the setup intent method has a payment method id param.. but it works also without.... I am confused

#

oh and I actually forgot about the connection of card and customer as primary card

inland dew
#

So Setup Intents can be used a couple ways. The most common use is to create Payment Methods. Usually one will make a setup intent without providing a payment method ID and then they can use the intent to create a payment method and go through 3DS auth

#

You can also use them on existing payment methods to do 3DS auth if it wasn't done while setting up the payment mehtod initially

#

It is hard to tell which your integration is doing given what you are saying right now. Can you go through your card setup flow in test mode and send me the ID of the resulting setup intent (seti_123) so that I can look further in to this?

main pebble
#

I went through the entire flow... hope that is ok... because testing the UI.. its hard to stop in the middle.. 😉

#

cus_MIBXHiAeqPlgNg
sub_1LZbBBAfQ68zM8anpFoUzFrt
pm_1LZbB8AfQ68zM8anxhB7DaQn

#

And I also used that "always 3D secure check necessary" test card and indeed - with this, it seems
My existing process has an issue:
Incomplete:
cus_MIBTtl6iJM8z0h
pi_3LZb7EAfQ68zM8an1eHck7XW

inland dew
#

Thanks, I will check those out

inland dew
main pebble
#

ok so for 1)

#

sorry your link is broken

#

and, in short - so how is the flow - first the customer is created, then the credit card, then the card is confirmed with the secret, or first teh secret is retrieved and then confirmed...

#

thats the question

#

and for 2) there was a test popup where it asked if I wanted the 3dSecure to suceed or fail, and I clicked succeed

inland dew
#

Fixed the link, my apologies.

#

The card is created when the secret is confirmed

#

And that is good to know. Checking in to what may have happened here

main pebble
#

but do I send the card id to GET the secret, or not?

inland dew
#

In this case, you are providing a card ID to the setup intent. So yes, you are using that to get a client secret here

#

You don't need to pass a card to get a secret but your integration is doing that as part of your flow

main pebble
#

So how can I have card id without the setup intent first???

inland dew
#

It looks like you are creating the payment method directly using a client side call. Can you check if your client side code has createPaymentMethod somewhere in it?

#

So it looks like your integration currently does this:

  1. Create payment method pm_123 with a client side call
  2. Create setup intent seti_456 providing ID pm_123
  3. Confirm seti_456 to create payment method pm_789
#

And presumably your integration will then check if 3DS auth and whatnot need to happen after step 3

main pebble
#

and wait

inland dew
#

Is that helpful here? I feel like that might be confusing

main pebble
#

and 4) is probably connect the card to the customer

#

?

inland dew
main pebble
#

is that flow "good" or not"

inland dew
#

That is a link to a call your integration made to set it as the default payment method

main pebble
#

?

#

which AFAIK is required

#

(default setting)

inland dew
#

Yes it is. So actually #3 is what attaches the payment method to the customer. You create the setup intent with a payment method ID and customer ID so confirming it automatically attaches

main pebble
#

and the secret / payment setup call and confirmation through the frontend is needed (for 3D secure) or not??

#

you said it could be done also without the payment id

inland dew
#

Yes, you need a setup intent at some point to do 3DS

#

Yes, it is possible to just create a setup intent and use that. I will find a doc on this and send it

main pebble
#

Create payment method pm_123 with a client side call
2. Create setup intent seti_456 providing ID pm_123
3. Confirm seti_456 to create payment method pm_789

--
Sorry, confused again.
In step 1-3 we are just creating a card.. with no actualy reference to a customer, or so I thought?

I see a call from the backend which attaches the card to the customer and / or makes it the default card of this customer, which I think is the same as just attaching it

#

CustomerUpdateParams updateParams = CustomerUpdateParams.builder()
.setInvoiceSettings(CustomerUpdateParams.InvoiceSettings.builder()
.setDefaultPaymentMethod(stripePaymentMethodId)
.build()).addExpand("invoice_settings.default_payment_method")
.build();

#

You create the setup intent with a payment method ID and customer ID so confirming it automatically attaches

#

AH! So you are saying... since I create the setup intent WITH the payment method Id ANd the customer id, stripe is smart enough to already attach the card to the customer... but then... do I still have to make that final call to make it the default card?

#

or, given there is just one card, will it already be the default card??

inland dew
#

And yes that update call to make it the default is still necessary

#

It if isn't set as the default, it won't be used, even if it is the only card

main pebble
#

Ok so my current 3D secure flow is:

  1. Create a customer
  2. Create a payment method with a client side call.
  3. Create a setup intent with the customer id and the payment id.
  4. Confirm the payment method creation and attach it to the right client
    by using the secret, with a client side call.
  5. Update the customer's primary card to the payment method id.
    --
    Missing still seems to be that I should listen to the invoice.payment_action_required event and block the app in this case,
    until the customer confirmed the new subscription cycle payment with a new
    3D secure call.
    --
    This could also be excuted by stripe with an email send to the customer directly.

A) But what to do if the customer never confirms? Which event(s) will
stripe send (when?) to inform about this situation, so that at some point
the app can be closed for the not paying customer?

B) So I understood correctly from last week, the flow could be optimised -
what would you advise? Creating customer, payment method and subscription all together?

inland dew
#

I will look in to A in a moment but can address B right now in the mean time.

#

From a Stripe API call perspective, you can do this more easily by creating the Customer+Subscription, that Subscription will have either a PaymentIntent or SetupIntent depending on whether you are taking payment immediately or not. You can then confirm the secret of that payment intent or setup intent client side

main pebble
#

so if I create customer and subscription.. when do I create the payment method?
I assume:

  1. payment method
  2. Customer and subscription and ask for secret in the same call
  3. confirm payment method with secret and this way link payment method to customer.
  4. Set payment method as default card for the customer.
    Yes?
inland dew
#

Yes, in that case the payment method is created and attached to the customer once the setup intent is confirmed

main pebble
#

So yes, this new 1-4, is the best / the one with the fewest api calls.. or do it differently?

inland dew
#

Yes, that is the current flow that we recommend to anyone starting out basically. Though there can be reasons to do it differently. Unfortunately I'm not sure what might make the most sense in your actual integration. If your flow works now, you might not need to update it unless it is running in to issues. Or maybe you can try implementing a test version of the new flow and seeing if it works for your site?

#

Also sorry for the delay on A, basically you won't get further events about the payment itself but your subscription will go past_due and such as if the payment failed if the user does not go through 3DS auth

main pebble
#

how long until it will go to past_due?

#

is that triggering those 4-5 payment failed events also?

inland dew
#

It looks like your settings cancel the subscription after 15 days of 3DS not being done