cashier-mollie
cashier-mollie copied to clipboard
Dealing with chargebacks and refunds
Hi,
I was wondering how this package handles a chargeback. I can see here that when a payment status
is paid
it set's the payment to paid.
However when a payment is a chargeback
we still get the status paid
from mollie. So in this case
it would go through that handlePaymentPaid()
method again right?
https://github.com/laravel/cashier-mollie/blob/d2b85e9c1f44d502ee6160fe1c1985f97e4f53b9/src/Http/Controllers/WebhookController.php#L26
--EDIT
It will nog go into the switch because of this $order->mollie_payment_status !== $payment->status
. But now de order status keeps paid
but it should be chargeback
.
Mollie has no separate status for chargeback
(or refund) unfortunately. There have been some discussions about that with Mollie's dev team but the issue remains unresolved for now.
I'm thinking about a solution for detecting state changes, may become a separate package. Would require a database modification ,so v2
.
@sandervanhooft I think they should change that it's weird when a payment is charged back
the status is still paid
.
Not going to happen. Semantically they are not wrong, a charged back payment is still paid for, so paid is an end-state here.
One of the possible solutions that were discussed is introducing events or an events API. This would be a big thing so if Mollie decides to go that way it would take a long time.
For now/cashier-mollie: I'm looking into handling chargebacks and refunds.
For a refund: the subscription should continue and an invoice should be generated. For a chargeback: the subscription should be cancelled. Not sure about the invoice.
We can use $payment->hasChargebacks()
and $payment->hasRefunds()
in the WebhookControllers.
In exotic cases, a payment can simultaneously refunds and chargebacks. For supporting these cases properly would require to store payments locally and diff them. This would require a more sophisticated approach, perhaps even an event store. It may be interesting for cashier-mollie v2.
For v1, we could simply check for the payment having a refund or chargeback. I expect this to cover 98% of the use cases without introducing a breaking change.
@sandervanhooft thanks that makes sense 👍