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.
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?
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.
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.
Hi, is there any new update? When can we expect v3? 🙂
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.
When is the next 2-week update? 🙂
We should have an update in a week or so. Sorry for the delays and lack of publishing. Between a few high profile non-3.0 projects like SCA that took up months of our time last year, we’ve not made many breaking or significant changes in the concepts on 3.0. I recent came back from a paternity leave, after which we’re setup some milestones and plans for 3.0 moving forward.
We’ve isolated some specific work around the view order details screen and database layers for the coming weeks.
It’s been almost a whole year since the last update on EDD 3.0
Will we get one soon?
We definitely have not done a good enough job and sharing the progress of 3.0 and we would like to apologize for that.
I did share a few more details in my year-in-review post and we will be sharing a lot more very soon. Right now, we’re finishing up a number of UI and UX components and shoring up some data migration issues that were discovered recently. If all goes well, we’ll have an initial beta before the end of Q1. We will also be sharing some previews of the UI and refund processing work we’ve been doing soon here.
Good to hear! Look forward to seeing the previews.
As much as I’d love a new update too, I just wanted to stop by to offer some support & encouragement for all the work you’re doing on 3DD. I can’t even begin to imagine the breadth and depth of work that has to go into completely restructuring such complex (and vital) software.
The longer it takes, the more confidence I have in it. Keep trucking along, team! And thank you for everything you do 🙂.
Thank you for the support and encouragement Dave!
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
Thank you for everything you do!
and? what about the update?? we’re facing several problems with the database heavy loading, plus the BD has a lot of old registers in there….
there’s a solution? there’s a new version on the fly?
We’ve posted multiple updates since this blog post here, including one announcing the release of our first beta:
At this time we’re closing in our 2nd beta release which is focusing in on the order refund process. We’ve pre-released several updates to our add-ons in the past few weeks getting ready for the 3.0 release, so that there is no ‘transition’ period where our extensions are not compatible.
To be sure to keep up to date with our development of 3.0 you can follow this blog or even subscribe to the email list so that when we publish updates about Development of EDD, you get notified quickly.