[unconfirmed] Wrong SSL certificate purchased -- only with automated provisioning

[rocksfrow]

===========DESCRIPTION===========

SSL Certificate orders are submitting the wrong enom ssl module item when automatically provisioned, but work fine when manually approved/provisioned.

 

The product is configured with the eNom SSL module. It's configured with the rapidssl certificate. Without any other modifications to the product, the 'rapidssl' order will submit to enom ssl incorrectly if automated.

 

=========STEPS TO REPLICATE=========

- Create a 'other' product

- Configure to use 'enom ssl' module

- Select 'certificate rapidssl' from the product choices and fill out module login information

- Choose 'automatically provision/module create after first payment received'

- Place an order for the product

 

Expected Result: rapid ssl certificate purchased

 

Actual Resut: comodo essential certificate purchased

 

=======ADDITIONAL INFORMATION======

The incorrect item automatically added via enom ssl module (when automated):

 

Array
(
   [uid] => *********
   [pw] => ***********
   [ProductType] => certificate-comodo-essential
   [Quantity] => 1
   [ClearItems] => yes
   [command] => AddToCart
   [ResponseType] => XML
)

 

The correct item automatically added via enom ssl module (when approving manually):

 

Array
(
   [uid] => *********
   [pw] => ***********
   [ProductType] => certificate-rapidssl-rapidssl
   [Quantity] => 1
   [ClearItems] => yes
   [command] => AddToCart
   [ResponseType] => XML
)

 

Zero changes are being made to the product itself, nor the product module configuration.

 

Until this bug is confirmed/resolved, I have reverted the product back to manual configuration.

 

Thanks!

Edited January 19, 2014 by rocksfrow
Conforming to post guidelines.

[rocksfrow]

===========DESCRIPTION===========

SSL Certificate orders are submitting the wrong enom ssl module item when automatically provisioned, but work fine when manually approved/provisioned.

 

The product is configured with the eNom SSL module. It's configured with the rapidssl certificate. Without any other modifications to the product, the 'rapidssl' order will submit to enom ssl incorrectly if automated.

 

=========STEPS TO REPLICATE=========

- Create a 'other' product

- Configure to use 'enom ssl' module

- Select 'certificate rapidssl' from the product choices and fill out module login information

- Choose 'automatically provision/module create after first payment received'

- Place an order for the product

 

Expected Result: rapid ssl certificate purchased

 

Actual Resut: comodo essential certificate purchased

 

=======ADDITIONAL INFORMATION======

The incorrect item automatically added via enom ssl module (when automated):

 

Array
(
   [uid] => *********
   [pw] => ***********
   [ProductType] => certificate-comodo-essential
   [Quantity] => 1
   [ClearItems] => yes
   [command] => AddToCart
   [ResponseType] => XML
)

 

The correct item automatically added via enom ssl module (when approving manually):

 

Array
(
   [uid] => *********
   [pw] => ***********
   [ProductType] => certificate-rapidssl-rapidssl
   [Quantity] => 1
   [ClearItems] => yes
   [command] => AddToCart
   [ResponseType] => XML
)

 

Zero changes are being made to the product itself, nor the product module configuration.

 

Until this bug is confirmed/resolved, I have reverted the product back to manual configuration.

 

Thanks!

Edited January 20, 2014 by rocksfrow
removed note to mods

[WHMCS Nate]

Hello,

 

I have not been able to reproduce your issue. Each time I order it requests the rapidssl. Can you open a support ticket so our support team can investigate this further and see if there are additional details required to reproduce this issue in your case?

 

Thanks for your report,

 

Nate C

[rocksfrow]

Nate,

 

You didn't order it manually, right? Manual ordering works fine.. it's automated ordering that orders the wrong item. I just want to make sure tested with *automatic* provisioning after purchase, as manually approving/provisioning works as expected the bug only exists when configured to automatically provision after 1st payment is received.

 

Please confirm. I will open a support ticket after you confirm this is the case because I'm shocked you cannot reproduce.

 

Question: in the product you are testing, is it configured as 'Other' item type? What field is the value of the domain populating into? I noticed that for my configuration, the domain name is actually populated in a CUSTOM field, not the default 'domain' field. Perhaps the domain value not being in there is triggering a bug in the API ordering the wrong item.