szef0

[ember grotto]

Hi there

Hmm what do you mean exactly by "pay for their account"?

Like you are trying to create a charge for your Connected Account?

Are you using Direct Charges?

[blazing bear]

Hey, I just tried to pay for their account, because I recieved info that the payments arent going through - this is how it looks in the dashboard for them and mine is also Incomplete as you can see, because it didnt trigger 3D secure

we just use this -> $stripe->paymentIntents->create(

and I just paid using the same integration for our "TEST" account connected to the Stripe Connect

There works fine, because I have paid there before, but doesnt work for my client (same integration)

Here you can see, the first account is our test and works fine, but on the other accounts we dont recieve webhooks

[ember grotto]

Can you give me an example PaymentIntent that you created?

[blazing bear]

pi_3N86uRQxqLfhF0YX0ZMS1uzW

you mean this yes?

[ember grotto]

Yes that's good

And you are trying to create these PaymentIntents and Charges directly on the Connected Account, yes?

[blazing bear]

yes

[ember grotto]

Okay yeah that PaymentIntent was created on the Connected Account and is in a status of requires_action

So it did trigger 3DS

And now you need to redirect the the next_action.redirect_to_url.url since you set a return_url

[blazing bear]

Ok, now I kind of get it - when I open the link it triggers auth on my Revolut account so good. Can you please tell me why on this pi_3N86nsQoQEuHtH200WIzVBZ0 it didnt require it?

[ember grotto]

3DS wasn't required by the bank in that case.

It just moved to succeeded immediately

[blazing bear]

because "next_action": null was null yes?

[ember grotto]

Well yes, but really you just want to look at the status property

[blazing bear]

but to be honest, we should check whether we should redirect to redirect_to_url.url property or just redirect to our redirect_url - there is no other possiblities?

now it works fine, but want to be sure if there are some other cases?

I just checked 1 that required 3DS and it redirected me to VISA and other one that didnt and redirected back to our url and worked fine also - what else should we check?

also other question - this blocked is because our integration was wrong or their cards are bad?

[ember grotto]

As long as you are handling the redirect when the status moves to requires_action then you are good to go. The customer will automatically be sent back to your return_url after they complete 3DS.

You can click on those blocked PaymentIntents and view them in the Dashboard and there should be the reasoning for why they were blocked at the top of the page

[blazing bear]

this is the reason yes?

[ember grotto]

Yep

[blazing bear]

could it be some bad Card operator in Portugal? Because I see a lot of them with this client

[mighty pewter]

Hi there 👋 jumping in as my teammate needs to step away soon, please bear with me a moment while I catch up on the context here.

Based on the error you shared, it looks like those payments were declined because our fraud model detected there was a high likelihood they were fraudulent. We (my team) aren't too familiar with the aspects that Radar looks at to make that determination, so I'm not sure offhand what could be causing that. If by "card operator" you're referring to the entities we typically refer to as Issuers (the entities that issue cards), then I would recommend taking a look at the Payments to see if they are all coming from a single issuer but I don't think that is likely.

[blazing bear]

yes I see that it is VISA - we cant/shoudnt disable this Radar yes? The 3DS auth is automatic or should we always "require" itd?

Other client on the other hand succeded and there is this info "This payment is not protected from being disputed for fraud" why is that?

We pass the 'confirm' => true, to the paymentIntent is that correct?

[mighty pewter]

Visa is a card network rather than an Issuer, the Issuer is typically a bank providing the card.

[mighty pewter]

I'm not sure offhand, we primarily focus on the API side of integrations and I'm not sure what the messages in the dashboard indicate. Does the hpyerlink in that message take you to a page with more detail?

My suspicion, is that message is trying to explain that a liability shift did not occur because a 3DS challenge was not completed for that transaction:
https://stripe.com/docs/payments/3d-secure#disputed-payments

[mighty pewter]

Is this correct for what?

[blazing bear]

for creating PaymentIntent - I meant if this triggers 3DS secure maybe?

[mighty pewter]

Confirming a Payment Intent is part of their lifecycle regardless of whether they require 3DS to be completed to be successful. The confirmation step is when the payment authorization is sent to the Issuer via the card network for approval. By passing confirm => true, you're telling us to confirm the Payment Intent as well as the operation the request is driving (I'm guessing you're doing this when creating the Payment Intent).