Domain registration contact info override using PreDomainRegister?

[RobertOCC]

We just have a quick question for a possible custom development for WHMCS.

When a user registers a domain via WHMCS, it uses the client information for the domain's registrant information (WHOIS).
Is it possible we override those info with our own? More particularly for the email address?

We are looking at the "PreDomainRegister" hook but can't find any sample codes on how to use it relating to what we need.

Any help is appreciated.

Thanks!

[steven99]

PreDomainRegister doesn't support a return, so within that hook you would have to update the domain's contacts via database calls or via modal or API, but not sure those will work if the domain is not yet registered.   For example, the Domain modal has functions to update the email address.  There is an API to update whois info but that expects a XML and would presume it expects to send to a registrar at that point. 

[brian!]

and also it's potentially a very dodgy thing to do... I buy a domain from your site, assume that it's going to be registered with my email address... then find out that it isn't, it's been registered to your email address and thus I cannot transfer or sell it.

[RobertOCC]

On 2/14/2019 at 7:58 AM, steven99 said:

PreDomainRegister doesn't support a return, so within that hook you would have to update the domain's contacts via database calls or via modal or API, but not sure those will work if the domain is not yet registered.   For example, the Domain modal has functions to update the email address.  There is an API to update whois info but that expects a XML and would presume it expects to send to a registrar at that point. 

The reason why we want to update the WHOIS info upon domain registration is to send the contact info (email mainly) the first time it was submitted to the registrar (in our case, Enom). This is because we want to receive the domain verification info ourselves - so we can verify the domain on their behalf.

I believe you are referring to the DomainUpdateWhoisInfo - but I don't think that will work since that is only for updating. At that point, the contact info has already been submitted, and domain verification email already initiated.

[RobertOCC]

On 2/14/2019 at 11:04 PM, brian! said:

and also it's potentially a very dodgy thing to do... I buy a domain from your site, assume that it's going to be registered with my email address... then find out that it isn't, it's been registered to your email address and thus I cannot transfer or sell it.

That's okay, and I don't think our customer won't mind. We also have our own flexible process of transferring domains to another registrant, and we normally do it for them. It shouldn't be an issue.

[Remitur]

23 hours ago, RobertOCC said:

The reason why we want to update the WHOIS info upon domain registration is to send the contact info (email mainly) the first time it was submitted to the registrar (in our case, Enom). This is because we want to receive the domain verification info ourselves - so we can verify the domain on their behalf.

Very, very, very bad idea...

So, you confirm your email address instead of the email address of Registrant, isn't it?

Well, but later you need to update registrant data, and modify your email address setting the right address of your customer, isn't it?

And when you do so, according to ICANN rules you get:

• a double email confirmation request  (one to your address, and one to the address of your customer)
• a sixty-days lock on the domain
• a confused customer who is wondering why the registry is asking him a confirm about something he's not fully understanding

 

 

[RobertOCC]

18 hours ago, Remitur said:

 Well, but later you need to update registrant data, and modify your email address setting the right address of your customer, isn't it?

 

thanks for your reply. the idea is we won't be updating the registrant data or email address to the customer's email, it will stay with our email address indefinitely or unless the customer specifically asks for it (which rarely happens to us). idea is we will be fully managing their domain, and we'll take care of the domain technicalities. but definitely we will not be holding their domain if they want to transfer. we will help them in the transfer process in fact, if they want to move.

so this won't be an issue for the "double email confirmation request".

[RobertOCC]

Still trying to figure this out. 😞 Any ideas guys?

[Evolve Web Hosting]

On 11/15/2019 at 2:14 AM, RobertOCC said:

thanks for your reply. the idea is we won't be updating the registrant data or email address to the customer's email, it will stay with our email address indefinitely or unless the customer specifically asks for it (which rarely happens to us). idea is we will be fully managing their domain, and we'll take care of the domain technicalities. but definitely we will not be holding their domain if they want to transfer. we will help them in the transfer process in fact, if they want to move.

so this won't be an issue for the "double email confirmation request".

That is really bad practice for you to act as their domain registrar yet the entire domain is in your name. I see other businesses do this too and I cringe. It's the customers domain and not someone elses so just update the technical contact and leave the other Whois information alone.

Edited December 27, 2019 by EvolveWebHosting

[Kian]

Overriding registrant information via API is crucial and should be added to WHMCS.

For example I'm redesigning from scratch the entire ordering process of domains and you can't imagine the importance of overriding data via API. At the moment I wasted almost two months trying to find a workaround with no success.

In my case I need to override registrant information to overcome an issue caused by WHMCS. Let me explain. Let's suppose that a customer transfers 1000 domains all registered to contact Bob White. Before transfers complete (it may take some days) the customer updates contact information from Bob White to Bob Black and transfers 500 domain in a different order.

At this point I would expect WHMCS to transfer 1000 domains for Bob White and 500 for Bob Black but sadly it processes all the involved domains so that they're registered to Bob Black.

The reason why it happens is that WHMCS does not "snapshot" contact details. It simply stores contact ID and doesn't care about the fact that contact details have been updated. When you have lot of domains it can easily lead to lawsuits. I mean you are basically ignoring what your customer ordered.

In conclusion we need this feature like air.

 

Edited December 28, 2019 by Kian

[Evolve Web Hosting]

I'm on board with the 'snapshot' so that Whois details aren't changed during the transfer. We've run into that too where the customer may have 1 phone number in WHMCS and another associated with Whois, as an example and it gets changed. Defaulting to the receiving registrars contact info isn't something I agree with. @RobertOCC makes mention of having them default to his own email address / contact info if I'm reading it all correctly.

[steven99]

34 minutes ago, Kian said:

At this point I would expect WHMCS to transfer 1000 domains for Bob White and 500 for Bob Black but sadly it processes all the involved domains so that they're registered to Bob Black.

Not quite sure I follow you here.  If they are different orders, then the 1000 tagged to Bob White should stay as that and the next order for contact Bob Black should be set to that and not the total 1500 . .

At any rate, it sounds like your own registrar module is in order to get the functionality that you and @RobertOCC want.   Or one option would be to use PreRegistrarSaveContactDetails, check if a session variable is set and if not, set it and then run DomainUpdateWhoisInfo API with the info you want, and then return array('abortWithSuccess'=>true).   It will run that PreRegistrarSaveContactDetails hook again and with the checking of the session variable there, it wont go in to a infinite loop.  And in this second hook firing, you have no return.   Have not tested it though but should work. 

[Kian]

7 hours ago, steven99 said:

Not quite sure I follow you here.  If they are different orders, then the 1000 tagged to Bob White should stay as that and the next order for contact Bob Black should be set to that and not the total 1500 .

The contact is the same. I simply updated last name from White to Black. It would have been the same with address, phonenumber, companyname, state, taxid etc. This is is something that happens on a daily basis if you have a lot of domains.

[RobertOCC]

On 12/28/2019 at 5:47 AM, EvolveWebHosting said:

That is really bad practice for you to act as their domain registrar yet the entire domain is in your name. I see other businesses do this too and I cringe. It's the customers domain and not someone elses so just update the technical contact and leave the other Whois information alone.

Our customers are not like that. Believe me they would consider this as a favor. 🙂

The idea is to get the domain verification email so we can verify it on their behalf. Just updating the technical info won't address that issue I believe.

Also, we don't want our customers to receive these emails as it will likely just confuse them. Again, have faith on me on this - our customers would like this.

[RobertOCC]

On 12/28/2019 at 9:45 AM, steven99 said:

Not quite sure I follow you here.  If they are different orders, then the 1000 tagged to Bob White should stay as that and the next order for contact Bob Black should be set to that and not the total 1500 . .

 At any rate, it sounds like your own registrar module is in order to get the functionality that you and @RobertOCC want.   Or one option would be to use PreRegistrarSaveContactDetails, check if a session variable is set and if not, set it and then run DomainUpdateWhoisInfo API with the info you want, and then return array('abortWithSuccess'=>true).   It will run that PreRegistrarSaveContactDetails hook again and with the checking of the session variable there, it wont go in to a infinite loop.  And in this second hook firing, you have no return.   Have not tested it though but should work. 

thanks for the suggestion. my problem with this is that this would mean creating a totally new domain order code logic to accommodate the requirement? is that correct.

what I was expecting is just a hook that will just override some date in the default domain order process. 

[Kian]

1 minute ago, RobertOCC said:

what I was expecting is just a hook that will just override some date in the default domain order process. 

There's no such a thing in WHMCS.

It took me weeks to find a workaround followed by months of frustration while coding but I gave up. I'd rather kiss the ugliest camel in the world.

[RobertOCC]

I really wish there is an API for this. We are using ENOM as registrant - anybody knows how to communicate with your registrant info from WHMSC via custom code for example?

[Kian]

There's still no way. Months ago I opened a feature request for this problem but there are only 2 upvotes. It's hilarious if you consider that this is a huge problem. In the meantime a feature request about an icon receives all the attention of WHMCS community and staff. That's why I dislike rating-based systems.

Edited June 30, 2020 by Kian

[brian!]

4 minutes ago, Kian said:

Months ago I opened a feature request for this problem but there are only 2 upvotes.

it's only been five months - give it until the Olympics after next and check again.  ⏳

5 minutes ago, Kian said:

It's hilarious if you consider that this is a huge problem. In the meantime a feature request about an icon receives all the attention of WHMCS community and staff. That's why I dislike rating-based systems.

one prolific beta tester is hardly the community... how many users are actually testing the app? double figures at best I suspect.

besides, we all know that they like to give the pretence of listening (occasionally they might) during a beta period... outside of that, you might as well kiss the camel. 🐪