Reduce purchase data sent to gateways to give better reliability in gateway totals

[cklosowski]

trafficstars

The Problem Currently, EDD tries to respect every gateway's different data formats to give things like discounts, item amounts, quantities, and taxes.

The most important item there that is problematic is Taxes. Each gateway really handles taxes differently. The risk there is that (as seen below in the Stripe and PayPal examples), our attempt to support taxes ends up with very different totals in the gateways leaving the reporting in the gateway itself inaccurate.

After much discussion in slack between @pippinsplugins @SDavisMedia and @mintplugins, some of these points proved there is a major problem with trying to use all the 'features' of the different gateways when it comes to calculating the item totals:

PayPal:
[...]
The problem arrises, however, when one of our item amounts or discounts has rounding involved.

Take, for example, a $9.99 item with a 75% discount. That discounted amount is 7.4925. EDD _has_ to round this to 7.49 because PayPal will flat out reject the purchase if we send in the real amount of 7.4925.

Typically this is fine until you extrapolate the cart out to 10x items. Over 10x items, that rounding results in a missing penny or two if you add the items together _post_ rounding.
PayPal will not do the rounding for us so we must pass the amounts in after we've rounded them.

Stripe:
[...]
Stripe says "just tell me the total amount you want charged and we're happy"
Super simple
But Stripe also says "**** you" when it comes to taxes
There are two immediate reasons Stripe sucks for taxes.

1. Stripe does not support an explicit amount. It _only_ takes a percentage.
2. Stripe has a feature called "customer balance" that we use to support varying initial and recurring amounts on subscriptions. This is basically just a "store credit" of either positive or negative amounts. PROBLEM: any amount that comes from the customer balance does not get tax applied to it by Stripe
So let's say we have subscription that is a $100 initial purchase then $10 per month. Stripe does not have a way to support this kind of purchase without doing really janky stuff.

EDD has to calculate tax on the $100 but Stripe, unfortunately completely ignores $90 of the $100 and only applies taxes to the $10 monthly. This is because $90 comes out of the customer balance which is, as far as Stripe is concerned, tax free
So at 10% tax, EDD records $10 in tax for the initial payment, but Stripe only records $1

So while we're attempting to accommodate these gateways to send taxes, it really puts us in a spot where we cannot accommodate all the situations fully, meaning that our tax sent to things like Stripe are wholly inaccurate, where they would be accurate in EDD.

Proposed Solution After some discussion, the idea we all agreed to, is to not try and attempt to log tax data at the gateway, and just send the itemized totals for items. While this means that the reporting won't be able to be run at the gateway, it does mean we will have accurate amounts collected at the gateway every time, instead of us having possible calculation totals going to the gateway and shorting/overcharging.

With this, however, we will need to improve our own reporting internally for taxes, which will be far more accurate after the 3.0 tables and reporting APIs are completed.

As a side note, we should still add the ability for the gateway to get taxes via a filter (with inline documentation that throughly explains why we do not do this) allowing some site owners/developers/gateway developers to allow this to occur.

[mintplugins]

Some related issues:

• Taxes are going to being sent to Paypal Express for recurring payments here - this issue will essentially undo that, while keeping the new columns in the edd_subscriptions table for taxes: https://github.com/easydigitaldownloads/edd-recurring/issues/906

• Recurring issue 939 can cause Stripe tax amounts to be incorrect. This issue will essentially bypass/fix that: https://github.com/easydigitaldownloads/edd-recurring/issues/939

• This issue with rounding can cause any number of things to be different at the gateway vs in EDD, which would also (hopefully) be resolved by this issue: https://github.com/easydigitaldownloads/easy-digital-downloads/issues/5879

[mintplugins]

Another thing to consider is not just taxes, but sending anything to the gateway except the total.

This includes not sending:

• Taxes
• Fees
• Discounts
• The list of items purchased

If we send the list of items to the store, the following becomes an issue:

Imagine 2 items at $5 a piece, adding up to $10. With 10% tax it's $10.10

If we send the itemized list to Paypal, the tax amount would have to be reflected inline:

Item 1: $5.05
Item 2: $5.05
__
Total: $10.10

This get dicier if there are discounts or fees as well, especially considering discounts and fees can be cart-wide or in relation to specific items.

If we send only the total ($10.10) to the gateway, it remains much more straightforward, and keeps EDD as "the place to go" for the full data.

Chris mentioned that not sending in the itemized list could prevent you from having seller protection, specifically at Paypal. We'll have to investigate that further to see what the repercussions are.

If there are repercussions, one way around that may be to philosophically consider that the customer bought a "cart" of items, like a "bundle", rather than a list of different products individually.

[mintplugins]

Thinking on this further, I just went to Home Depot and paid with a credit card. I got 2 receipts.

• The Home Depot Receipt with the itemized breakdown, tax, and total
• The visa (actually moneris) receipt with only the total

I believe this reflects the desired outcome for this issue exactly