-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Disputes: inaccurate dispute notification when the dispute is in inquiry state after Klarna "return" process #7885
Comments
This issue impacts Disputes, so assigning to Helix (based on team responsibilities Pc2DNy-3z-p2) @Automattic/helix. Assigning as part of Gamma Triage process PcreKM-yM-p2. |
Just to clarify the following:
This is not correct. It was reported by a merchant using Klarna, correct, but the return process is triggered by the customer within the Klarna payments app. The intention is that Klarna and the merchant are alerted to the return. This distinction is important to understand, because the merchant does not trigger the inquiry - the customer triggers the inquiry. The merchant therefore has no control over the flood of non-dispute disputes. In 7401002-zd-a8c, the business model relies on returns and a smooth return flow. |
If I'm understanding this correctly, we are misrepresenting a standard Klarna returns process as a dispute. @souravdebnath1986 what are your thoughts on the priority of this issue? |
Marked as medium priority for now. Klarna is a subset of transactions, but if the dispute flow & notifications are incorrect, we will need to fix, as the issue will continue to affect Klarna merchants. |
@souravdebnath1986 can you advise on priority? This might be Also we'll need to clarify how to reproduce this and the exact pain point / inaccurate UI. @nicdwilson @dpaun1985 can you add steps for how to reproduce this, or screenshots of the relevant UI so the incorrect UI is clear? |
Yes, this could be This is the difference between Klarna (closed loop scheme) and other card schemes - For Klarna, inquiries are triggered when the customer reaches out to Klarna with a complaint. Klarna notifies the merchant. Merchant has to reach out to the customer on their own and attempt to resolve the inquiry. No defense submission to Klarna is required irrespective of whether the merchant agrees or doesn't with the complaint. If they don't agree to the inquiry, it will result in a formal dispute from Klarna at which point the merchant can submit defense documents. Process explained here For other card schemes, if the merchant doesn't agree with the complaint, they should do a defense submission else it will result in a chargeback which can be unwinnable because of non-response to the inquiry. If they agree with the complaint, they should issue a full refund. Partial refunds can still result in a chargeback. In the case above, the customer reached out to Klarna to request for return of an order. Klarna reached out to the merchant with an inquiry. The merchant has 21 days to resolve the inquiry with the customer which is upto the merchant i.e satisfy the customer by convincing them to not return or issue a refund etc. Klarna at the end of 21 days will check with the customer if they are satisfied, if so close the inquiry and if not close the inquiry > raise a formal dispute. |
To move this forward we need to reproduce the scenario. If we can't reproduce in test mode, we could also try a production store (if practical) or reach out to Stripe to get detailed info about how Klarna returns are represented on Stripe platform. |
See also similar issue for SEPA disputes, which has more reports (tickets) linked: #3909 |
Another 2:
|
ReproductionI've spent some time trying to reproduce this issue. Klarna has a bunch of test accounts to simulate disputes and returns (which it sounds like is the case here. Using the In the original case reported, it was only an Inquiry. So this problem that merchants are having is not yet reproducible. |
I've created a server issue to update the email copy for inquires which should help resolve this issue. |
7854828-zen The merchant is quite frustrated since they are not able to process refunds and they have 2k+ of pending disputes. Earlier messages here indicate that refunds should in fact be possible as this isn't an actual dispute. The merchant mentioned this:
Although earlier they indicated a different button:
Is there a process of refunding these orders that are falsely indicated as disputed or should the merchant follow a standard refund process? Should they still reach out to the customer? Edit: the merchant mentioned that only full refunds are possible but not partial refunds:
Is there a workaround for a partial refund? |
We cannot currently test the returns flow, this is a limitation of test accounts. I have managed to test a return on a live account in test mode using test credentials. However the return showed up as a full dispute rather than an inquiry that they should.
Both full and partial refunds should be available when a merchant has an inquiry. Here is how this works. Screen.Recording.2024-03-11.at.3.12.09.PM.mov |
The original issue mentioned here is now solved. There are now separate notification emails for inquiries. If there are other issues with disputes and klarna please open a new issue. |
8014625-zd-a8c |
Describe the bug
When a inquiry is created, the merchant receives a notification email that the disputed charge and the dispute fee will be deducted from their account.
Inquiries are similar to disputes, with three key distinctions: no funds are withdrawn unless the inquiry is elevated to a dispute, they remain refundable until disputed , and have a different set of statuses.
This was reported by a merchant that uses Klarna. In their Klarna app, when they return a product, they have a button ”I’ve made a return” that creates an inquiry. At this step, the merchant is not charged for the dispute, and they can refund the order.
However, the merchant receives the email notification that a dispute was created, and they will be charged with the dispute fee.
7401002-zd-a8c
p1702293773268309-slack-C7U3Y3VMY
The text was updated successfully, but these errors were encountered: