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.