Easy Digital Downloads 3.0 Update – February 13, 2019

Another couple weeks have passed, and we’ve got another development update on Version 3.0 of Easy Digital Downloads. Here are your changes since the last update.

New refund UI and APIs

In the past refunding items and orders didn’t quite follow basic tenants of the Generally Accepted Accounting Principles, or GAAP for short. This could create difficult situations in support when coming back to an order weeks, months, or even years later, to determine what was actually done with an order. Refunding an order was an all or nothing experience. If you wanted to remove a single item, it was completely removed from the order. As you may have experienced, this was less than ideal.

In EDD 3.0, we’ve completely changed how refunds operate. Refunds are now a specific type of ‘order’. Since a refund is similar to an order, they exist in the same database table with a type of ‘refund’. They also have related order items, which are the specific items refunded. You can refund some or all of the items from an order. Refunds can also have their own transaction IDs. We’ve worked up a user experience that I think will highlight this process here:

Next up for the refund process is getting gateway functionality baked in so that this new way of processing refunds works as seamlessly as possible with your enabled gateways.

Other improvements and bug fixes

  • Fixed a bug in the get_average_refund_time method, which caused a MySQL error. (#7148)
  • When creating a new order, tax calculations were failing when quantities were disabled. (#7072)
  • Further improved the view/edit order details Customer information section (#7052)
  • Fixed an issue that resulted in the status counts of orders to be incorrect when filtering the list table. (#7079)
  • Improved the way the product dropdown works with bundles. (#6760)
  • Improved timezone compatibility with PHP 5.5 and lower. (#7130)

Major updates yet to tackle

  • Improve the upgrade routines for stability – A host of improvements are in the works to make the upgrade routines more stable and accurate as well as fault tolerant.
  • Extension testing and compatibility – The time has come, to start working through extensions and make sure we can pre-release any known compatibility issues prior to 3.0 being released.

So those are the major changes since our last update. Keep looking for these posts until we hit the release date in order to make sure your upgrade to Easy Digital Downloads 3.0 is as smooth as possible.

12 responses... add one

Looks great! Haven’t hit needing to refund parts of an order but when it has happened it’s super annoying.

Not sure how the current gateway checkbox “Refund charge in ____” will be handled, especially with that hover-over/inline Refund link? A modal perhaps?

Thanks Brian!

As it’s still in ‘development’, we’re finalizing what all those little changes will be. We wanted to get this initial preview out so people can start playing around with it in their local development environments. We’ll be re-working the way gateways interact with this new refund interface next.

Refund process looks fantastic.

Iā€™m curious if you have a checklist of changes that need to be addressed in EDD extensions? Would be useful to check over my own extensions for EDD and any custom code.

Thanks Daniel!

We’ve got a preliminary set of things we’re looking for. As we finalize that set, I’ll be sure to publish that list of things you’ll need to change or account for on this blog. I really want to get through a few of our own extensions first though to make sure we don’t miss anything for 3rd party developers to be on the look out for.

It is great to see EDD progressing. I know how challenging it can be to overcome the inertia that can stem from the inherent risk of change. In the end, it is necessary and well worth it though.

How about some granular store manager permissions, or administrative restrictions, or rate limiting surrounding refunds?

What am I talking about? Refunds are a potential point of abuse. Imagine a disgruntled employee or hacker who refunds the last month(s) of revenue. Whist these types of abuse can’t be entirely prevented, the risk could be mitigated.

At the most simple, rate limiting could prevent a malicious actor from bankrupting the business.

That said, maybe it is best to handle this with custom code rather than adding complexity to EDD core. Food for thought.

We added roles in 2013, which give granular control of viewing and altering sensitive shop data like orders.

With 3.0 we’re adding support for refund windows. You can define how long refunds can be processed after the purchase at both a store and product level. You even have the ability to mark a product as non-refundable.

Along with those refund timeframes, are limits to who can process a refund. Someone with the `edit_shop_payments` capability has the ability to process a refund only during the refund window. It takes a Shop Manager or Administrator to process a refund after the window has expired.

The rate limiting is an interesting thought as well, so I appreciate that. I believe that limiting the refund window for restricted shop worker roles should help stop any bad actors from doing what you have mentioned above.

Great to see EDD progressing. Is there a time frame for the next release of Frontend Submissions? Will it have conditional logic on the product submission form? Thanks!

At this time we don’t have a timeframe on the next Frontend Submissions release. Right now we’re focusing getting EDD 3.0 to a state we can beta test it and also doing some work on gateways as there are some pressing changes coming this year that we are trying to get ahead of.

We do have an open feature request in GitHub for conditional logic within FES so it’s on the roadmap, just no date yet.

Thanks for the feedback and questions.

Fantastic! Partial refunds and the way it’s implemented is a very welcome improvement, dealing with partial refunds was always a drag (luckily I’ve only had to do a handful).
In a previous blog you were referring to a beta, but here you mention new features as well. Does that mean there is not a feature freeze yet? At some point I guess it would be better to get an MVP for 3.0 out rather than adding new features šŸ™‚

Anyway, keep up the good work, awesome!


This ‘feature’ was more of just exposing an API that was finished early in the process of developing 3.0. As far as features we’ve been in freeze for quite a while. I’m working on an update blog post with how extensions can account for the migration to the tables, and key changes to make, as well as a follow up with how the migration is performing.

Keep your eyes peeled for this update soon.

We are still actively working on it! Due to the SCA requirements and timeframe, we had to temporarily pull all development resources off of 3.0 so we could complete SCA. Now that SCA is finished, we’re getting back to 3.0.

Leave a Reply

Your email address will not be published. Required fields are marked *