Make sure the subtotal on recurring orders is the price excluding tax

[ideadude]

A user has reported that recurring payments with Stripe have orders created with subtotals that include the VAT price.

From the user:

The order for the initial payment went through as anticipated – £10 subscription + £2 tax = £12. The subtotal field and tax fields were completed correctly. We did notice that the recurring payment on the Edit User was reported as £10 – the no-VAT figure. The next payment came through at £12, which is correct. Looking at the order detail, the subtotal is reported as £12 and the tax as £2.40, with a total of £12.

The new order should have a subtotal of £10, a tax value of £2, and total of £12.

[floshontay]

Any news on this? In my case the total amount for recurring orders is calculated correctly as e.g. 36 but the tax is reported as 0 and the subtotal as 36 (should be 30 subtotal, 6 tax).

[ideadude]

Confirmed that this happens in Braintree recurring orders. Probably happens with Stripe orders as well.

Because we aren't sending the tax amount to the gateway, they don't send it back to us in the recurring orders.

So when the webhook handler runs and processes the order, the $order->tax amount is not set.

The $order->saveOrder method checks if ! isset( $order->tax ) and if so sets it using the getTax method. That method uses the pmpro_tax filter. And the VAT Tax add on filters that to set the tax.

We can either:

1. Quick Fix: Set the $order->tax to 0 instead of null in the webhook handlers. This will keep the tax from being added to the order and adjusting the total. Pro: the total amount is accurate. Con: the order doesn't include the tax breakdown.

or

2. Better Fix: Figure out when tax is involved (even though the Gateway doesn't know about it) and back out the tax amount from the total. We can check the first order for the same subscription ID to see if there was tax on that order and if the amounts line up. If so, copy the tax/subtotal/total from the old order. Need to figure out which filter to use to do that or if we need new filters.

Hope to have a solution for this soon.

[ideadude]

This commit on the core PMPro plugin should avoid the tax being added to the order total twice on recurring orders: https://github.com/strangerstudios/paid-memberships-pro/commit/19dda880bed80548a955cb1f4eaed076ce50e6bc

I am still working on the 2nd (better) fix.

[ideadude]

Working on the "better fix". Some notes.

• PMPRO CORE: Should we create a method on the MemberOrder class to get the oldest order for the same subscription transaction id. get_original_subscription_order?

• PMPRO CORE: Should we build a way to detect when we are in a webhook generally and specifically which gateway? Add function pmpro_in_webhook( $gateway ) that checks if the global $pmpro_in_webhook is set to that specific gateway or set at all if no gateway is passed in. The webhooks would set a global var to the current gateway. Could use a constant instead, similar to the DOING_AJAX constant. And we should probably mirror that pattern.

• PMPRO VAT TAX: Add a function to easily pull just the vat tax info out of the notes.

• PMPRO VAT TAX: Check here (https://github.com/strangerstudios/pmpro-vat-tax/blob/master/pmpro-vat-tax.php#L580) if PMPRO_DOING_WEBHOOK and if so, look for the original subscription order using the new method, and get the VAT TAX info and add it to the new order notes. Also, calculate the tax amount and update that in the order through a new DB query.

• PMPRO VAT TAX: Calculating the tax amount from the total and tax rate. Divide the total by 1 + the tax rate.