Easy-digital-downloads: Build out refund API for processing / recording refunds

[zackkatz]

It would be helpful to see a visual of refunds as well as Earnings and Sales.

[pippinsplugins]

I'd definitely like to see this.

We will need to do a few things:

1. Store a Refunded Amount with each payment. This will support partial and complete refunds.
2. Add a graph for refunds overtime

[pderksen]

+1!!!

[cklosowski]

@pippinsplugins thinking of extending the functionality of the edd_undo_purchase function? seems a naming convention there is wrong and we'd need something more like edd_apply_refund.

There's a few things to work out though. If it's a partial refund (for maybe one product in the purchase) or if it's just a global 'discount' type of refund, how do we subtract earnings from a product(s) included. do we then extend out EDDSL to identify partial refunds as still valid licenses.

What do we do with taxation on partial refunds, if applied. I think we'll need to rework the entire 'undo purchase' process if we start supporting these type of refunds.

I'm all for this, just a few things to keep an eye on as we move forward.

[pippinsplugins]

I agree. The whole undo purchase process needs improved. It hasn't been touched much at all since it was first introduced.

[pippinsplugins]

This has to be punted for now since we don't yet store the refunded amount. We're already running an upgrade routine for 2.3 and I'd rather not run multiple/

[pippinsplugins]

Related to #2625

[pippinsplugins]

We're getting much closer on this with #4403 and the recent changes to EDD_Payment for refund processing.

Before we can go 100% with this, we need to work out a way to refund line items and/or full amounts.

[cklosowski]

I think in order to do this properly, we need our custom tables for Payments. Without the custom tables it's extremely difficult to make these relational information changes with full confidence. Because of that I'm going to have to punt. I want this to be done, but with our current data structure, it will be neither easy or consistant because of our current meta.

Thoughts on this for 2.8/9 @pippinsplugins?

[pippinsplugins]

I agree with that.

I hope we can do it in 2.8 or 2.9 but it will depend entirely on the custom tables project.

[JJJ]

I'd like for us to tackle this in 3.1, after all of the dust from moving to custom tables has settled.

We are going to put 3.0 beta 1 out today. It's _possible_ that we can sneak this in during beta, but I don't want to set that expectation by having this issue in that milestone until we know how beta goes.

[pippinsplugins]

I am okay with this not being in 3.0 so long as it is a top priority for 3.1. It's been one of our longest-standing weak points.

[JJJ]

Bringing this back to 3.0.

We'll need this in order to provide a UI for order adjustments anyways. I've already started on this, so this will make it into 3.0. <3

[JJJ]

Second pass at a UI that provides room to grow for partials, in release/3.0 now:

[JJJ]

Things to do here:

• Quick Add/Edit JS
• Non JS Add/Edit pages
• Settle on bulk actions & row actions
• Test with different Adjustment types & depths
• Test with add-ons, more migrated data, etc...

---

Bonus

I envision the "Recalculate" button UI (hidden in the above screenshot) for this continuing to be hidden, and happening on the fly (via AJAX and such) detecting changes as items & adjustments are tweaked.

So the Total input field would be live recalculated as individual items are edited, and changing the value inside that box would probably continue to do what it already would do, which is apply a global prorated price change across all order items.

[sunnyratilal]

First phase of refunds has been merged in.

This introduces:

1. edd_refund_order()
2. edd_refund_order_item()
3. edd_apply_order_credit()
4. edd_apply_order_item_credit()
5. edd_apply_order_discount()
6. edd_get_order_total()
7. edd_get_order_item_total()
8. edd_is_order_refundable()

[cklosowski]

Just had a conversation with @JJJ about where we should head with this and we've settled on a modal that presents itself.

Since our minimum version is 4.7, we can't rely on the 5.0 dialog JS, so we'll use jQuery Dialog to do this. We had discussed using the Free Downloads modal however, it presents it's own challenges, so using a known library for it is probably best.

We've made some improvements to the styles for it, so we can fine tune that so we don't end up with the stock designs. As I work up a UI for this, i'll post progress images.

[cklosowski]

Initial work is done here. Need to do some UI tweaks to make it a little more friendly but here is a preview.

Things to do still:

• [x] More fault tolerance code to catch exceptions
• [x] Include/Verify nonce usage
• [x] Final UI tweaks
• [ ] Work up gateway support for partial refunds (if they support, and when they do, how we send the partial refund to the gateway)

Stretch Goals:

• [ ] Include adjustments and discounts application to existing orders

[cklosowski]

I've gone through and added 'spinner' wait indicators when checking boxes (for browser delays), and when submitted. The success and failure icons are a bit more visible now. Nonce verification has also been added to the process.

[cklosowski]

Also fixed up a bug in WP core when loading a list table via AJAX, and changed the refund item list table to have it's own single and plural definitions.

[DrewAPicture]

@cklosowski Is there a PR or branch we could create a PR from with these changes?

[cklosowski]

@DrewAPicture I'll have to get one updated with all the recent changes.

[cklosowski]

@DrewAPicture PR Created.

[cklosowski]

Closing this out. Any changes needed to the refund process/API for gateways to support this new method/concept, should be put into new issues and developed in an isolated scope. This includes support for partial refunds.