The problem of domain Registrant details

[Kian]

I'm opening this thread to link my feature request (please share/vote it) and discuss about the possible solutions we have to overcome these issues before WHMCS intervention. For simplicity reasons I'm going to post the request here since Feature Request doesn't support formatting.

I've never been a Registrar myself but it seems that some of my customers desperately need two things in WHMCS:

• Specify registrant details when using DomainRegister and DomainTransfer API functions
• WHMCS must preserve registrant details upon order creation to prevent profile changes for existing orders

Both things are equally important and I'm going to show you why.

1. PREVENTING LAWSUITS

This is a serious problem for mid/large size enterprises using WHMCS. Let me explain what I mean with an example. A customer transfers 100 domains and creates the following contact to use as registrant information - Don't worry, I'm using fake details:

Fiorenza Panicucci
TIM S.P.A.
tim@example.com
Via Callicratide 24
Ussel
AO
11024
IT - Italy
+39.03102578690

As you know, it may take some hours/days before all transfers complete. In the meantime the customer updates this contact details like follows:

Fiorenza Panicucci
TIM S.P.A.
fiorenza@example.com <--- CHANGED
Via Callicratide 24
Ussel
AO
11024
IT - Italy
+39.03102578690

Then he proceeds to transfer 100 more domains placing a new order. At this point we have 2 orders each one with 100 domain transfer both linked to the same contact.

We all would would expect WHMCS to process the 1st order using tim@example.com email address and fiorenza@example.com for the 2nd but WHMCS has other plans. Both orders will be processed using fiorenza@example.com email for the simple reason that WHMCS doesn't store registrant data snapshort. The reason why customer placed 2 separate orders was exactly because he wanted use different emails but WHMCS just picks the "live" data.

The consequences of this behaviour are distruptive since customers can update all details anytime (company name, telephone number, address...) with orders that are still in progress causing hundreds of domains to be potentially registered with wrong data on a daily basis. If you have lot of domains this is the worst of your nightmares since:

1. You need to fix all information manually at Registrar level. It can cost you a lot of money to spend for domain trades
2. Domain owners are angry and disappointed. Lawsuits are Just Around the Corner... and they're 100% right!

Please don't think that preventing customers from updating contact details is the solution. It will simply force customers to register an enormous number of contacts just because they need to use a different telephone numbers for specific domains or when they need to register X and Y for their company and W for themself. Not to mention that WHMCS forces email addresses to be unique. Believe me, I have already tried this solution over the years with tens of mid/large sized WHMCS systems and this is a complete nonsense.

Keep in mind that this was just an example. The problem described above can occurr in different ways also with registrations and ironically it gets worse when orders have a small number of domains. On a large scale it makes daily checks close to impossible. Over the years I had customers paying fines or literally buring money for unnecessary domain trades that were super expensive!

2. INTEGRATIONS

This part is less scary but still relevant. I work with customers that have heavily customized systems to the point that no one uses WHMCS cart at all. We're talking about 100% custom-made ordering processes that transmit data to WHMCS via API. The only thing we can't get is to register/transfer domains via API providing registrant information "on the fly". I hope I don't need to explain why this is important. We should have something like follows:

<?

$postData = array(
    'domainid' => '1',
    'registrant_firstname' => 'Mark',
    'registrant_lastname' => 'White',
    'registrant_companyname' => 'Dragon Ltd.',
    'registrant_email' => 'mark@example.com',
    // ... and so on
);

$results = localAPI('DomainRegister', $postData);

----------------------------------------------------------------------------------------

At the moment I can't find any viable way to cope with both needs. All solutions I came up with are impractical. They would require me "deactivate" core features of WHMCS replacing them with my own ones writing an enormous amount of code but I have a life 🙄

 

[Remitur]

19 hours ago, Kian said:

 

We all would would expect WHMCS to process the 1st order using tim@example.com email address and fiorenza@example.com for the 2nd but WHMCS has other plans. Both orders will be processed using fiorenza@example.com email for the simple reason that WHMCS doesn't store registrant data snapshort. The reason why customer placed 2 separate orders was exactly because he wanted use different emails but WHMCS just picks the "live" data.

Hummmm... no. It's not so. That's to say:

• it's not a matter of WHMCS, but it's matter belonging to every single Registry and related Registrars modules
• it's not true that this happen always

Let me explain:

•  for few TLDs a domain transfer ( = change of registrar) includes always a trade (= change of registrant) too, for few others TLDs transfer and trade are different and unrelated operations (so, first you need to complete the transfer, and then you'll be able to to the trade), for few others TLDs both are possible
• an example of the first: .es
  You need to transfer the .es "as is", and when the transfer is complete you'll be able to change registrant data (trade)
• an example of the second: gTLD (.com .net etc.)
  Everytime you start the transfer of a .com, in the very same EPP command you specify the new registrant data too.
• an example of the third: .it
  For .it, you have two different EPP commands: one for "transfer+trade", and the second one for "transfer"
  If you use the first one (transfer+trade), the behaviour is exactly the same as for gTLD.
  If you use the second one, the behaviour is exactly the same as for .es
  But choosing the first or the second is a matter of the registrar module, not of WHMCS...

To make the matter even more complicated, there're few many exceptions:

• .ru
  You can't edit or change registrant data at all
  Registrant data may be modified only by the Registrant himself, working on the registry's site (nic.ru)
• .fr
  Trade (change of registrant) is a paid operation; your user can't change registrant data directly, because he's required to pay fo it

... and so on...

BTW: the problem sometime I meet is exactly opposite to your: customers edit just a contact profile in WHMCS, and then wonder "Why all of my domains (hundreds of them, dozens of different extensions) were not updated accordingly?!?! Your system does not work!!!!!!!" 😀

The fix for both?

Just lock the "edit" feature for contacts profiles. If a user needs a different contact, he will be forced to creat a new one. 

 

Edited January 8, 2020 by Remitur

[Remitur]

16 hours ago, Kian said:

The only thing we can't get is to register/transfer domains via API providing registrant information "on the fly".

You can do it easily using  just two different API commands:

1. AddContact (https://developers.whmcs.com/api-reference/addcontact/) 
2. DomainRegister

With the first one you specify registrant data and create the registrant contact profile

With the second one tou register the domain, specifying the ID of the new contact just created with the previous command.

BTW: this add-on: https://marketplace.whmcs.com/product/1602 is working exactly as you want. But I'm using it, and believe me: when anything is going wrong, it's a nightmare... 😕

 

[namhost]

I have another use case to add that I explain here: 

 

 

In short, our clients have different pricing depending on the registrant. We also have resellers that register domains on behalf of their clients. So the reseller would order a domain, then they must specify their clients details, and then if that client has Country = My Country, then they get a much cheaper price than if they were outside of my country. And this is a rule the registrar as set for this domain, so I have to cater for it.

Will that add on module help me with that too?