Handling a refund in the code

Question

Handling a refund in the code

Bird87ZA opened this issue 4 years ago · 9 comments

I recently (yesterday) set up mollie and first want to give kudos to the team for excellent documentation. Setup and everything went down without a hitch and I'm really impressed.

I have been playing around with it ever since and have a question. What I can see from the documentation is there is no refund feature. So I want to understand how the system currently works.

I triggered a refun on the Mollie Dashboard. 10 mins later, it called a webhook. And this is where it becomes unclear. From ngrok, it looks like it's calling /webhooks/mollie/first-payment. Which then creates another subscription, order_item and order in my DB. They all look the same, so I see no way that I can determine if this has been refunded on Mollie Dashboard, in my app.

I've gone through the documentation and can't see any mention of other webhooks that need to be set up, and can't really find anything on Mollie Dashboard that looks like it should be changed.

Basically, the question is, how is it currently working, and how would I be able handle a refund on my end?

Answer 1 · 2021-03-13T10:44:53.000Z

After some more research I see that Mollie itself doesn't support refunds (unless it's the first payment). I also found issue #157 explaining a bit more abour refunds and chargebacks.

Now all I want to know is why mollie makes a call to the webhook and then creates more subscriptions/orders?

Answer 2 · 2021-03-13T15:57:10.000Z

Thanks for reporting this. It looks like a bug - on first payments only.

Cashier v1 does not handle refunds nor chargebacks, and simply ignores these webhook calls. However as you reported there seems to be a bug for handling these calls on first payments. We'll look into this.

Cashier v2 will bring support for refunds.

Answer 3 · 2021-03-13T16:05:15.000Z

Thanks for the feedback @sandervanhooft. Let me know if you require anything from me for the bug. I assume the bug is on Mollies side and not in the library? Since that is what's making the webhook call?

Answer 4 · 2021-03-13T16:36:19.000Z

Hi!

If you perform a refund, Mollie will call the payment webhook, only passing the paymentId. Cashier then needs to sort out why that webhook was called.

I hope Mollie will make figuring out the changes easier someday, but for now this needs to be done locally.

I've prepared a patch to handle these calls the same as on mandated ("non-first") payments: do nothing and reply with a 200 OK response, so Mollie gets informed the webhook call was received ok. You can check the latter on the payment resource in Mollie's dashboard.

Because we need to figure out what happened locally I need to store more data, which involves a breaking change. That's why the support for refunds has been pushed to v2. If everything goes well the alpha for v2 will open up in a few weeks. 🤞

Answer 5 · 2021-03-13T16:37:03.000Z

Can you check out and see if the develop branch fixes your problem?

Answer 6 · 2021-03-13T16:39:08.000Z

Checking now. Will update

Answer 7 · 2021-03-13T17:07:11.000Z

Okay. It works. Thank you very much. I'm not getting duplicate rows now. Looking at your patch, what you did makes sense.

One last question: Why are there two rows added in order_items? I see one has a process_at time, the same time in the future as my plan interval, so I'm assuming it's handled by the scheduler. I'd just like to understand why this is there.

Answer 8 · 2021-03-13T20:45:31.000Z

Thanks!

One is paid, the other is scheduled. The cashier:run command scoops up all scheduled order items that are ready to be processed and create an Order for it. This way, if a customer has multiple subscriptions for example, (s)he'll receive a single invoice for both order items.

Answer 9 · 2021-03-13T20:52:57.000Z

I've just officially released the patch - v1.16.2.

Thanks again for your report.