#[LBG] India-PCI-compliance
1 messages · Page 1 of 1 (latest)
Hi đŸ‘‹ that sounds like a question that the networks would have more insight into than we would, but you should always be PCI compliant.
Hi, yes, and we are, but from our dashboard we're not
I am stuck with old charges log from an old integration
Based on those dates, those charges only look like they're a couple weeks old. Did you just recently stop your older integration?
yes
The dates are false, we updated to payment methods in March
When I click on the on link it does not redirect to good evt
Can you copy/paste one of those charge IDs here?
Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.
req_rjyWO0e5u886Cd is from 2/24/2022
Oh I know, ch_3Khym9LJLkeHRLt11gWV0WMv
We still have charges running
Wonder how this one could pass SCA and not our new payment methods
I am really sorry to keep try harding this SCA ***** with you guys, I would rather do something else believe me
How come there is 0% authenticated eventhough we use Checkout ?
SCA and PCI are two different things
Yeah but I am trying to find anything that could affect our payments
Looking at the underlying payment method, it looks like it was created from Stripe JS. Do you have a flow where customers can provide their credit card information in a UI that belongs to you rather than Stripe?
What is the payment_method id you are talking about ?
card_1KWj1lLJLkeHRLt11jlVWbnq
Well, this is an old subscription (02/24/2022) using a non SCA integration, with card objects. Between 03/04/2022 and 04/13/2022, we were saving the payment method (credit card) and setting it by default on the customer using checkout in setup mode, then creating a subscription via API on the customer without finishing the necessary setupIntent needed to authenticate the off_session future payments linked to the subscription (for exemple : pm_1KbOPbLJLkeHRLt1jUHGLzup with seti_1KbOQmLJLkeHRLt1gql0ZlFx, there are two incompleted setup_intents, or even this one : pm_1KbPV1LJLkeHRLt1zGLl5DqL with
seti_1KbPVTLJLkeHRLt14hsR2GYP). But now, we create the customer via API, and then we create the subscription AND the payment method via a checkout session in subscription mode, so everything should be authenticated
We deployed our new integration the 04/13/2022 and already saw customers subscribing, but still 0% authenticated payments ?
Since our new integration all our customers have this new field I did not have before :
seti_1KoLymLJLkeHRLt13aPTtCJY
?
What geo is most of your traffic coming from?
France
Okay, so SCA should be somewhat common then, I believe. I'm honestly not sure what that chart from the dashboard is showing as we primarily focus on the API side of things.
Can we take a step back, can you clarify what your question is?
Why do I have 0 payment correctly authenticated ?
If it is not SCA exempted, it fails
Can you provide an example of a payment where you saw that?
I am looking at this
seti_1Kp8IyLJLkeHRLt1JXFnriYz
Why is the mandate null ?
Why there is no mandate in the setupintent created by the Checkout ?
you there ?
Yep, still looking. Setup should set this up properly. Checking in to the failed payment to see what that message said specifically
Hi @warm pumice, ok thanks
The payment for that user specifically failed from insufficient funds https://dashboard.stripe.com/payments/pi_3KqEk7LJLkeHRLt10Mc3Fkdh
Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.
This does not tell me why the mandate is null ?
Knowing that mandate seems to be required for what I've been struggling with for 2 months, but just discovered it
Mandates are mostly for bank accounts. If Checkout set up this card then the card should be good for payment. Here the issue is that the bank told Stripe that that card had insufficient funds to make the payment
You are set up correctly for SCA/3DS here as you are setting these cards up with Checkout which will walk the user through any initial 3DS requirements as they are setting up their card.
See recommended mandate text for saving cards or saving SEPA bank details.
For users impacted by SCA, this agreement helps payments succeed without interruption
The mandate property that you are looking at is expected to be null for cards
The Checkout Session successfully went through 3DS auth on that card for that Customer. We have all the proper data for that card on our side. In this case, you have everything you need from that section of the guide.
This decline came from the bank and did not indicate that a mandate was the issue. The card owner should reach out to their bank if they believe that this charge should have gone through.
It does not seem optional to me
To use merchant-initiated transactions, you must authenticate the card at the time of registration or first payment. Finally, you must obtain the customer's consent (mandate) to charge the card later.
That consent was collected by our Checkout Session when the Customer added their card and went through the 3DS auth.
The only thing that the bank told us is that that card has insufficient funds. We can look in to other payments but as far as I can see there is nothing indicating that that decline is mandate related.
This request includes several pieces of information, including the cardholder's address, your company's activity and the amount of the transaction. This information is encrypted in a message, according to the ISO 8583 standard. Issuing banks use complex logic to determine whether a payment should be declined: the ISO 8583 message contains 128 fields that each issuing bank can interpret and combine in its own way.
Also referred to as "issuer denial," a network denial means that the customer's bank has denied the transaction request. Transactions are typically declined for one of the following reasons: there are insufficient funds available on the card, the card information is inaccurate or outdated, there is a suspicion of fraud or malfeasance (for example, if an issuing bank believes a lost or stolen card is being used). A payment failure can also occur if the issuer suffers a breakdown and is unable to authenticate the card.
Translated with www.DeepL.com/Translator (free version)
That's what I've been screaming for weeks now. Banks handle declined codes as they like
With sometimes default ones
How do you explain this then :
0 payment authenticated correctly
Either exempted or failed
Hi đŸ‘‹ I'm stepping in for @warm pumice . There is a lot to catch up on so if you could just summarize
- What you are trying to do
- What isn't working
that would be a huge help
Hi @polar gyro
We have set up checkout for subscriptions, but still have issues with SCA
Okay so you are using Stripe Checkout for creating Subscriptions and the cards being used are running into authentication issues?
I just figured out that this cus_LVNp5n1cGwJDqk has a failed payment with incorrect card number
How is this possible with checkout ?
Can you share the Checkout Session ID for this event?
req_QuYp5q2hceLLV4
Thank you
Okay so upon confirmation this card was then required to go through 3DS authentication. You ca see that in the setup_intent.next_action property
WHich setup_intent ?
This one : seti_1KoN7nLJLkeHRLt1XJZlp53B ?
It has succeeded
Yes it did, after it was redirected through 3DS authentication
What's the link with the error "incorrect card number" ?
Where are you seeing that?
pi_3KpTYFLJLkeHRLt10DJ0ZJJY
You know what, nevermind
I'm done with Stripe
I know it's not your fault don't take it personally but nobody is able to identify what is going wrong with our integration even though were are loosing hundreds of customers
In my misfortune I am lucky that you are not alone on the market
I am sorry you feel that way.