#adnan
1 messages Β· Page 1 of 1 (latest)
It depends on the 3DS rules you set in the dashboard. You can refer to more details here: https://stripe.com/docs/payments/3d-secure#controlling-when-to-present-the-3d-secure-flow
@twin saffron are these changes already applicable?
Yes if you're using PaymentIntent or SetupIntent API
Were users asked to update to these changes via email?
This doesn't require changes to your integration
This is the change at the card scheme (visa, mastercard... etc)
If you're using PaymentIntents or SetupIntents API, 3DS2 has always been supported
Understood! Can we get this data for last two weeks? I saw dashboard doesn't support custom date field ! We want to see if there is a drop in %
Also I am checking on radar/rules for the rules we use, can you please direct me which part of the pages will be applicable to look into the rules?
Apologies for small level help! I am new to using stripe
Can we get this data for last two weeks? I saw dashboard doesn't support custom date field ! We want to see if there is a drop in %
This channel is for technical API integration. I'd recommend reaching out to our Support as they are the expert in getting data from dashboard: https://support.stripe.com/contact
Also I am checking on radar/rules for the rules we use, can you please direct me which part of the pages will be applicable to look into the rules?
Radar rules can be found in Dashboard > Payments > Rules under Fraud & Risk: https://dashboard.stripe.com/test/settings/radar/rules
For more details, you can refer to here: https://stripe.com/docs/payments/3d-secure#three-ds-radar
p.s. we are facing some sever backlash from the users are the past a few days for the failed payments! so we are quire frustrated at the moment
There are three titles under this page:
Authentication rules / allow rules / block rules
Which one should I refer to for my enquiry sake?
@twin saffron
For 3DS, it'll be under Authentication rules
We have these rules in place! With these in mind, going back to my original question:
Do as a user I need to perform 3ds every time? Or is it a one-time event that happens when user connects their card with the platform?
π taking over here
Thanks πββοΈ
Um your 3D Secure looks a bit aggressive. Normally only the first one is needed
How can the rest of two options impact UX?
It will require 3DS more often, as its name says, when 3DS is recommended or supported but not required
We always had these conditions but we didn't face the issues we are facing right now
Users being asked to preform 3ds even they have been old platform users
And to make things more difficult for us, theur 3ds is failing or is incomplete
Anyways, so we can say with such rules - it is possible even an old time users may be asked to perform 3ds multiple times even when they are being an old user on a platform?
Yes it's possible. The issuer banks hold the last for aftermost decision to require 3DS or not (that's how they regulate, or being law-regulated in their country). The banks could have conformed to a new regulatory and enforce 3DS on all their customers.
To be able to look closer, do you have an example Payment Intent Id lately? I will look at the decline message
Sure, brb on this
pi_3LurB1HIt450iiBT1LP7VEuj
pi_3LuqcfHIt450iiBT0N0PwIEn
pi_3LuW5hHIt450iiBT0ZWmG0Dm
pi_3LtjlFHIt450iiBT0ppTviup
Frist round of payment intent ids!
@forest plover πββοΈ
Are you from the same company with @fair solar ?
yep
Ok pi_3LuqcfHIt450iiBT0N0PwIEn is different from the other 3. It triggered 3DS but the customer canceled from frontend.
The other 3 PIs was never attempted 3DS. They are created+confirmed on server-side, but after became require_actions, they are never sent back to client-side to attempt 3DS
Normally when you create+confirmed the PI server-side and Stripe tell you this require_actions, you will need to bring back your customer online, and let them authorize again by using our client-side SDK
What could be the reason that these PIs were never sent to client side for 3DS?
(ideally we think these PIs shouldn't need 3DS because these are our old clients, who had done their 3ds when they connected their cards with us)
ideally we think these PIs shouldn't need 3DS because these are our old clients, who had done their 3ds when they connected their cards with us
I understand why you would think this way, but as explained above any card could be requested 3DS later, and the decision is ultimately hold by the banks. We recommend merchants to build a flexible integration that can always handle such a cases, not by assumption that "they shouldn't need 3DS because they have done"
There are various reason some bank could suddenly trigger 3DS. ie SCA in Europe or recurring regulation in India
Ahh, understood πββοΈ
Anyhow, why these PIs were not sent to client side for 3DS? where would problem lie for this behavior?
From Stripe view I can only see the logs, and from the logs there was no confirmation attempted in frontend
I think simply because you haven't built the handling logic for this case?
When 3ds isn't triggered at all for PIs, which happens by the bank > what are we supposed to show on the client side for confirmation? and confirm what exactly when their is no 3DS from the bank side?
How can we handle such cases? What should our clients be seeing?
Thanks @forest plover this conversation is leading us somewhere - so we really appreciate your support πββοΈ
Let's take pi_3LurB1HIt450iiBT1LP7VEuj for example. When you create + confirm it by https://dashboard.stripe.com/logs/req_IRPzhk7NHqjf0N
Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.
Your code should look at the response next_action. Here it says use_stripe_sdk
You would want to build a page, using stripe.js 's handleNextAction and supply this PaymentIntent Id. Then you email your customer asking them to go back into that page.
1 min, I will find Document about handleNextAction
You can look at its diagram. Your flow should start from here
I see, let us take a look into our code and get back to you confirm if we are missing this bit to handle such cases π
Sure. The key point, on server-side, whenever you see a require_actions PI, you should trigger this flow
Meanwhile, can you please check what is the status of these two PIs on your side? 3ds is successful for these two but remains uncaptured?
pi_3LusDbHIt450iiBT1wTgcorg
pi_3LtoJoHIt450iiBT0BMyL06b
πββοΈ π
Yep correct. These are good, you just need to call Capture on them
Hi @forest plover
Me again π
I think this part is handled by Stripe SDK ? Our app (CA) use Stripe SDK to do 3DS auth.
Normally uncaptured PI will expire in 7 days
@fair solar let's continue in our thread, sorry to mention you here
Oh I see, probably sever already send back to the app?
I doubt that the PI is lost somewhere between server and app then, or the customer never re-visit the app again
Yes, please refer to this video
This is a succeeded one.
I thought app will redirect user to three_d_secure url, and when they finish the auth, then Stripe will receive the result right
Which PI corresponding to that screen recording? Sorry both of you provided quite a lot of PIs and they are all different
Back here - However our system didn't call Capture for these PIs? So what could be the reason for that? Apologies for the information overload πββοΈ
Um I am not sure? From Stripe's point of view I simply don't see the Capture call. When you create your PIs you have
capture_method: "manual",
means you will need to call Capture somewhere
My suggestion is look at the code where should be sending Capture, and investigate on why it wasn't triggered for those 2 PIs
For example if you are calling Capture based on receiving a specific Webhook event.
Ah understood! That's a solid action point on our side, let me get back to you ~
@forest plover is there a chance to have an audio call with one of you guys?
Sorry we don't have phone support service but we are happy to help here
I am trying to communicate this with my dev but can't make them understand! can you please make things easier to understand for us : #1032876081948139520 message
I would suggest using the Doc links. It has clearer diagram and explanation
ππ½ππ½ ππ½
Back with the second round (hopefully last) of PIs! Here is some context:
Sometimes our user would add extra requirements in their orders after the hold has been captured, in such scenarios their order price would increase from X to Y ! Our system is expected to charge Y amount to these customer however it is not able to charge the full amount to these users! Sample PIs:
pi_3LusqrEn1D9f60DB0goMhqFW
pi_3Ltll5En1D9f60DB1R98Egmy
pi_3LrXTcEn1D9f60DB0bcPRJmg
pi_3LrxtDEn1D9f60DB0HBYKnWb
@forest plover πββοΈ
I am a bit confused. You mentioned "after the hold has been captured", so you already captured X, but now want to charge for (Y-X)?
But then you will charge X + Y? That's overcharge
That's before the capture, right? Because you said after the capture
Okie
All 4 PIs you provided succeeded and I am not sure if they was your charge for X or Y, and where is the error?
For example for pi_3LusqrEn1D9f60DB0goMhqFW
The system was supposed to charge $643 ( price Y ) but instead it charged $570 (price X)! The reason being is 3DS attempt incomplete
Thanks Soma πββοΈ
Yes, I can see that this payment required 3DS. This is up to the bank to request 3DS or not. And when the bank does request 3DS, you have to ask your user to come back to your website/app to confirm the payment and go though the 3DS flow with https://stripe.com/docs/js/payment_intents/confirm_card_payment#stripe_confirm_card_payment-attached
So what happened in this case? Did user perform 3ds? Were we able to prompt user to perform 3ds on the front end side?
Here you created the PaymentIntent from your backend, and then nothing happened. So the call to confirm the PaymentIntent is missing.
Pardon, this doesn't make things clear to me!
Bdw did this case happened to all of the above three PIs?
For pi_3LusqrEn1D9f60DB0goMhqFW, here's what you did and what is missing:
- [done] Create the PaymentIntent on the backend, it had
status: "requires_source_action" - [missing] ask the user to come back to your website/app and call
confirmCardPayment()(link above) to start the 3DS flow - [missing] the user finishes the 3DS flow, and the PaymentIntent get
status: "succeeded"
Bdw did this case happened to all of the above three PIs?
Can you share the PaymentIntent IDs?
pi_3Ltll5En1D9f60DB1R98Egmy
pi_3LrXTcEn1D9f60DB0bcPRJmg
pi_3LrxtDEn1D9f60DB0HBYKnWb
Yes it's the same issue.
The bank is requesting 3DS, but you are not calling confirmCardPayment() to start the 3DS flow.
What does missing mean here? It isn't part of the code? Or it didn't return the expected behavior?
Great help @tawny pelican π
Your code created these PaymentIntent correctly. The bank, for whatever reason, decided that 3DS secure was required (because status: "requires_source_action"). So your code needs to handle that case by: (i) asking the user to come back to your website/app and (ii) call confirmCardPayment() (link above) to start the 3DS flow. So you need to review your Stripe implantation to make sure you handle (i) and (ii). Based on our log, you never called confirmCardPayment() for the PaymentIntent you shared.
(FYI I just edited my reply above with more context)
Hi @tawny pelican
But all the clients reported said they have started the 3DS flow.
We have our app (CA) using Stripe SDK to do 3DS, and the clients said they have encountered these issues.
1.complete 3DS and white blank page and canβt back to CA (keep spinning)
2.complete 3DS then no response, CA hang and need to kill app -> open CA again
As far as I know, the 3DS verification flow is handled by Stripe SDK right ? And Stripe will receive the result when 3DS verification finish.
So the missing part is between 3DS verification and the Stripe receiving the result. Is there a way to test ?
Give me a few minutes to look into this.
Sure @tawny pelican - Please take your time ~
Could you share more details about your integration? Like can you share the code you are using to create the PaymentIntent and handle 3DS currently?
@fair solar
@tawny pelican
We logs the request sent from CA, it sends request to here: https://api.stripe.com/v1/payment_intents/pi_3LvGMlHD3HubdpRJ0dL4iq4b?client_secret=pi_3LvGMlHD3HubdpRJ0dL4iq4b_secret_8L8eSIKLhmUNIk8KGofhpqdXD
and CA will get response like this:
"amount": 15500,
"amount_details": {
"tip": {}
},
"automatic_payment_methods": null,
"canceled_at": null,
"cancellation_reason": null,
"capture_method": "manual",
"client_secret": "pi_3LvGMlHD3HubdpRJ0dL4iq4b_secret_8L8eSIKLhmUNIk8KGofhpqdXD",
"confirmation_method": "automatic",
"created": 1666340047,
"currency": "hkd",
"description": "HK Transport Order #<To be confirmed>",
"id": "pi_3LvGMlHD3HubdpRJ0dL4iq4b",
"last_payment_error": null,
"livemode": false,
"next_action": {
"type": "use_stripe_sdk",
"use_stripe_sdk": {
"source": "src_1LvGMlHD3HubdpRJNNVsKdtI",
"stripe_js": "https://hooks.stripe.com/redirect/authenticate/src_1LvGMlHD3HubdpRJNNVsKdtI?client_secret=src_client_secret_ebO3jns1VzKqA4GlNX0k72HB&source_redirect_slug=test_YWNjdF8xQmczVjFIRDNIdWJkcF
JKLF9NZVpWTmxZQW5FRG9PQjljM2JxVzI2WWZmajBMZkdv0100YVPygcTo",
"type": "three_d_secure_redirect"
}
},
"object": "payment_intent",
"payment_method": "pm_1LvEGjHD3HubdpRJr00xYOXi",
"payment_method_types": [
"card"
], "processing": null,
"receipt_email": "qa4@gogotech.hk",
"setup_future_usage": null,
"shipping": null,
"source": null,
"status": "requires_action"
}
And then can see the 3DS authentication page, and during the authentication and , it's not handled by our side right ?
The integration code will be provided later π
And what do you do with that API response? Do you look at the information inside next_action.use_stripe_sdk to start the 3DS flow on your own?
@tawny pelican we are in another meeting at the moment, let us get back you in a while! please stay tuned
Hi @tawny pelican
I'm still gathering the informations π
Thanks
Hey, taking over here. Let me know if there's any follow-up Qs I can answer!
Hi @timid hare
This is our code in iOS
import Foundation
import Stripe
protocol StripePaymentProtocol {
var publishableKey: String? { get set }
var connectAccountId: String? { get set }
func confirmPayment(
clientSecret: String,
context: STPAuthenticationContext,
completion: @escaping Stripe.STPPaymentHandlerActionPaymentIntentCompletionBlock
)
}
extension STPPaymentHandler: StripePaymentProtocol {
var publishableKey: String? {
get {
Stripe.STPAPIClient.shared.publishableKey
}
set {
Stripe.STPAPIClient.shared.publishableKey = newValue
}
}
var connectAccountId: String? {
get {
STPAPIClient.shared.stripeAccount
}
set {
STPAPIClient.shared.stripeAccount = newValue
}
}
func confirmPayment(
clientSecret: String,
context: STPAuthenticationContext,
completion: @escaping Stripe.STPPaymentHandlerActionPaymentIntentCompletionBlock
) {
let params = STPPaymentIntentParams(clientSecret: clientSecret)
params.returnURL = "ggv://stripe" // for webview fallback
STPPaymentHandler.shared().configUI().confirmPayment(params, with: context, completion: completion)
}
}
Thanks @timid hare - Looking to get your help for the closure π
It should be this line to use Stripe SDK @timid hare
STPPaymentHandler.shared().configUI().confirmPayment(params, with: context, completion: completion)
Thanks for sharing all of these details, give me couple of minutes while I check this please
Thank you
Sure @timid hare - Take your time π
Hey, checking in here. This issue will require an in-depth investigation from our team in order to figure out the root cause. Can we ask that you write in to us via https://support.stripe.com/contact, providing as much detail and context as possible (you can also reference this thread).
What is the expected time that will be take on stripe side for this in-depth investigation?
I can't offer a specific timeline, but the more detail you can provide will help us debug this in a timely manner
Also, if you check the 'developer' box when writing in it will come straight to our team
Okay sure, our in-depth ticket is coming your way! @fair solar is on it ~
Thank you!