Dispute system design for Vendure

[asonnleitner]

Vendure currently does not have a built-in dispute system, which can be a challenge for merchants and customers to resolve disputes about orders, fulfillments, and payments.

I'm wondering if it would be valuable to implement a dispute system in Vendure. This system would allow customers and sellers to easily create and manage disputes, and it would provide a fair and efficient way to resolve disputes.

What are your thoughts on this? Do you think a dispute system would be a valuable addition to Vendure?

Components:

• Dispute: A dispute represents a disagreement between a customer and a merchant about an order, fulfillment, or payment.
• Dispute line: A dispute line represents a specific issue within a dispute, such as a defective product, a missing item, or an unauthorized charge.
• Dispute participant: A dispute participant is a party to a dispute, such as a customer, a merchant, or a payment processor.
• Dispute state machine: The dispute state machine defines the possible states of a dispute and the transitions between those states.

Entities:

• Dispute:

  • id: Unique identifier for the dispute
  • status: Current status of the dispute (e.g., open, closed, resolved, unresolved)
  • createdAt: Date and time the dispute was created
  • updatedAt: Date and time the dispute was last updated
  • disputeLines: Array of dispute lines associated with the dispute
  • disputeParticipants: Array of dispute participants associated with the dispute

• Dispute line:

  • id: Unique identifier for the dispute line
  • disputeId: Unique identifier for the dispute the dispute line is associated with
  • type: Type of dispute line (e.g., product, fulfillment, payment)
  • description: Description of the issue
  • status: Current status of the dispute line (e.g., open, closed, resolved, unresolved)
  • createdAt: Date and time the dispute line was created
  • updatedAt: Date and time the dispute line was last updated

• Dispute participant:

  • id: Unique identifier for the dispute participant
  • disputeId: Unique identifier for the dispute the dispute participant is associated with
  • type: Type of dispute participant (e.g., customer, merchant, payment processor)
  • userId: Unique identifier for the user associated with the dispute participant (if applicable)
  • createdAt: Date and time the dispute participant was created
  • updatedAt: Date and time the dispute participant was last updated

State machine:

The dispute state machine would define the following states and transitions:

New -> Open -> In Progress -> Closed -> Resolved

A dispute can transition from the New state to the Open state when the customer or merchant creates the dispute. The dispute can transition from the Open state to the In Progress state when a dispute participant begins investigating the dispute. The dispute can transition from the In Progress state to the Closed state when the dispute has been resolved or determined to be unresolved. The dispute can transition from the Closed state to the Resolved state when the dispute participant has taken action to resolve the dispute, such as issuing a refund or replacing a defective product.

Relations:

• A dispute can have multiple dispute lines.
• A dispute can have multiple dispute participants.
• A dispute line is associated with a single dispute.
• A dispute participant is associated with a single dispute.

** Implementation:**

The dispute system could be implemented as a standalone module or as part of the Vendure core.

Benefits:

The dispute system would provide a number of benefits to Vendure merchants and customers, including:

• A fair and efficient way to resolve disputes
• Improved customer satisfaction
• Reduced workload for merchant or support teams

Conclusion:

I'm interested to hear your thoughts on the feasibility and benefits of implementing a dispute system in Vendure.

[mschipperheyn]

There should also be a Rejected state. A common scenario is that a customer by law has a right to x days return, no questions asked. Disputes usually occur when those x days have passed. In such a scenario, if the user made a mistake and say, ordered the wrong product, the merchant could reject the request (=> status: rejected). Or, choose to accept the request.

A dispute should include the possibility to include photos as proof of the problem that is the source of the dispute.

In case of product failure, I would say that there are some less common scenarios that might be possible, other than a simple return. One would be to simply send a new product and not ask for a return, bc it's simply too costly to process the return. Another might be to simply cancel the order without the return and refund the money.

So, it might make sense to have a Refund relationship as well.

If a return is accepted, there needs to be a return process. In many cases, merchant platforms will have deals with delivery partners and the general mail service to process returns. In such a scenario, the merchant would activate a Return (status: Return) and the system should interact through a Return strategy with whatever mechanism is available for that.

[asonnleitner]

I totally agree with you on the Rejected state. Some more descriptive states would be helpful as well. I came up with the following states:

• Created - The dispute has been created by either the customer or the seller. No actions have been taken yet.
• Pending - The dispute is currently pending review by the seller. The seller has not yet made a decision regarding the dispute.
• Rejected - The seller has rejected the dispute proposal and is awaiting the customer's response.
• Resolved - The dispute has been resolved; either the seller or the customer has accepted the other party's decision.
• Closed - The dispute is closed, indicating that all pending actions have been completed and no further actions can be taken.

I also agree that the disputes should include the possibility to include photos as proof of the problem that is the source of the dispute. I think this could be implemented as an assets field on the dispute proposal, which I completely forgot to include in my original post.

I also agree with the Refund relationship.

A ledger implementation would be extremely beneficial for handling refunds in a multi-vendor marketplace setup. With a ledger, fund transfers to either the customer or the seller would not have to be handled by the initial payment method. This would allow the marketplace to indirectly use the seller's funds to refund the customer, even if the seller does not have enough funds in their account to cover the refund immediately. Additionally, the customer could potentially receive their refund in a different payment method than the one they used to make their original purchase. Seller payouts could also be processed by other payment processors, giving the marketplace more flexibility in how it manages its finances.

[michaelbromley]

@asonnleitner thanks for the detailed proposal of a potential dispute system.

My initial feeling is that this could be implemented as a plugin, and would actually be quite a significant one in terms of complexity & features. This could either be a "core" plugin (part of the Vendure monorepo) or could be developed by the open source community.

For the next minor (v2.2) I'm planning on some improvements & simplifications to the way we manage refunds & cancellations (#2393) , which is quite closely related to disputes.

While I don't have time to work on this myself right now, I do think it is something we need to have available. If anyone is interested in working on this let me know. There is also the possibility to develop this functionality as a paid plugin that can feature in our upcoming marketplace (estimated to launch Q2 2024). This might offer an incentive for someone to put in the significant time it would take to design & develop a complete solution for this problem.

[gfomengia]

Any update on this?

[michaelbromley]

See my reply #2423 (reply in thread)

[chrislaai]

@asonnleitner thanks for the detailed proposal of a potential dispute system.

My initial feeling is that this could be implemented as a plugin, and would actually be quite a significant one in terms of complexity & features. This could either be a "core" plugin (part of the Vendure monorepo) or could be developed by the open source community.

For the next minor (v2.2) I'm planning on some improvements & simplifications to the way we manage refunds & cancellations (#2393) , which is quite closely related to disputes.

While I don't have time to work on this myself right now, I do think it is something we need to have available. If anyone is interested in working on this let me know. There is also the possibility to develop this functionality as a paid plugin that can feature in our upcoming marketplace (estimated to launch Q2 2024). This might offer an incentive for someone to put in the significant time it would take to design & develop a complete solution for this problem.

Sounds like a great implementation on Vendure's multi-vendor right? I'm curious if the plugin is a monthly or one-time payment🤔