The Recurring Payments extension is getting a major update in version 2.8 with some significant fixes. Most notably, taxes on subscriptions are now being logged in the subscriptions table in 4 new columns:
- initial_tax_rate – storing the tax rate from the initial purchase in the subscription
- initial_tax – storing the tax amount from the initial purchase in the subscription
- recurring_tax_rate – storing the recurring tax rate, which will be used for all recurs in this subscription
- recurring_tax – storing the recurring tax amount, which will be used for all recurs in this subscription
These 4 columns are important because the initial amount and tax rate may not match the recurring amount. For example, if you have a free trial for your products enabled, the initial tax amount will be $0. But for subsequent recurs, that amount can be different.
It is also important to note that in version 2.8, taxes, discounts/coupons, and fees are no longer sent separately to the payment gateway. All calculations that modify the final price for recurring products are now done solely in EDD Recurring Payments and Easy Digital Downloads core.
Previous to version 2.8, taxes/discounts/fees were sent to the gateway as separate amounts and the gateway would redo its own calculations on the total. The problem with this was that it could result in different amounts, even by a single cent. A lot of this has to do with the fact that Stripe and PayPal handle rounding extremely long numbers differently. The end result was that the numbers could be slightly off at the gateway vs what they were in the EDD payment record. Now, by doing the math only in EDD and sending just the total to the payment gateway, there will only be a single set of numbers, and no possibility of duplicate math.
It is advisable that you use the EDD’s payment history for accounting and reporting purposes going forward, as opposed to using the taxation/discount/fee numbers provided by the payment gateway. Those additional amounts/breakdowns are no longer sent to the gateway, so they will no longer exist there.
During the alpha stage of the 2.8 release, our team tested over 196 unique checkout scenarios related to this change. All of these scenarios are created by combinations of possible settings in Easy Digital Downloads, especially when used alongside Software Licensing, and also when discount codes come into play. Between free trials, discounts codes, renewal discounts (from Software Licensing), taxes being entered both inclusive and exclusive of tax, and the combinations of all of the above, we believe we have accounted for and tested almost all possible situations that may arise.
If you are running Recurring Payments alongside Software Licensing, it is a good idea to run this beta version on your staging server and running a few test purchases to ensure you get the results you expect. This applies especially if you have custom code anywhere on your site that affects Recurring Payments in any way. Once you have confirmed that your test purchases go through as you expect them to, then it is advisable to update to the 2.8 release when it becomes available on your live site.
We will be leaving version 2.8 in beta for at least 2 weeks before full release to allow time for beta testing.
Additional fixes included in the 2.8 release:
Fixed Content Restriction Integrations
If you use the Content Restriction extension alongside Recurring Payments, you might be using the “Require active subscription” option to revoke a subscriber’s access to restricted content if their subscription expires. There was an edge case for people who required either a recurring product OR a non recurring product. Recurring Payments was doing too good of a job at requiring active subscriptions, even on products that weren’t recurring-enabled. That is now fixed in version 2.8, and you can restrict a product to both a recurring product or a non recurring product at the same time. An example of this would be if you sold yearly or lifetime packages. The yearly package is recurring enabled (yearly), but the lifetime package is not recurring. Therefore, lifetime purchasers would not have a subscription, and therefore they would not have access. This was the most common use-case for this. That is now resolved in version 2.8 so that the lifetime, non-subscription products also give access, while still requiring active subscriptions for products that are recurring-enabled.
Fixed re-activating subscriptions from the customer account
Another issue that has been resolved in 2.8 is re-activating subscriptions from the customer’s account dashboard, which is provided by the [edd_subscriptions] shortcode. The customer could not re-activate their subscription at Stripe. This was due to an API change made on Stripe’s end, which we have now adjusted and accounted for.
Prevented free trials from being incorrectly applied
If a customer on your site had 2 products in their cart, one of which had a free trial, and the other did not, a free trial was getting applied to both. That bug has also been resolved in version 2.8. Products with free trials and products without free trials can no longer be purchased at the same time. If attempted by a customer, they will receive an error stating “Error: Free trials and non-trials may not be purchased at the same time. Please purchase each separately.”
Resolved multi-currency issue
If you have a custom integration with EDD that charges customers in a different currency than your default currency for your shop, there were previously issues with
the Paypal Pro/Express gateways in that it expected the currency to match the store’s default currency instead of using the unique payment record’s currency. That has now been resolved.
Search results on the Subscriptions page
When searching through your subscriptions in the admin dashboard, the number of found posts always reflected the total number of subscriptions, as opposed to showing the number found in your search query. That has now been resolved.
PayPal eChecks with subscriptions
If a person chose to buy a subscription and paid with an eCheck, previously those payments were not labelled with the “eCheck” label. Those now have code in place to be handled and labelled correctly.
This sounds really good. Hope it will solve our problems with more than 40 incorrect invoices from older recurring payments.
But I have one big question, how do you handle older recurring payments, where the four fields (initial_tax_rate, initial_tax, recurring_tax_rate and recurring_tax) weren’t set and data is already sent to the payment gateways?
Did you also think about the possibility that states change their VAT rates or in the case of the UK that after the brexit there is not need for charge with VAT anymore?
There is an upgrade routine that gets run after the update is installed that will go through every subscription record and populate those fields. Once the upgrade routine is finished (can take a while), all subscription records will show the initial and recurring tax amounts.
We haven’t yet added a way to disable taxes on existing subscriptions (for future renewal payments) but that may be something we can add in the future.
Hi Pippin,
Will this work with the EU VAT plugin you recommend on your Tax Settings page? I’m talking about this one here: http://www.wproute.com/2013/10/vat-for-edd/
I don’t think there should be any problem, but taxes are such a complicated part, I just want to be sure everything will be OK.
Yes that should work perfectly fine!
Tax rate changes or expired VAT numbers (customer no longer being eligible for VAT exemption but subscription being registered without any tax) are a quite a headache for us now, so I hope this will also open up doors for more flexibibility in that area. There are two scenarios here:
1) Total amount (on the payment processor end) does not change, but taxes and thus the net amount do, resulting in higher or lower margin for the merchant (currently the only way to do this, manually)
2) Total amount is adjusted before renewal to reflect latest tax settings. I imagine this is much more complex as it would require triggering a change right _before_ the actual renewal and I don’t know if this is supported by all payment processors…
Having 1) automated would already help tremendously though!