question

The real problem occurs when we use the values calculated in the former scenario in a clover e-commerce payment. Even though we charge the proper total, the order shows up as partially paid since clover internally recalculates and arrives at some totals that reflect the latter scenario.

Can you expand on this? What APIs are you using? The order/pay endpoint shouldn't be calculating totals unless you haven't set a total on the order.

Can you provide an example order and what you believe the total should be?

Your description of how a fixed amount order level discount is applied seems inaccurate. The key to computing the total when you have an order level discount that is a flat fee is converting it into a percentage. That is done by taking the pre-tax subtotal and dividing the tax amount from it. Let's say we have an order with two 10$ items, one with a 10% tax rate and the other with a 5% tax rate. The pre-tax subtotal is 20 the tax is 1.50 (10*0.1 + 10*0.05) and the total is 21.50. Now if we add an order level discount of 2.00 the discount % is calculated as 2 / 20 (discount / pre-tax subtotal) or .1 (this is the same as a 10% discount). The subtotal is 20, the tax is 1.35 ($10*0.9*0.1 + $10*0.9*0.05, the .9 is 1 - the discount %). The total for this order would be 19.35 (20 - 2 + 1.35). If there was another item (1.50, delivery charge) the pretax subtotal would be 21.50, the new discount % would be .906976744 (1 - .093023256) and the tax would be 1.36 (round($10*0.906976744*0.1) + round($10*0.906976744*0.05) + round(1.50*0.906976744*0)) and the total would be 21.50 + 1.36 - 2 = 20.86.

I know that this is convoluted but we are thinking to implement this as below.

Number of Items	Description	             Rate
1	              Item A @10.99	    10.99
2	              Item B @6.78	    13.56
1	              Item C @10.00	    10.00
 	                           Discount -5.00
 	                           Delivery  3.00
                                     Total  32.55
 	                           Tax 6%    1.95
 	                        Sub Total   34.50
                                      Tip    2.50
 	                      Grand Total   37.00

The first item is 10.99, the second is 6.78 and the third is 10. The discount is 5 on all items but not on delivery and tip. The tax is 6%. The subtotal is 34.50 and tip without tax is 2.5 and the grand total is 37.00

Now, as clover does the tax on each line item, doing a discount is problematic as it will apply to the delivery as well and we can not have a discount on delivery.

A possible solution to the above is:

Calculate the total number of items - which is 4 in our case (do not include line-item delivery). Then, calculate the discount per item - which is 1.25 in our case (5/4). Now, subtract 1.25 from first, 2.5 from second, and 1.25 from 3rd line items.

Delivery is taxable in most states and we will include this as a line item.

The modified table will look like.

Number of Items	Description	                Rate
1	              Item A @9.74 (Orig 10.99)	 9.74
2	              Item B @5.53 (Orig 6.78)	11.06
1	              Item C @8.75 (Orig 10.00)	 8.75
 	                            Delivery	   3.00
 	                                 Total	32.55
 	                                  Tax 6%	1.95
 	                                   Tip	2.50
 	                           Grand Total	37.00

In this case, the total will not change and we will still have delivery line items that will not get reduced due to the discount. The tip will not get taxed unless we specify it as Clover allows it to be taxed or not taxed.

Then, we should add a line somewhere in the receipt which will say that your saved 5 on this order due to a discount.

Now, the key here is to show the original and discounted price for each line item in the description to make it clear that we applied the discount on the price so that there is no confusion otherwise people will start a quarrel that where is the discount.

The right thing is for Clover to come up with a new API that does it correctly instead of the above-convoluted solution.

There's a hacky way around this that works most of the time if you don't require service charges elsewhere and don't mind making a couple of queries. Imagine the following order:

itemA: $10

discount: : $1.50

deliveryCharge: $2

tax: 10%

First GET the `/default_service_charge` so you can fetah the $serviceChargeId

Then POST to `/orders/:orderId/service_charge` with:

{
"id": $serviceChargeId,
"name": "whateveryoulike",
"percentageDecimal": ( deliveryCharge/ (itemA - discount) ) * 1000000
}

This gets into difficulty with small orders or large discounts as the % service charge cannot be more than 100% of the post discount total. This approach ends up adding a non revenue charge that doesn't affect tax or discounts which is pretty useful and (I believe) the proper way of handling a delivery fee.

NB: my multiplier might be slightly off, basically trying to get 23.5294% of 8.5 which equals the required deliveryCharge of $2.

We used a Custom Line Item to pass the Delivery Fee.
But then we came across another issue.

When the Label printer is used to automatically print out the Line Items when an order is placed, 'Delivery Fee' is also printed out as a Label.
Is there any way to avoid this from happening?