MODULE-7144 BUG - WHMCS 7.8.3 - 2Checkout - Recurring Payment Only - Discount is being applied twice

[Mechanic]

HI,

In WHMCS 7.8.3 + 2Checkout payment gateway, the discount is being applied twice when a client tries to create a recurring subscription.

This does not happen when they try to make a one off payment.

This can be reproduced by creating a similar invoice under any other client account.

 

[Mechanic]

WHMCS Support acknowledged that this is indeed a bug and they will develop a fix. However, they didn't provide any timeframe for such.

[sufi]

Hello,

Any ETA on this one? Can't upgrade to 7.8.x for this bug!

Thanks.

[WHMCS ChrisD]

Hi @Mechanic and @sufi thanks for your post, I'll check in on this for you and respond soon

[Mechanic]

HI @WHMCS ChrisD Thank you for the response.

 

Seeing no action from your part, we started offering Blesta to our clients, and inspecting HostBill for us, as your lack of action both via support and community hurt our confidence in WHMCS.

I didn't expect your quality of service to take so much downhill. We are stuck with WHMCS for now, but that too might change.

[WHMCS ChrisD]

Hi @sufi a HotFix has now been released for this issue :

 

@Mechanic I'm sorry to hear you feel that way, we do review issues submitted by users frequently and our development team prioritise these, we have now released a hot fix and I will ensure I loop your feedback back to the team.

 

[Mechanic]

On 10/25/2019 at 6:44 AM, WHMCS ChrisD said:

I'm sorry to hear you feel that way, we do review issues submitted by users frequently and our development team prioritise these, we have now released a hot fix and I will ensure I loop your feedback back to the team.

Thank you for the hotfix.

You would expect a bug as important as a payment gateway bug would be fixed as fast as possible. You seem to have aother priorities which speak a volume about your development path. Every other day we see features being developed which nobody wants.

But this is not the only reason for introducing another billing solution to our clients.

You might want to work on how you provide support and bug fixes.

[Mechanic]

@WHMCS ChrisD I just applied the hotfix and it just worsened the issue.

Now the coupon is not being deducted at all.

[RockTBN]

@Mechanic Has it been fixed yet?

[Mechanic]

7 hours ago, RockTBN said:

@Mechanic Has it been fixed yet?

No, the issue hasn't been fixed. The problem reversed actually.

In the past sometimes discount coupons were being deducted twice from the price, now they are not being deducted at all.

I really don't understand why WHMCS was not able to fix the issue. This is just calculation via scripting, not some complex algorithm.

Edited November 12, 2019 by Mechanic

[RockTBN]

11 hours ago, Mechanic said:

No, the issue hasn't been fixed. The problem reversed actually.

In the past sometimes discount coupons were being deducted twice from the price, now they are not being deducted at all.

I really don't understand why WHMCS was not able to fix the issue. This is just calculation via scripting, not some complex algorithm.

Thank you for the information. We will stay with our current 7.7.1 until it's fixed.

This issue should be considered with high priority as a lot of providers like us are using 2Checkout as the main Credit Card gateway.

[Mechanic]

On 11/13/2019 at 10:56 AM, RockTBN said:

This issue should be considered with high priority as a lot of providers like us are using 2Checkout as the main Credit Card gateway.

They are going to release a new WHMCS version within a few days, without fixing this issue.

[Mechanic]

@WHMCS ChrisD Any word whether we would get a fix for this payment gateway bug?

 

It seems you have put aside your development for a new WHMCS version. If a payment gateway bug is not important, which type of WHMCS bug is important to you?

[WHMCS John]

Hi @Mechanic,

I'm pleased to advise this fix has been included in v7.9 which has just entered public beta testing: https://preview.whmcs.com

I encourage you to install the beta, test it out, and make sure you have the desired functionality. We welcome feedback via https://whmcs.community/forum/485-v79-beta-discussion/

 

Quote

MODULE-7144 - Correct promo calculation for 2CO

https://docs.whmcs.com/Changelog:WHMCS_V7.9.0_Beta_1

 

[Mechanic]

 

 

 

 

6 minutes ago, WHMCS John said:

Hi @Mechanic,

I'm pleased to advise this fix has been included in v7.9 which has just entered public beta testing: https://preview.whmcs.com

I encourage you to install the beta, test it out, and make sure you have the desired functionality. We welcome feedback via https://whmcs.community/community/485-v79-beta-discussion/

 

https://docs.whmcs.com/Changelog:WHMCS_V7.9.0_Beta_1

 

 

Have you tested the hotfix or it's a theory that you believe that the issue was fixed after re-writing some code?

Can you state publicly how many transactions WHMCS has performed with the hotfix applied and what are the nature of the line of items of those invoices?

I bet you can't tell because you fixed the issue only in theory, didn't test the hotfix at all.

The hotfix that you applied in v7.9 REVERSED the issue, fixed nothing:

 

You really need a good QA team. As furious and hopeless as I am, seeing your quality of support going so low saddens me. Your entire team should do their homework without quoting from a predefined set of replies.

 

[WHMCS Marcus]

On 11/26/2019 at 3:53 PM, Mechanic said:

 

Have you tested the hotfix or it's a theory that you believe that the issue was fixed after re-writing some code?

Can you state publicly how many transactions WHMCS has performed with the hotfix applied and what are the nature of the line of items of those invoices?

I bet you can't tell because you fixed the issue only in theory, didn't test the hotfix at all.

The hotfix that you applied in v7.9 REVERSED the issue, fixed nothing:

 

You really need a good QA team. As furious and hopeless as I am, seeing your quality of support going so low saddens me. Your entire team should do their homework without quoting from a predefined set of replies.

 

I've attempted to replicate this behavior in version 7.9 of WHMCS but cannot. Are you indicating this behavior is still present for you? I can also confirm that the hotfix linked has resolved this issue in v7.8.3 for my tests as well. I have outlined my replication steps below:

 

1. Install WHMCS Version 7.9 Beta1
2. Navigate to Setup > Payments > Payment Gateways
3. Activate/configure the "2CheckOut" gateway module with the following settings:
   • Checkout Style: Inline Checkout
4. Navigate to Setup > Products/Services > Products/Services
5. Create a new product group
6. Create a new product with the following settings:
   • Details -> Require Domain: False
   • Pricing -> Payment Type: Recurring
   • Pricing -> One Time/Monthly -> Enable: True
   • Pricing -> One Time/Monthly -> Price: 10.00
7. Navigate to Setup > Payments > Promotions
8. Create a new promotion with the following settings:
   • Promotion Code: Test
   • Type: Percentage
   • Recurring -> Enable: True
   • Value: 10.00
   • Applies To: Select all in list
9. Navigate to the cart.php page
10. Click on the "Order Now" button
11. Enter "Test" into the Apply Promo Code field
12. Click on the Validate Code button
13. Click on the Checkout button
14. Fill out the registration form
15. Click on Complete Order
16. Wait for the Inline Checkout modal to pop up
17. CONFIRM: The payment screen prompts for $9.00 as expected.

I have also completed these same steps in v7.8.3 with the linked Hotfix applied and it is also working as expected.

I'm happy to look into this issue further for you, can you please open a ticket with us or PM me your Ticket Number and I'm happy to review your specific case.

[Mechanic]

52 minutes ago, WHMCS Marcus said:

I've attempted to replicate this behavior in version 7.9 of WHMCS but cannot. Are you indicating this behavior is still present for you? I can also confirm that the hotfix linked has resolved this issue in v7.8.3 for my tests as well. I have outlined my replication steps below:

 

1. Install WHMCS Version 7.9 Beta1
2. Navigate to Setup > Payments > Payment Gateways
3. Activate/configure the "2CheckOut" gateway module with the following settings:
   • Checkout Style: Inline Checkout
4. Navigate to Setup > Products/Services > Products/Services
5. Create a new product group
6. Create a new product with the following settings:
   • Details -> Require Domain: False
   • Pricing -> Payment Type: Recurring
   • Pricing -> One Time/Monthly -> Enable: True
   • Pricing -> One Time/Monthly -> Price: 10.00
7. Navigate to Setup > Payments > Promotions
8. Create a new promotion with the following settings:
   • Promotion Code: Test
   • Type: Percentage
   • Recurring -> Enable: True
   • Value: 10.00
   • Applies To: Select all in list
9. Navigate to the cart.php page
10. Click on the "Order Now" button
11. Enter "Test" into the Apply Promo Code field
12. Click on the Validate Code button
13. Click on the Checkout button
14. Fill out the registration form
15. Click on Complete Order
16. Wait for the Inline Checkout modal to pop up
17. CONFIRM: The payment screen prompts for $9.00 as expected.

I have also completed these same steps in v7.8.3 with the linked Hotfix applied and it is also working as expected.

I'm happy to look into this issue further for you, can you please open a ticket with us or PM me your Ticket Number and I'm happy to review your specific case.

Thank you for your reply. I had several tickets open with you, my comment on the support quality was based on those tickets.

I appreciate that you are trying to help. Though a single test cannot tell whether a hotfix works or not.

I can give you a lot of scenarios where the hotfix failed. These hotfix files are integrated into v7.9, so it is too, bound to fail.

1. The issue appears randomly, with random symptoms, seemingly only for recurring services.

2. Create a renewal invoice (currency: USD) for an existing product.

3. The renewal date should be in the future.

4. Edit the invoice and include the following line items:

anything 14.26

anything -4.28

5. The invoice total should now be 9.98

6. Log in as a client, or via the link from the client profile

7. Click on "Create Automated Recurring Subscription" and you will see the amount shown is 9.20

8. Close the popup

9. Click on "Make One Off Payment", you will see the amount shown is 9.98

This was when I tried to replicate an issue of a client invoice. The second line item was a 30% recurring discount code, and the first line item was a monthly reseller hosting service. But you don't need to enter anything more than "anything".

The client faced a different issue on their invoice. Instead of paying 9.98 or 9.20, they paid 14.26 which means the discount was never deducted while WHMCS passed the values to 2CO.

Again, these issues do not appear on all invoices, but they do appear frequently enough to lose clients.

 

 

 

 

 

[WHMCS John]

Hi @Mechanic,

Thank you for providing that detail, this is a slightly different issue to the one originally reported.

The Recurring Amount value sent to 2Checkout is based upon the service's Recurring Amount. So in this scenario, you'd need to ensure the appropriate promotional discount is applied to the service record (via the client's Products/Services tab) as well as modifying the invoice.

This is necessary because recurring payments in 2Checkout require a "product" to be created in their panel with the details of the service the client has purchased. As the 2Checkout product record is analogous with the service, the payment amount values are sourced from the WHMCS service record.

As a result modifying the invoice directly is sufficient for one-time payments which are based purely off the invoice values, but recurring payments also require the service to be modified.

 

I trust that clarifies this scenario. If I can be of any further assistance, please don't hesitate to get back in touch via your support ticket.

[Mechanic]

Hi @WHMCS John

 

 

 

1

On 11/28/2019 at 4:35 PM, WHMCS John said:

The Recurring Amount value sent to 2Checkout is based upon the service's Recurring Amount. So in this scenario, you'd need to ensure the appropriate promotional discount is applied to the service record (via the client's Products/Services tab) as well as modifying the invoice.

This is necessary because recurring payments in 2Checkout require a "product" to be created in their panel with the details of the service the client has purchased. As the 2Checkout product record is analogous with the service, the payment amount values are sourced from the WHMCS service record.

As a result modifying the invoice directly is sufficient for one-time payments which are based purely off the invoice values, but recurring payments also require the service to be modified.

Are you suggesting that a manual edit in the "Recurring Amount" filed in the client's Products/Services?

WHMCS automatically calculates and updates this value once an order is placed, is it not?

Today, the issue occurred multiple times. all with the same behavior I will provide details of two new orders, not recurring:

01.

The client ordered a Reseller Hosting, prorated on the 1st.
Added an Addon.
A 40% recurring discount was applied with coupon.
Ordered for three years.
Regular price for 3 years is: 2486.25

On the Product Details page:

First Payment Amount: 1834.39
Recurring Amount: 1491.75

Invoice:

Reseller Hosting: (protated: 29/11/2019 - 31/10/2022) 2424.95
40% Recurring Discount -969.98
Addon 379.42
Invoice Total: 1,834.39

When they click on "Create Automated Recurring Subscription", they see 1871.17
When they click on "Make One Off Payment", they see 2804.37

I lost this first client.

02.

The client ordered a Reseller Hosting2, prorated on the 1st.
A 40% recurring discount was applied with coupon.
Ordered for Quarterly.
Regular price for Quarterly is: 50.59

On the Product Details page:

First Payment Amount: 21.11
Recurring Amount: 30.35

Invoice:

Reseller Hosting2: (protated: 29/11/2019 - 31/01/2020) 35.19
40% Recurring Discount -14.08
Invoice Total: 21.11

When they click on "Create Automated Recurring Subscription", they see 30.35 on the credit card tab, when they go to PayPal, PayPal payment page shows: 35.19
When they click on "Make One Off Payment", they see 35.19

Had to create a custom invoice for them to pay.

So, how do you explain the logic behind these? Is this normal for a billing application to behave and you are still calling it a fix?

 

[Mechanic]

Hi @WHMCS John

I am still waiting for your reply.

Do you still think these behaviors are normal for WHMCS?

[WHMCS John]

Hi @Mechanic,

Thanks for providing that detail, I've been able to reproduce the issue; a recurring discount on a proforma product paying via 2CO Inline mode seems to be the cause.

I've now opened case # MODULE-7206 with our developers in order to have this reviewed for future releases. Once we resolve cases and push features they are available at our change log, here:

https://changelog.whmcs.com/

In the meantime, switching to the Standard Checkout mode in the 2Checkout settings of the Payment Gateways page within WHMCS appears to be calculated correctly.

 

I apologize for the inconvenience, and appreciate your patience as we work to resolve this.

Thanks again for taking the time to report your findings. We welcome bug reports at https://bugs.whmcs.com/

[Mechanic]

Hi @WHMCS John

In addition to that, there might be another bug.

I just switched to Standard mode from Inline but all of the invoices are showing the Inline mode. I have cleared the template cache and used a different browser. All the same.

[WHMCS John]

Hi @Mechanic,

I placed a new order and I was taken to the Standard Checkout order page (attachment 1)

I did notice that if I first tried paying an invoice via Inline, switched to Standard Checkout, then went to pay again, I saw an inline-style checkout page (attachment 2)

WHMCS is redirecting correctly to https://www.2checkout.com/checkout/purchase but it it seems 2Checkout choose to display an inline-type checkout in that case. If I had to speculate it might be because the product records were already created at 2CO during the first payment attempt in Inline mode, so they maybe have some logic to display a different inline-style checkout page in that case?

 

[Mechanic]

11 minutes ago, WHMCS John said:

WHMCS is redirecting correctly to https://www.2checkout.com/checkout/purchase but it it seems 2Checkout choose to display an inline-type checkout in that case. If I had to speculate it might be because the product records were already created at 2CO during the first payment attempt in Inline mode, so they maybe have some logic to display a different inline-style checkout page in that case.

Hi John,

Thank you for investigating this. I don't see any products created under my 2checkout account after replicating this behavior. If you confirm that it is something for 2Checkout to look into, I will contact them to look into the issue.

Could you speed up a hotfix for # MODULE-7206 (the original issue) and make sure it is thoroughly checked by WHMCS, not the beta testers so that there are fewer chances to cause any new bug?

It is a payment gateway bug after all and doesn't deserve to wait until a new version releases.

[Mechanic]

Hi @WHMCS John

Any update on fixing this issue?