Skip to content
This repository has been archived by the owner on Feb 2, 2022. It is now read-only.

Handling a refund in the code #309

Closed
Bird87ZA opened this issue Mar 13, 2021 · 9 comments
Closed

Handling a refund in the code #309

Bird87ZA opened this issue Mar 13, 2021 · 9 comments

Comments

@Bird87ZA
Copy link

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?

@Bird87ZA
Copy link
Author

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?

@sandervanhooft
Copy link
Contributor

sandervanhooft commented Mar 13, 2021

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.

@Bird87ZA
Copy link
Author

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?

@sandervanhooft
Copy link
Contributor

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. 🤞

@sandervanhooft
Copy link
Contributor

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

@Bird87ZA
Copy link
Author

Checking now. Will update

@Bird87ZA
Copy link
Author

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.

@sandervanhooft
Copy link
Contributor

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.

@sandervanhooft
Copy link
Contributor

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

Thanks again for your report.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants