Dilanbops

[buoyant kestrel]

hello! what do you mean by "compromised"?

[errant island]

Let's say the merchant app is using some third party library and we are not sure if the library is legit or it's collecting some data behind the scenes. I know for a fact that the iframe can prevent these libraries from accessing card numbers.

But what if I tell you that at merchant app itself that I can access all payment redacted_payment_details thats are saved by customer and I can access it, which I belive I can make payments using publishable key

If a merchant app can do that, any library added can also do it right?

[buoyant kestrel]

It's not possible to make payments with the publishable key alone. Also, the publishable key can only access limited, non-sensitive data. If you look at our API docs, the only information which can be retrieved with the publishable key will be indicated by RETRIEVABLE WITH PUBLISHABLE KEY

[errant island]

But to confirm a payment I'll need consumer_session_client_secret & client_secret $auth_session_client_secret along other things which are available easily, I'm just saying if i have acces to these data mentioned above I can make a payment right?

[buoyant kestrel]

You would need the secret key to generate a PaymentIntent client_secret. While the client secret is usually passed back to the frontend to for a customer to make payment, once the PaymentIntent is successful, it can no longer be reused.

Yes, if you have all of these information i.e. the client secret of a yet to be successful PaymentIntent, along with the publishable key, it is possible to make payment using an existing card. What would be the benefit to a bad actor to do that though? You can request for 3DS for all on-session payments to ensure that liability is passed on the issuer for any fraud disputes.

The concern for most users is usually card testers who test large numbers of cards to check if they're valid using scripts. It mainly comes down to making it hard to get a client_secret by limiting what they share with the frontend and only returning it when a user is authenticated and ready to pay etc; merchants can also add captchas to the part of their integration that returns a client_secret to make it difficult for card testers to get them quickly/easily.

[errant island]

Ok so while integrating Link I found that there is a token that is saved in local storage once authentication is completed. So everytime the SDK is opened with a new clientSecret it makes a /lookup call with the token from local storage, now this API returns the every type of details that I require to make a payment. So I thought if a merchant app is compromised so is the saved payment details of all customer.

[errant island]

??

[buoyant kestrel]

sorry but did you have a question? you mentioned all of that, but didn't explicitly mention a specific question that you had

[errant island]

No I just wanted to know if whatever I told is possible right? or Am i wrong?

[buoyant kestrel]

i think my original answer kind of covers the Link scenario also too doesn't it? If there's a specific scenario which you feel it doesn't, it'd help if you explained it in more detail

[errant island]

Ok got it so you are saying in this case even if the details are compromised 3DS will add on more level of security?

[buoyant kestrel]

yes, i would say so.