Hey Albert,

That would not be a future or fix in Easy Digital Downloads 3.0, and will require some changes to our Recurring Payments extension to execute properly. We’ve logged an issue to look into the possibility of this, but we will need to look into what type of impacts it may have amongst other areas of EDD and Recurring.

Thanks for your interest.

What about the address issue that Thomas mentioned?

Thanks for the update. I can hardly imagine what a huge undertaking this is. Looking forward to it.

Hi Matthias,

There is quite a bit of progress on 3.0. What you are seeing are minor issues that we find popping up as we finalize the development of it prior to an internal Alpha. We choose to log every thing that needs to be fixed, big or small, so that we don’t lose track of it or miss something. Early in a larger project it is common to have a small number of issues that take a lot of work, but as we near the final stages, you’ll likely see a number of smaller issues creep up that we find in testing with extensions and in other environments, so we can make sure to address them.

Awesome, thanks!

In 3.0, all refunds (partial and full) create new order records, so yes, that problem is fixed in 3.0 🙂

Another issue is that we actually need an “invoice” for (partial) refunds instead of changing the initial payment. WooCommerce handles that correctly. Is this part of EDD 3.0?

Thanks

@Matthias,

I realize that these tax improvements may not be useful for everyone, but the way that taxes work is directly tied to the new adjustments API built into the brand new orders system, so things like this are critical to making sure compatibility is maintained.

The length that EDD 3.0 has taken is far longer than we had hoped, but as we near the end of the development, we are finalizing very important aspects of the data schemas, which will prevent any major issues with the data going forward after 3.0.

Extensions are our next priority after the alpha is ready, so that we can maintain compatibility for our users.