Overcharging on Ecommerce API if order has discounts

Question

question

jms asked Jul 9, '20 David Marginian Deactivated commented Apr 5, '21

Overcharging on Ecommerce API if order has discounts

HI

We have an overcharging issue with customers when an order is charged for using the e-commerce API if a discount is added to that order.

We use the endpoints to process orders:

OrderPlacing: https://api.clover.com/v3/merchants/{merchantId}/orders
AddDiscount: https://api.clover.com/v3/merchants/{merchantId}/orders/{orderId}/discounts
TokenizedCharge: https://scl.clover.com/v1/orders/{orderId}/pay

A sample request-response for the TokenizedCharge is as follows (sandbox, also happens on live):

Request (note that we are sending the correct value to be charged; refer bill below):

{"amount":515,"currency":"USD","source":"clv_1TSTSQRmMHET7Y1GcwDq7exo"}

Response:

{"id":"SBGP2SEECQ5JW","object":"order","amount":578,"tax_amount":28,"currency":"USD","charge":"RC4CGNHNR46YP","first6":"411111","created":1594282068000,"ref_num":"019100500860","auth_code":"OK5734","items":[{"parent":"1D8RRXCGXYM2J","amount":550,"description":"Chestnut Rose Cassis Tart"}],"source":{"address_line1_check":"unavailable","address_zip":"12345","address_zip_check":"pass","brand":"VISA","exp_month":"12","exp_year":"2020","last4":"1111"},"status":"paid","status_transitions":{"paid":1594282073817}}

Notice that the response amount is higher that the charge request amount.

Also note that the tax amount in the response is incorrect. Even though we don't specify it, when the discount is applied, it gives a wrong value (the tax showing up in clover orders is 25 cents but here it is 28 cents)

This incorrect tax/amount does NOT happen if there is no discounts in the order.

The overcharged scenario is clearly visible in the bill as well:

Please help us figure this issue out.

e-commerce api Taxes Discounts

clover-bill.png (20.1 KiB)

2

10 |2000

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

David Marginian ♦♦ commented · Jul 09, 2020 at 01:16 PM

I just pinged the ecomm team about this.

1 ·

iliaskarim commented · Jul 09, 2020 at 06:09 PM

Thank you for flagging the issue @jms.

1 ·

Welcome to the
Clover Developer Community

Answer 1 · 2020-07-09T15:26:23Z

David Marginian Deactivated answered Jul 9, '20 David Marginian Deactivated commented Aug 19, '20

It looks like this is a bug on our end. I have created an issue for further investigation.

As a workaround, we believe you can specify the order total when creating the order, that way it doesn't have to be computed by ecomm. Please see - https://docs.clover.com/docs/working-with-orders#section-calculating-order-totals for how to calculate the order total.

15

10 |2000

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

jms commented · Jul 10, 2020 at 08:08 AM

We tried your workaround and it worked. Sadly we can't use that solution.

An unpaid order shows up in the clover online dashboard if the total is set (regardless of state) since it automatically goes to OPEN state.

The problem is now merchants can see an order which may not be paid for (say user closes the payment form). Now the merchant will actually go ahead and start preparing the order since paying later when customer comes to collect is also an option.

The result is an unpaid order has been prepared which the user has actually decided not to proceed with.

Do you have any other solution?
Could you please provide an ETA on the actual fix on clover e-commerce API? (this is impacting heavily on our merchants orders who use promo discounts)

0 ·

David Marginian ♦♦ jms commented · Jul 10, 2020 at 08:16 AM

I will get in touch with the ecomm team tomorrow morning and see if they have any additional workarounds.

0 ·

jms David Marginian ♦♦ commented · Jul 12, 2020 at 02:41 PM

Hi @David, a kind reminder on this

0 ·

David Marginian ♦♦ jms commented · Jul 12, 2020 at 03:42 PM

It is being worked I'll probably have an update for you early week.

My understanding is that we have a fix that is in testing. It's just a matter of testing and then determining when the fix will be deployed. Unfortunately we're upgrading our environments later this evening so that may impact the deploy schedule.

0 ·

David Marginian ♦♦ David Marginian ♦♦ commented · Jul 13, 2020 at 07:12 PM

Update: We have a fix and are planning to deploy it in the very near term (hopefully this week).

0 ·

jms David Marginian ♦♦ commented · Jul 16, 2020 at 04:43 AM

Hi @David. Thanks for the Update.

Can we expect the fix to be available in production by EOD Friday?

0 ·

David Marginian ♦♦ jms commented · Jul 16, 2020 at 12:35 PM

Unfortunately, that doesn't look likely. Under normal conditions I believe we would have already had the fix deployed. But, with the server changes earlier this week we are letting things stabilize before introducing changes. All I can tell you is that we're trying to get the fix out and it will be deployed as soon as we release fixes.

0 ·

David Marginian ♦♦ David Marginian ♦♦ commented · Jul 21, 2020 at 03:42 PM

Sorry for the lack of updates. Due to the server updates I described above we are tenatively planning for this fix to rollout the first week of August. We are also performing an analysis to gauge the impact of it.

1 ·

jms David Marginian ♦♦ commented · Aug 04, 2020 at 06:27 AM

Hi David, any specific date for the rollout since it is the first week of August?

0 ·

David Marginian ♦♦ jms commented · Aug 04, 2020 at 12:21 PM

The scheduled date is August 18. Both the discount and service charge fix will be in that deployment.

1 ·

jms David Marginian ♦♦ commented · Aug 19, 2020 at 02:44 AM

Hi David. Just an update on the above fixes. Are they rolled out to production?

0 ·

Show more comments

jms David Marginian ♦♦ commented · Jul 30, 2020 at 06:56 AM

Hi David. As an addition to this problem we also noticed that service charges configured are not accounted for as well. Even though we send a payment request to /v1/orders/ORDERID/pay with the full amount, the actual charged amount is total - serviceCharge and hence the order shows up as partially paid now.

0 ·

David Marginian ♦♦ jms commented · Jul 30, 2020 at 11:39 AM

Thanks jms. I will report this and get information on your about the ETA on the discounts fix.

0 ·

Answer 2 · 2021-04-05T18:31:19Z

a-leafiy answered Apr 5, '21 David Marginian Deactivated commented Apr 5, '21

Hi, I still got this problem when I apply a discount to a ecomm order. The discount does not apply to the total payment.

1

10 |2000

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

David Marginian ♦♦ commented · Apr 05, 2021 at 06:35 PM

The original question is about the method of the discount calculation, not discounts not being applied. If you want some assistance you will need to describe the problem and provide the request you are making and some sample order ids for us to look at. Please do that in a new post as your question doesn't appear to be related to this thread.

0 ·

question