I registered my domain through Namecheap. As they are Enom resellers, is it possible for me to enter through http://access.enom.com ? I tried but password was not accepted. If I registered through Powerpipe.com, would this have been possible ?

You should be able to access your domain via that link, but I'm not exactly sure how namecheap sets them up. Did you just try going to www.enom.com and accessing it? You could also try it from my site (www.domainmaze.com) as we are eNom resellers also.

Frank

As far as I understand it, just because a registrar is an enom reseller doesn't mean that access.enom.com is usable. I use Namecheap and am unable to use this method of updating. I think that this is an "option" that can be enabled/disabled by the reseller.

Originally posted by Abu Mami
As far as I understand it, just because a registrar is an enom reseller doesn't mean that access.enom.com is usable. I use Namecheap and am unable to use this method of updating. I think that this is an "option" that can be enabled/disabled by the reseller.
I am almost positive I'm correct about the following:

Any domain name in the eNom system is accessible via http://access.enom.com (often referred to as eNom's generic, tan interface).

Any domain name in the eNom system may be logged-in to via any Registry Rocket interface -- even that of an eNom reseller where one did not originally register one's domain. I believe same is also true for the new PDQ interface.

If it does not work, it is almost certainly a password problem.

There is no place in the eNom reseller interface on the eNom web site where one may specify whether or not a given re-sold domain can be accessed using the generic, tan interface, or the Registry Rocket interface, or the PDQ interface.

There is one possibility, however, which I have not yet tested so it might or might not be the case: It is possible that a domain registered through the eNom downloaded API and then modified by the reseller might not be accessible via one of the alternate interfaces. But, again, I haven't tested that one.

It's late as I'm writing this but in the morning I'll look into this and get an answer because now I'm curious myself.

Originally posted by DesElms

I am almost positive I'm correct about the following:

Any domain name in the eNom system is accessible via http://access.enom.com (often referred to as eNom's generic, tan interface).

Unfortunately, this is untrue. I contacted Elevated Hosting (Enom Resellers) to see if I could manage my domain ats http://access.enom.com and they stated that they have a proprietary control panel instead.

I wish they could all be managed through Enom...

Tried all of mine registered through NameCheap and got the same result - couldn't login in through access.enom.com .

Whether or not you can access the name via access.enom.com depends on whether a password has been issued *for the domain*. Basically there are three ways that a domain can be registered and controlled through eNom:

1) The registering company registers the name in their own eNom account and issues a domain control password to the customer. If done this way, access.enom.com can be used. This is how RegistryRocket works.

2) The registering company sets you up with an account on *their* servers, registers the name in their own account, then when you log in to your account with them you get control of all the names you've registered through them (probably via the API that eNom makes available). I think this is what NameCheap does. In this case a domain control password will almost certainly NOT be issued, and therefore access.enom.com will be unavailable.

3) The registering company sets you up with an eNom retail account, registers the names in *your* eNom account, and you can control them by logging in to your retail account either at the registering site or at the standard www.eNom.com If this is the case, you should be able to issue a domain password yourself if you need to grant access via access.enom.com (log in to your account at eNom.com, go to "domain names", click on the domain you're interested in, then choose the "Domain Access Password" option). This is how PDQ sites work.

I think this system was set up by eNom so that people (e.g. webhosts) could register domains in their own account and then give out a domain control password to their customers, whereas fully-fledged registration businesses had a choice of methods to give direct account control.

Best wishes,
Simon.

gadget,

Just for "grins" try to log into my site (www.domainmaze.com) and see if you can access your account.

As far as I know there are two ways that accounts can be setup with eNom. With the first method, they actually setup setup a retail account for you (i.e. you get an account name/password) and you can manage all your domains from this account.

With the second method you don't have your own retail account but there is a password associated with the domain. In this case, the access.enom.com is used to manage the account.

This is just based on observation and I don't have any facts to back it up. I have a contact and eNom and I'll try to get more details.

Frank

access.enom.com dun work with registerfly also

I represent NameCheap.com and I just wanted to clear things up for you. Most of our website including our database and control panel is custom built, therefore access via access.enom.com is not possible. I think you will find the control panel we provide for you as good or better than the one provided by enom. If you have any other questions do not hesitate to contact us.

Thanks for clearing the doubt for us ;)

Okay, I am yet another enom reseller.

The bottom line is this - when a reseller registers a domain name through the API, or whatever registration method is used, the reseller has the option of setting a domain password or not. This can be implemented any number of ways - the reseller could prompt the user for it, or the reseller could simply utilize the customer's reseller account password (as we'll be doing) or the reseller can simply ignore that feature and not set any password at all.

So, it seems that NameCheap probably doesn't set a password for your domain. It is a very simple matter to set one and I'm not sure why they don't do it. To me, it is an important failsafe - if my site should ever go down, every customer is assured that they can have full access to their domain. They probably do not want to involve enom in any way shape or form, despite the fact that the access.enom.com panel is not branded and can be used in a manner that has enom transparent.

In any event, if it is very important to you to have that access, you can shift your name easily to any other registrar or reseller you choose. Of course I'd recommend me, but that would be biased, and is not the intent of this e-mail :D

As for a great hosting company - depending upon your needs, I'd highly recommend www.hostit365.com. I'm not sure whether or not affiliate links are taboo here or not, so I'm not going to put mine up. Besides, this is an unbiased recommendation. I've used quite a lot of hosts and these guys are really great in all areas.

If you want any more info on any of this, please let me know. Feel free to e-mail me privately as well.

Hope this helps.

Mike

OK, it seems that PowerPipe.com does give direct access to access.enom.com to manage the domain accounts. Namecheap should have done the same too :rolleyes:

Well...we're in competition with Namecheap, but I have to say that their interface is pretty nice and I'm not entirely sure why you'd want the ability to use access.enom.com as well? Unless you're worried about them going under of course. In that case you might do well to look for someone who creates a full eNom retail account for you when you order from them rather than just issuing you with an access.enom.com password. That way you can be sure that the domain is in your account and not theirs, and even if they do go belly-up you'll still be able to log in and fully control your domains from the main eNom.com site (this is how we do it).

I wouldn't be too worried about Namecheap though, they've been around a while and have a good reputation.

Simon.

As I had previously stated, it is prudent to offer, since it allows redundancy - in the event that the reseller's site were down, etc. Or, if perhaps enom was to add features and the reseller did not keep up, etc. I think it's a good measure of security, since no end user can really determine much about the reseller they are doing business with.

Anyhow, we create subaccounts for all of our customers.

Mike

Yes, the sub-account option offers the best of all worlds. Access via the reseller's site, access via eNom.com, and the ability for the customer to create an access.enom.com password too if they so choose. Total redundancy as you say. I guess my point was that given Namecheap's excellent reputation I wouldn't let the lack of an access.enom.com password deter me from using them.

Mike: Did you use PDQ, or did you manage to code for the API in such a way as to automatically create sub-accounts, or do you create the sub-accounts manually? Just being nosey, we use PDQ and have found it to be superb so far.

Best wishes,
Simon.

Quite honestly we really have not had many, if any, requests to give access to our customers via access.enom.com. That being said we are definitely not set in our ways and are always looking to improve. Seeing that there is a demand for this, I will speak to one of my developers about implementing this option. Very interesting board here, I was reffered here by one of our customers. BTW Simon thanks for the kind words :)

Richard

Originally posted by AQHost
Mike: Did you use PDQ, or did you manage to code for the API in such a way as to automatically create sub-accounts, or do you create the sub-accounts manually

Simon,

You can setup the retail sub-accounts via the API. That's what I was working on before PDQ came out. It's a tad tedious and not that well documented, but it can be done.

Frank

Originally posted by ffeingol


Simon,

You can setup the retail sub-accounts via the API. That's what I was working on before PDQ came out. It's a tad tedious and not that well documented, but it can be done.

Frank

Yup, I got that far with my own implementation of the API (in PHP). I could create sub-accounts, put domains in the shopping cart, etc - the downfall was that I couldn't actually set the retail pricing in the new sub-account. There's an undocumented API function PE_SETPRICING which is supposed to allow you to do this, but I never got a completely coherent model for the function from eNom's developers. The function involved passing the party ID after the account had been created, and then setting the pricing for each TLD, but it kept returning errors.

Best wishes,
Simon.

Originally posted by brn2h8
Unfortunately, this is untrue. I contacted Elevated Hosting (Enom Resellers) to see if I could manage my domain ats http://access.enom.com and they stated that they have a proprietary control panel instead.
So all that means is that my suspicion, as stated earlier, that names registered through the API may not necessarily be accessible via the generic tan interface, the Registry Rocket interface, or the new PDQ interface, was correct. And, clearly, other postings herein subsequent to my original one seem to bear that out.

Also, my earlier statement that any domain in the eNom system is accessible via the generic tan interface or the Registry Rocket interface; and that if it is not then it has to be a password issue, is also correct. Not creating a password for the domain is, categorically, "a password issue." When I wrote what I wrote earlier, I guess I didn't stop to consider that not creating a password at all might not be considered by those posting herein to be "a password issue." I guess I should have been more specific. Even one's domain created using NameCheap's custom interface can be accessed via the tan generic interface (access.enom.com), or the Registry Rocket interface if NameCheap simply goes into its reseller account on the eNom web site and issues one's domain a password.

Finally, my statement that there is no place in the eNom interface where one can specify whether or not a given re-sold domain can be accessed using the generic tan interface or the Registry Rocket interface was also correct. What I meant and that was clear was that there is no place in the interface where one checks a box or answers a 'yes' or 'no' question or anything like that. I suppose one could argue that not assigning the domain a password, or assigning one, is the same as indicating whether said domain may or may not be accessed via the generic tan interface and/or the Registry Rocket Interface. In that sense, assigning or not assigning a password is "indicating" whether or not the password may be accessed via http://access.enom.com or the Registry Rocket interface.

So, brn2h8, what I wrote earlier was not untrue after all.

Just wanted to set that record straight.

And I'll up the ante a bit and offer those posting here yet another related aspect of this matter to chew on and, if you see it as I do, to be irritated about...

Once a password is assigned to a domain name so that it can be accessed via http://access.enom.com, it can thereafter also be accessed via any reseller's Registry Rocket interface.

That has always bugged me. I've always felt that if a person registered his domain through my Registry Rocket interface, he should not be able to go over to the Registry Rocket interface of my competitor who is an eNom reseller and be able login to modify it. But the way the eNom system is set up, he can. And this begs the question -- a question which I have not tried to answer through testing but which I probably should -- if one registers a domain through my Registry Rocket interface, thereby placing it into my eNom reseller account, can one then go to the Registry Rocket interface of my competitor who is also an eNom reseller and renew the name? And, if so, does it then move over to his eNom reseller account? Personally, I suspect the answer to both those questions is "no," but, again, I haven't tested it.

But if you think that's irritating, you ain't seen nothin' yet...

Did you know that any account that can be logged-in to directly on the eNom web site can also be logged-in to on any eNom reseller's PDQ site? Don't believe me? Any one reading this who has a direct retail or reseller account with eNom... just go to any PDQ interface that you happen to know of that is not your own and try logging-in using the same login ID and password that you use on the eNom web site. If you don't happen to know of a PDQ interface that isn't your own (and if you're not Lee Hodgson), try Domain Guru's PDQ interface (http://register.domainguru.com) just for testing purposes.

But the behavior is not limited to direct eNom retail and reseller accounts. Any retail or reseller account Log-in ID and password originally intended for use directly only on the eNom web site but created by a reseller, beneath said reseller's eNom account, may also be logged-in to on any other eNom reseller's PDQ account!

Of course this begs the same sort of hypothetical question I raised earlier in this posting regarding the Registry Rocket interface, to wit: If I have a retail customer who signs-up and registers domains using my PDQ interface (thereby becoming a retail sub-account beneath my eNom reseller account), and he then goes over to Domain Guru's PDQ interface (http://register.domainguru.com) (or any other eNom reseller's PDQ interface) and logs-in and purchases additional domain names and/or renews existing ones, which eNom reseller account gets a piece of that action... mine, Hodgson's, or both?

The answer, I believe, is that even when my customer who originally created his account using my PDQ interface logs-in to Hodgson's PDQ interface, he is still considered by the eNom system to be my customer. This is evidenced by the fact that when he does try to purchase an additional domain name and it gets into his shopping cart, he sees there my pricing that I set for him, and not Hodgson's pricing as shown in the "pricing" section of his PDQ interface (into which my client is, to my chagrin, logged).

Is it just me, or does anyone else around here find this cross-logging-in capability across all Registry Rocket and PDQ interfaces to be particularly irritating?

Simon -

We have coded everything to interface with the API and have built a custom site, rather than using any of the canned stuff. You can take a look at the development site at www.smoothregister.com. It is not live yet, and not complete.

We've got it so that the API interface will setup a retail subaccount for each new customer automatically through the API. Of course I've also got the option of setting up manual subaccounts, but will not have the need and that would cause complexities in syncronizing the two, since we are storing some customer history and details locally as well as in eNom's databases.

Anyhow, I'm not sure what price level you've prepaid for, but I am at the lowest, so if you'd like to work something out, get in touch with me directly and I might be able to get you better pricing or maybe we can work something else out that is mutually beneficial.

Also, I've managed to get eNom to make improving their documentation a priority. Apparently they've now got a technical writer or intern working on this as a major project. That should simplificy a lot of things. The API is more powerful than their documentation enables you to properly implement it.

Mike
mike@centralstation.com

Mike,

Nice work so far, I like it. I'm guessing the availability lookup is one of the incomplete parts as it shows domains as registered when they're not? One of the frustrations I had when coding for the API was that eNom changed from having the results of an availability check in a particular order to returning them in a random order. Without telling anyone :rolleyes:

One question though - once you've got the retail sub-account set up (which I can happily code for) have you managed to set the pricing levels in their account using PE_SETPRICING? Or did you find another function that does the same thing?

Thanks for the offer on pricing btw, but I'm all set.

Best wishes,
Simon.

DesElms,

First great posts. Takes a while to read (and re-read) but great posts.

From a customer point-of-view, I really like the fact that my customers can go to any eNom reseller (or even eNom) and manage their account. It gives them a nice warm fuzzy. They want to know that if we get run over by a beer truck, they can still manage their domains.

Customers can "push" their eNom account from one reseller to another. The need to know the username of the reseller that they wish to "push" to. In the PDQ interfaces, it's under Domain Names/push.

Finally, I did some testing (and things worked as I expected them to). I have a dummy account setup. When I went to register.domainguru.com and logged it, it looks like their site. But when I check the pricing, I got the pricing that I set for the dummy account.

So eventhough you can log in from anywhere, you are still the customer of the reseller that you signed up under and you get their pricing etc.

I may be totally wet on this, but that's what I could see from my testing.

Frank

Originally posted by ffeingol
Customers can "push" their eNom account from one reseller to another. The need to know the username of the reseller that they wish to "push" to. In the PDQ interfaces, it's under Domain Names/push.


That function actually pushes a domain name from one account to another (popular with ebayers). It doesn't move the whole account. They could of course set up a new account with the new reseller and then use the "Push List" function to push all their names from the old account to the new one. But this is getting kinda off topic :D

Best wishes,
Simon.

Simon - the results are fictitious since the site is NOT LIVE and is thus on the resellertest.enom.com TEST SERVER ;)

I've got to check my notes and the current code to see what we managed to do on setting pricing.

Mike

Originally posted by ffeingol
First great posts. Takes a while to read (and re-read) but great posts.
My strategy in these forums is to wear down the reader so that no one will argue with me. [Kidding... er... well... sort of. ;)]

Originally posted by ffeingol
From a customer point-of-view, I really like the fact that my customers can go to any eNom reseller (or even eNom) and manage their account. It gives them a nice warm fuzzy. They want to know that if we get run over by a beer truck, they can still manage their domains.
Well, we're pretty much of one mind on that notion -- to a point. If I had any wary customers, it would, indeed, be nice to be able to show them that their account on my site (via PDQ) would also work on the eNom web site. But I have no interest whatsoever in assuaging their worries by pointing out that they can also go to the PDQ interfaces of any of my competitors. If knowing that eNom is behind my registration business isn't enough then the customer is going to have to figure out a way to live with it in my opinion -- either that or find another registrar or reseller thereof.

And it's a false sense of security in any case. If I got run over by a beer truck (from my typing fingers to God's ears as far as my ex-wife is concerned) and my eNom reseller account subsequently terminated along with my life, my customers' retail and reseller accounts would revert to direct eNom accounts -- and at the higher eNom prices. To recapture the lower prices, they would then need to find another eNom reseller who had been more successful at avoiding beer trucks than I had been, and who would match or beat my prices, and they would have to "push" all their domains from the aforementioned direct eNom account to their new account at the new reseller. Which, indirectly, brings us to your next comment...

Originally posted by ffeingol
Customers can "push" their eNom account from one reseller to another. The need to know the username of the reseller that they wish to "push" to. In the PDQ interfaces, it's under Domain Names/push.
As Simon beat me to pointing out, and as he correctly stated, the "push" feature is for pushing domain names from one eNom account to another, not for pushing eNom accounts from one reseller to another. Although... now that you've brought it up, that would be a pretty cool PDQ feature, wouldn't it? But I digress...

In any case, it isn't the name of the destination reseller that one needs to know to push a domain name on the eNom system. It is the destination reseller's eNom Log-in ID that one needs to know to do so. And visiting a competing reseller's PDQ interface would not tell your customer that information.

Originally posted by ffeingol
Finally, I did some testing (and things worked as I expected them to). I have a dummy account setup. When I went to register.domainguru.com and logged it, it looks like their site. But when I check the pricing, I got the pricing that I set for the dummy account.

So even though you can log in from anywhere, you are still the customer of the reseller that you signed up under and you get their pricing etc.

I may be totally wet on this, but that's what I could see from my testing.
No, you're not all wet... er... well... your personal habits regarding the state of dryness you prefer while typing postings in WebHostingTalk are none of my business but... let's at least say that you're not wrong. [grin] As I pointed-out in the second-to-last paragraph of my previous posting, once a customer signs-up and opens an account via one reseller's PDQ interface, that customer, when using that Log-in ID, remains the originating reseller's customer, no matter which competing eNom reseller's PDQ interface the customer goes and logs-in to.

But why? I mean, what in the world could possibly be more confusing for the customer than that? And does not that incidental capability help to erode the customer's brand loyalty to the originating reseller -- at least in some measure?

This obviously isn't an earth-shattering problem, but I find it irritating and I wish the eNom system did not allow cross-reseller Registry Rocket and PDQ interface logging-in.

And, circling back to why I brought it all up in the first place... it all further illustrates my larger point: That eNom's system pretty much lets any domain name to be logged-in to in almost any of the various eNom interfaces...

...but, as has been more precisely stated by others than I stated (but meant) in my first posting in this thread, only as long as the reseller gives the domain name its own password in the eNom reseller interface on the eNom web site.

Very simply, write to eNom and express your concerns and suggestions for alternate methods of handling this. They've been very open to suggestion and good at putting good feedback into their development pipeline.

Mike

Originally posted by lbeachmike
Very simply, write to eNom and express your concerns and suggestions for alternate methods of handling this. They've been very open to suggestion and good at putting good feedback into their development pipeline.
Already did it. I just wanted others to know about it here so maybe I wouldn't be the lone wolf making the suggestion. And also because I was just curious how everyone else felt about it.

It's a catch-22 - you can argue the benefits of detriments of both. I'd have to give this further thought, and since I'm not using their generic stuff, I've not yet come across this directly.

I think that the percentage of users this would affect, in reality, will be small - let's say it is 1%, which I believe is a generous number. So, while I would not want to churn 1% of my customer base, I don't think it's a great concern. I also don't think it will churn customers.

The potential for abuse would lie in the ability for somebody to register a misspelled domain name of a competing reseller and hope to suck up some of their competitor's customers who have poorer typing skills :D This, of course, is illegal.

Other than that, I simply don't believe that most customers are smart enough to do anything unless another registrar/reseller uses this to try to lure them away. So, that is where I see the greatest potential issue - in the abuse area by a bad-faith reseller.

mrk

Well this has been the most informative thread I've seen here in quite a while.

Thanks guys!

Frank

Originally posted by lbeachmike
I think that the percentage of users this would affect, in reality, will be small...
I think you're probably right. Like I said, it's not an earth-shattering thing. It's just an irritation that I wish eNom had anticipated and had coded-for appropriately. That's all... no big deal.

By the way, Mike... smoothregister.com looks real nice. Congratulations and good luck with that.

I have a usability suggestion, though, if you don't mind...

I notice you're using radio buttons beneath your search box to specify which of the TLDs the user wants included in his search; and that as many radio buttons may be clicked active as the user wishes.

I realize HTML allows one to use radio buttons in this way. However, if one goes back even further and examines how Microsoft specifically indicated that radio buttons should be used in program interfaces, they were intended for "choose-one-only" sorts of situations. In other words, they were intended to be used in a situation wherein the end-user has several items to choose from, but can only choose one of them; and, having clicked on one choice, when he tries to click on another the first choice is unselected in favor of the second. And so on and so on.

Microsoft's intended graphical element for situations wherein the user may select several items from a larger list is the checkbox.

Now, all that having been said, we've all seen web pages which use radio buttons in the way you're using them. And they've worked out just fine. But from my reading and experience, that is generally frowned upon, and checkboxes are preferred as a matter of appropriateness and style, as well as consistency with the original Windows GUI just generally.

Just my .02 worth... just tryin' to be helpful -- not that you asked, so if my unsolicited suggestion is unwelcome, so be it. No harm or offense was intended.

Originally posted by ffeingol
Well this has been the most informative thread I've seen here in quite a while.

Thanks guys!

Frank

Yeah, right ! Glad I could start it off :D

I admit to being a bit confused regarding the logging in thing. I went to a PDQ site (not mine) and logged in with my reseller username and registered a domain through my reseller account. I'm not sure if custoemrs would do this (use a previous login name), and register a name thinking they are getting one price but ending up getting the price fromk the other reseller. Could be confusing. I suppose it would have to return an error saying that the username was already being used, which leads me to think that usernames are only unique to the particular reseller account (and enom account if registered through enom directly at their site of course)?

Anywhooo, point was I was surprised I could log into my account through a PDQ site and access it as if I logged in at enom. I'm glad I got my price for the domain, though, heh, as the PDQ site I was at was $5 more :D

Originally posted by DesElms

I think you're probably right. Like I said, it's not an earth-shattering thing. It's just an irritation that I wish eNom had anticipated and had coded-for appropriately. That's all... no big deal.

Actually it could be an earth-shattering thing. I was going back through this thread earlier, and Chicken's post in particular, when a thought struck me (it was going slowly at the time, no harm done). Let's say that I coded a full implementation of the API and had my customers set up in retail sub-accounts under my account. I hooked the code into my merchant account for payments, and the lower rates meant that (being insane) I could sell for $7.49 as a publicity stunt and make 10 cents net per domain. That would be fine as long as my customers used my site, but what if they logged in using their username and password at a PDQ site? That PDQ site couldn't hook into my merchant account, so would the registration still work? And if so, would I be charged eNom's merchant fees, thus pushing me into a loss situation? Hardly seems right or fair...

Originally posted by DesElms

I notice you're using radio buttons beneath your search box to specify which of the TLDs the user wants included in his search; and that as many radio buttons may be clicked active as the user wishes.


Some added input (groan) on the radio buttons - I notice that your site makes extensive use of JavaScript to interpret them. That's ok, but what's going to happen to the small percentage of paranoid surfers who surf with JS switched off? You might want to put a warning on the page that JS is required, or else use checkboxes and some server side code to do the interpreting. Just my $0.02, so between the two of us you're up nearly a nickel :D

Best wishes,
Simon.

My guess is that the registration wouldn't work, since they'd be logged into their account which isn't funded.

Originally posted by Chicken
My guess is that the registration wouldn't work, since they'd be logged into their account which isn't funded.

Retail accounts aren't required to be funded, only reseller accounts. Just for the hell of it I created a retail account (via the API) then manually set .com at $7.49. Then I went to Frank's PDQ site, logged in, chose an available domain name, then went to checkout. I was prompted for credit card information which makes me think the registration would have gone through just fine at a loss to me after eNom's charges. That's a pretty serious flaw IMHO...

Simon.

Tried the same stunt on a RegistryRocket link...
so say for ease of calculation my cost is $10
I can setup a RR link for $10 (my cost) and ask my customers to register thru the link...

Now guess what happens, customer keys in his CC number and the domain is his for a $10 charge...

What does Enom do to my account, it credits $0.00 then debits it by $0.95 + (0.03*$10) = $1.25
which means I LOSE $1.25 on every transaction...

Serious flaw in the system ... IMO...

Hmm. I see what you're saying now. Hmm.

I just sent a message to my contacts at eNom asking them to consider tuning-in to this thread so they can see if they agree that there is an issue here and, if so, to go about remedying it.

They're probably out for the rest of the week for the holiday -- I know at least one of them is -- but no doubt they'll stop-by here on Monday at the latest.

As I'm sure Simon (AQHost) and Mike (lbeachmike) will attest, once eNom is made aware of stuff like this, it's usually pretty good about getting it into the development/repair queue.



07-03-2002 02:41 PM PDT
I have re-thought this situation and my words, above, and I now refer the reader to my posting made at 07-03-2002 02:39 PM, below.

Not being an Enom reseller I found all this both enlightening and disturbing. One of the things I stress to all domain purchasers is that they can access their account either through my site or directly through the registrar's site. I want all customers to have full control independent of me and encourage customers to only use registration sites that grant them such protection. If I were selecting an enom reseller to purchase from (and, yes I have many domains through one or more enom resellers), I would personally make sure that I had independent access through access.enom. I don't care if the alternative is better...I just want the safety.

Originally posted by Incognito
Not being an Enom reseller I found all this both enlightening and disturbing. One of the things I stress to all domain purchasers is that they can access their account either through my site or directly through the registrar's site. I want all customers to have full control independent of me and encourage customers to only use registration sites that grant them such protection. If I were selecting an enom reseller to purchase from (and, yes I have many domains through one or more enom resellers), I would personally make sure that I had independent access through access.enom. I don't care if the alternative is better...I just want the safety.
I don't disagree with this. As I said earlier, if I have a wary customer who wants to know that he can always log-in on the eNom web site, all I have to do is give him a retail sub-account Log-in ID and password and away he goes.

And the new PDQ interface has that built right in. Any customer who establishes an account on any eNom reseller's PDQ interface will automatcally be able to log-in directly on the eNom web site using that same Log-in ID and password. And that's because when one creates an account on a reseller's PDQ interface, one is creating a sub-account beneath said reseller's eNom reseller account. And all sub-account Log-in ID's and passwords work directly on the eNom web site.

I suspect no eNom reseller would (or, if he did, he probably shoudn't) have a problem with his PDQ customer also being able to log-in directly on the eNom web site. I think you'll get no argument -- certainly not from resellers who share your views (and in my opinion they should).

My issue is that my PDQ interface customer can, in addition to being able to log-in directly on the eNom site (which I don't mind), he can also log-in on any other eNom reseller's PDQ site (which I do mind). Though as long as they use the Log-in ID and password they got on my PDQ site they remain my customer no matter whose PDQ interface they log-in to, it introduces a level of confusion and screws around with the original eNom reseller's customer's brand loyalty issues in a way that's just not necessary or acceptable to me.

This posting amends my posting made earlier at 07-03-2002 09:40 AM and last edited at 07-03-2002 at 02:41 PM:


Actually, upon re-reading and re-thinking, I now realize that I shouldn't have responded quite as I did earlier. I mean, I still think it's worth a look by eNom to see what the issues of this thread are and to decide if anything needs to be done about it.

But as for Simon's and Royong's posts above...

The single thing that would make the problem Simon suggests into an actual problem is the API's creation of an eNom retail sub-account than can be logged-in to on the eNom web site. That's not a thing that normally happens when the API is implemented. Actually, if we go back through this thread, we learn that that's a cool extra thing that Mike (lbeachmike) did and which, now that he's read Simon's posting, he may want to reconsider.

Normally when one does a full implementation of the eNom API one does not also set up a retail sub-account as part of it. eNom intended for domains registered through the API to end-up directly in the eNom reseller's direct eNom reseller account. The API simply allows the reseller's customer a way to control the domain without having to log-in to the reseller's direct eNom account directly on the eNom web site. The http://access.enom.com interface (which, incidentally, was always intended by eNom to be CNAME aliased-to by the reseller so it could become www.access.reseller's-domain-name.com (http://access.domainlightning.com)) was created for the benefit of resellers who bothered to code the registration part of the API, but not the domain control part. Such resellers could register names on their sites using the API, but then tell their customers to go to www.access.reseller's-domain-name.com (http://access.domainlightning.com) to manage their domain. That was the whole point of http://access.enom.com

When one uses the API and their own merchant account, one must charge the customer enough more than his eNom wholesale price to cover their own merchant account's charges and still make a profit.

The Registry Rocket interface is nothing more than the eNom API as downloaded from eNom's web site, but running on eNom's own servers and using eNom's own merchant account. eNom created it for the benefit of eNom resellers who did not want to download and customize the API themselves and use their own merchant accounts. And eNom charges the reseller $.95 plus 3% of the price the customer pays for that privilege. So when a reseller uses the Registry Rocket interface, the reseller must charge enough more than his eNom wholesale price to cover eNom's merchant charges and still make a profit.

So, Royong, one would never set their Registry Rocket price to $10 if their cost was $10. In addition to the fact that there's simply no gross profit in it if $10 is your cost, that price also doesn't take into consideration that eNom is going to charge the $.95 and the 3% of the $10. If your cost (and I presume by "cost" you meant your wholesale cost) is $10, then you'd need to add a few bucks of good, old-fashioned gross profit, and then you'd need to add the $.95 that eNom's going to charge you, plus calculate what 3% of that total would be and add that, too. That's always been the case with Registry Rocket. It's not a serious flaw. It's how eNom set it up so that resellers could use the eNom API without customizing it themselves. Someone has to pay the credit card charges. eNom's certainly not going to. You certainly would have paid them if you had used the API on your own site and used your own merchant account. eNom's charges might be higher than most merchant accounts, but one should consider the difference what eNom charges for letting you use theirs.

In neither of the above scenerios (the reseller's full implementation of the API, or the reseller's use of Registry Rocket instead) does the customer get a retail sub-account log-in ID which can be used directly on the eNom web site. eNom never meant for that to happen.

In the case of the first scenerio -- the domain having been registered via the reseller's full API implementation -- as long as the reseller never gives the customer's domain a password in his eNom reseller account, the customer may never access and control it using either the http://access.enom.com interface (or any alias CNAMEd thereto), or using the Log-in part of anyone's Registry Rocket interface either. That, apparently, is how NameCheap (and many other resellers who use the API) does things.

In the case of the second scenerio -- the domain having been registered via the Registry Rocket interface -- the domain would immediately become accessible via the Login part of any reseller's Registry Rocket interface, as well as the http://access.enom.com interface (or any alias CNAMEd thereto). And my earlier concern was with the former of those two: The ability of my Registry Rocket customer to go to any other reseller's Registry Rocket interface and log-in and control his domain name. That in and of itself isn't so bad (though it messes with my customer's brand loyalty, in my opinion). The problem is, what happens if my Registry Rocket customer then chooses to renew his domain (which had originally been registered on my Registry Rocket interface) on another eNom reseller's Registry Rocket interface? That's the one I haven't tested yet to see what happens. But because the domain is actually in my eNom reseller account, I suspect it would simply not work. So I'm not too awfully worried about that one.

The new PDQ interface is a different animal altogether. When a customer creates an account on a reseller's PDQ interface, he's actually creating a sub-account beneath the reseller's direct eNom reseller account -- something that, prior to PDQ, only the reseller could do as a manual process within his own eNom direct reseller account. I have no problem with the fact that my PDQ customer can use the Log-in ID and password obtained on my PDQ site to then go log-in directly on the eNom web site. That's fine. My problem is that they can then use their Log-in ID and password obtained on my PDQ site to then go log-in to any other eNom reseller's PDQ interface. But my concerns about that are mostly marketing and brand awareness concerns -- and general customer confusion concerns -- since my PDQ customer created on my PDQ site always remains my customer and sees my pricing no matter where he logs-in.

Simon's scenerio, of course, is why NameCheap and the others who have bothered to implement a fully-functional API interface don't also create retail sub-accounts as part of what happens when their customers register domain names. They can safely give passwords to their customers' domains so they can be controlled using http://access.enom.com (or any alias CNAMEd thereto) and Simon's scenerio would not be an issue because it would just be a password to the domain, not to an entire retail sub-account that could be logged-in to anywhere and could incur credit card charges.

But there is no question that Simon brings-up an excellent point on one score: A domain name registered via a reseller's fully-functional API and using said reseller's own merchant account is completely incompatible with eNom retail sub-accounts. The minute your API also gives a customer a retail sub-account on the eNom system, it opens the door for said customer to purchase or renew domains within the sub-account on the eNom web site rather than via the reseller's API. If so, that method would use the reseller's prices calculated for the reseller's own merchant account yet would use eNom's (undoubtedly higher) merchant fees. If the reseller's margin were tight, as in Simon's scenerio, that would definitely be a problem, as Simon correctly pointed out.

The solution, it seems to me, would be to either not allow your API to also create a retail sub-account on the eNom web site, or, set your pricing on both your API and in the sub-account to one price that's high enough to cover the higher eNom merchant fees when and if the customer uses the eNom web site instead of your API. That way the customer would see the same pricing no matter which interface he used. And you'd make a little bit more profit when he used your API since your transactions there use the lower fees of your own merchant account.

Of course, eNom will be surprised to read some of the thoughts in this thread because it has taken great pains to hide the fact that eNom is the ICANN-approved registrar whose domains the reseller is reselling if the reseller so desires. After all, why do you think eNom changed its nameservers? eNom is probably going to think to itself, after reading this thread, "Man! You're damned if you do and damned if you don't" because after all it did to help the reseller be independent from eNom in the eyes of his customers, here we are arguing about giving the customer a warm, fuzzy feeling knowing he can always use the eNom web site directly instead of the reseller's interface -- presumably in case the reseller goes out of business some day or something.

What a fickle crew we are, eh? :D

I have to agree on the RegistryRocket issue.... how thinking back.. maybe its not a "serious flaw" but I thought that the system should prompt to say that a price of $10 would result in a lost .. by the way, the system does prompt you when you set a price lower than your cost i.e $9 - so I guess, this would make it a little suggestion for improvement on the RR system, maybe ?

Correct me if I'm wrong on this... I'm actually quite new to the Enom thingee.... for the benefit of others reading this thread...
I found that when a customer registers via my RR link, he is able to login to http://access.enom.com to manage his domain - I have no qualms over that.... but ..... he can only manage the DNS and Nameserver settings, the system does not all full access to all the functions as advertised by Enom ie. 10 page web site - so I guess if the customer requires / wants to use Enom's 10 page web site - for reasons unknown to me - then the reseller has to "upgrade" him to a retail account which he can either login at Enom.Com or at someone's PDQ.

Now that truely makes RR a bare bones system - for a full access, a customer still needs more than RR domain login - he needs a retail account login.

PS - thanks Gregg and Simon for all the information - you guys are simply wonderful.............:)

Originally posted by Royong
I have to agree on the RegistryRocket issue.... how thinking back.. maybe its not a "serious flaw" but I thought that the system should prompt to say that a price of $10 would result in a lost .. by the way, the system does prompt you when you set a price lower than your cost i.e $9 - so I guess, this would make it a little suggestion for improvement on the RR system, maybe ?
So, if I understand you right, you're saying that if you set a Registry Rocket price that's above your wholesale cost, but still too low to cover the $.95 + 3% eNom merchant fees, the eNom system doesn't warn you that you're going to go negative on any sales made using said Registry Rocket interface. Right? I haven't tried that, so I actually didn't know what happened if you did that. But if that's what you're saying, and if it's true that that's the behavior of the system, then I suppose that is indeed a flaw that eNom should probably fix. But I wouldn't hold my breath. In an email discussion with one of eNom's higher-ups a month or two ago, I got the distinct impression that no more improvements to the Registry Rocket interface were being planned; that PDQ was now eNom's focus for an eNom-hosted reseller interface. I'm not saying the person specifically said that. I'm saying I got that distinct impression from other things she said. That having been said, if a person could convince eNom that it had a serious problem with the Registry Rocket interface, I'm sure it would schedule a fix for it in the queue.

Originally posted by Royong
Correct me if I'm wrong on this... when a customer registers via my RR link, he is able to login to http://access.enom.com to manage his domain... he can only manage the DNS and Nameserver settings, the system does not allow full access to all the functions as advertised by Enom ie. 10 page web site - so I guess if the customer requires / wants to use Enom's 10 page web site - for reasons unknown to me - then the reseller has to "upgrade" him to a retail account which he can either login at Enom.Com or at someone's PDQ.
Yes, you've got it right. The generic, tan http://access.enom.com interface (or any alias CNAMEd thereto) is the most limited. It provides basic domain control -- usually all that most people need:

- Contact information
- Nameservers
- Hostname DNS configuration (IP pointing, MX records, CNAMEs, etc.)
- email forwarding
- Password maintenance

The management part of the Registry Rocket interface has all that and a few more features , to wit:

- Value-added features (the three "Name My..." products)
- Ability to renew the domain name
- Ablity to release the registrar lock

Quite frankly, it's difficult to imagine the vast majority of domain registrants needing much more than that. But it's true that the above interfaces still do not provide access to control each and every last one of eNom's features -- like the 10-page web site, for example. Or the POP3 accounts. That sort of thing.

To give people access to those additional features, you'd need to either manually create for them a retail sub-account beneath your eNom reseller account directly on the eNom web site; or you'd need to have a PDQ interface where they could open an account which, as an added benefit, would automatically create a retail sub-account beneath your eNom reseller account directly on the eNom web site. From that point forward, your PDQ customer could log-in on your PDQ interface, or directly on the eNom web site, or (to my chagrin) in any other, competing reseller's PDQ interface.

Originally posted by Royong
Now that truely makes RR a bare bones system - for a full access, a customer still needs more than RR domain login - he needs a retail account login.
Well... yes and no. I mean, Registry Rocket's management interface doesn't include the ability to control every last one of eNom's features. But it includes the ability to control all of them that anyone tends to ever use. Isn't that pretty much enough?

And, yes, to go beyond that he'd need either a retail or a PDQ account, as explained above.

Originally posted by DesElms
So, if I understand you right, you're saying that if you set a Registry Rocket price that's above your wholesale cost, but still too low to cover the $.95 + 3% eNom merchant fees, the eNom system doesn't warn you that you're going to go negative on any sales made using said Registry Rocket interface. Right?

Spot - on !

Another little flaw...

Following my post about a theoretical situation in which a reseller had developed a site around the API using his own merchant account etc and the possibility for a loss if his customer used a PDQ site, I had a thought (2 in 1 day - get the red pen out): if that reseller hadn't signed up for eNom's credit card processing services, which since he was using his own merchant account he certainly wouldn't have, then surely the transaction couldn't go through at a PDQ site?

Wrong.

I created a reseller account under my own, and the new account was not signed up for Registry Rocket, PDQ, and hadn't agreed to the card processing terms and conditions. I then logged in as the new reseller and created a retail sub-account with a price that would incur a loss. I took that retail account and logged in at someone else's PDQ site, chose a name, and was prompted for CC information. The whole transaction went through perfectly despite the fact that the reseller to whom the retail account belonged had not agreed to the card processing Ts and Cs...

That can't be right, surely?

I think what we need here is basically what DesElms said in an earlier post - resellers must be given ownership of the retail accounts that are created directly under their account, not just for brand loyalty and marketing purposes, but to prevent possible financial loss for those who develop for the API. Ownership must be granted in such a way that the retail customer can log in at eNom.com and the reseller's site, but not anywhere else. I appreciate that it's possible to develop for the API in such a way as to retain the domain in the reseller's account, but that's not the point. Doing things that way loses out on an awful lot of functionality - all of the shopping cart features for a start.

Another $0.02 worth. I'll go broke at this rate!

Simon.

So which means for the the current moment...
on the safe side of things, resellers SHOULD

alway make their minimum prices = cost price + 0.95 + 3%

irregardless whether they are using APIs, PDQ, RR or manual creation of reseller and retail accounts.

The only sureproof way of NOT making a loss....

then again.. I might be wrong !

Originally posted by Royong
So which means for the the current moment...
on the safe side of things, resellers SHOULD

alway make their minimum prices = cost price + 0.95 + 3%


I believe this to be true for retail accounts. For reseller accounts, I don't think it applies.

I had an interesting one the other day. ONe of my resellers wanted to buy a domain from himself. He only wanted one, so he did not want to deposit money into his account.

He setup a RR account and set the retail price to his wholesale price. RR took it and he was able to purchase the domain. The next day he checked and on his reseller account it had charged him for the CC fee.

At first I though this was pretty stupid of him. He should have set the price to wholesale + 3% + $0.95. Then I started to think about it. What he did was actually smart. He was going to get charged the same thing anyway so why not just set the price at your wholesale price.

I won't do it, but I wonder if you could setup a RR with a $0.00 price? Then you could buy the domain from yourself at no cost. It would then charge your reseller account your wholesale price + $0.95 and no percentage (since 3% of 0 is 0).

The PDQ system seems to have a few more checks and balances. You can not set the retail price for an account lower than wholesale price, but you can set it equal.

Frank

Well ... RR does have a few checks.. it doesn't allow you to create a link with a price lower than your wholesale price....

but .. I think your reseller is right... ie.

wholesale cost = $10 and if he sets up RR for $10
the total price would be $10 + $0.95 + (3%+$10) = 11.25
as such, $1.25 would be DEDUCTED from his commission account.

verus

my calculations of setting a RR for (10+0.95)*1.03 = 11.279
in this case, the cost price would be $11.279

Finding : Your reseller has justed saved himself $0.029

Just my 2cents... this time literally.

Boy, are you guys ever giving eNom's development people (whom I know for a fact are reading this thread) something to really think about!

Originally posted by AQHost...
If that reseller hadn't...
There's a critical "if" condition missing from your hypothetical description, the absence of which renders the hypothetical itself moot. And that "if" is: If your API also created a retail sub-account as one of the things it's programmed to do when it registers a new domain; and, thereafter, if it also placed said newly-registered domain in said retail sub-account.

Without that condition, there is no possibility that the customer who used your API for registration in the first place can then go log-in to eNom's web site or to a PDQ interface and do anything like what you describe. His domain, in that case, would be in your eNom reseller account, to which your customer has no direct access via the eNom web site or any PDQ interface. His sole means of controlling his domain is via your API or if you have his domain a password so he could control it via the generic, tan http://access.enom.com interface.

That was my point earlier: It's that whole business of having your API also create a retail sub-account that's tripping you up.
eNom, as nearly as I can tell, never had that sort of thing in mind for the API when it created it. eNom envisioned, I believe, that resellers who use the API would use it to register and renew, and then would either steer their customers to the http://access.enom.com interface or would add domain management capabilities to their API. The latter -- management strictly via the reseller's customized API -- is, no doubt, what is going on with Elevated Hosting as described in brn2h8's posting earlier in this thread. And the means by which Elevated Hosting denies it customers the ability to control their domains using the http://access.enom.com interface is that they simply never give the domain itself a password.

I'm becoming rapidly persuaded that, just categorically, an eNom reseller's use of the API and his own merchant account, and his use of sub-accounts and/or PDQ, are mutually exclusive concepts.

But here's the sixty four thousand dollar question, as I see it... building on Simon's hypothetical:

If, the reseller circumvents the hypothetical problem Simon described by abandoning the notion of having his API also create a retail sub-account on the eNom web site whenever it registers a new domain name, and,

if the reseller, in order to avoid paying eNom's merchant fees also never creates a Registry Rocket interface beneath his reseller account, but,

if the registrar nevertheless agrees to give his customer's domain a password so that said customer can then manage the domain using the http://access.enom.com (or an alias of the reseller's that he has CNAMEd thereto) interface, then,

what happens when the customer discovers that he can log-in to any other reseller's Registry Rocket interface and manage his domain; and what happens if he then decides to renew/extend the domain right then and there while he's in the other reseller's Registry Rocket interface?

Does the other reseller's Registry Rocket interface simply reject the customer's attempt to renew/extend? Hopefully that's all that happens. But what if it's not?

What if it goes ahead and allows it and, if so, then at what price? Does it renew/extend at the price set by the other reseller in his Registry Rocket interface since that is, after all, where the customer is trying to do the transaction? Or, does it do so at the reseller's wholesale price since, after all, that's the account where the domain actually "lives" and the pricing set forth therein is the only pricing the eNom system knows to use?

And if the other reseller's Registry Rocket interface does allow your customer to renew/extend his domain, and if it does so at the other reseseller's price since, after all, that's whose Registry Rocket interface is being used for the transaction, does the customer remain your customer or, because he renewed it the other reseller's Registry Rocket interface, does some kind of weird, automatic "push" thing happen whereby the domain now gets moved from your reseller account into the other reseller's eNom account?

Ponder that one, why dontcha?

Actually, if forced to guess, I'd guess that the other reseller's Registry Rocket interface would just refuse to renew/extend once it sees that the domain does not actually exist in his account. But if it did allow it, I presume it would do so at the price set forth in the Registry Rocket interface in which the transaction is occurring. But, again, that's just a guess.

The scenario helps to illustrate my earlier point: That eNom's system should not allow cross-reseller logging-in on Registry Rocket and/or PDQ interfaces.

Which, of course, was Simon's point when he wrote...

Originally posted by AQHost...
I think what we need here is basically what DesElms said in an earlier post - resellers must be given ownership of the retail accounts that are created directly under their account...
Of course that still doesn't really fix the problem you outlined in your earlier hypothetical scenario. The minute you create a retail sub-account for your customer who originally registered using your API, and the minute you then push his domain into it so that he can log-in to the eNom web site or to any PDQ interface and manage it, he can then do the very thing you described above, unless, you set his price in said retail sub-account high enough that his purchases or renewals will not negatively impact your reseller balance.

In his earlier posting, Incognito made an excellent point about how important it is for some customers to know that they can always go directly to the ICANN-approved registrar's site in the event that the reseller becomes unresponsive or even goes out of business. And lbeachmike's idea of the API automatically creating a retail sub-account on the eNom web site responds to that nicely. But knowing what we now know, I'm not sure that will work out -- at least not unless lbeachmike sets the pricing in the sub-account higher to cover eNom's higher merchant fees.

And I'm not sure that we should be hard on eNom because there is an inherent mutual exclusivity between use of the API and use of retail sub-accounts and PDQ accounts. Clearly eNom intended for those to be two completely different means of registering domains. If one chooses the API, then it's "in for a penny, in for a pound," I think -- a real commitment.

But what I do think eNom should address is the whole business of a given reseller's retail sub-account customers and/or PDQ customers being able to log-in on any PDQ interface other than said customer's reseller. That, it seems to me, is a biggie.

The whole thing should, in my opinion, be set up like this:

1) Retail sub-accounts manually created by a reseller for use by the customer to log-in directly on the eNom web site should only be allowed to log-in there, on the eNom web site. They should not be allowed to log-in on any PDQ interface -- not even the reseller's, if he has one -- because the sub-account was not originally created in a PDQ interface but, rather, manually, beneath the reseller's eNom account.

2) The creation of a PDQ account should continue to automatically cause a retail sub-account to be created directly on the eNom web site, beneath the reseller account of the PDQ interface's owner, as it is now. But whether or not the customer actually knows that a retail sub-account has also been created should be up to the reseller. The reseller, in the area where he controls the behavior of his PDQ interface, should be allowed to control that. eNom has taken great pains to help the resellers hide from average consumers the fact that they are eNom resellers. Some do not agree with Incognito's thesis about enhancing the customer's comfort level by allowing him to know that he can login directly on the registrar's site. If the PDQ customer is automatically able to also log-in on the eNom web site, he would quickly discover that little secret.

And in any case, a given reseller's PDQ customer should never be allowed to log-in to another reseller's PDQ interface. Ever!

3) A given reseller's customer whose domain names has been given a password so that he can log-in to and manage it using the http://access.enom.com interface should not also be able to log-in to the management portion of another reseller's Registry Rocket interface. Or, if he can, the "renew/extend" option should not appear for him because he's in a foreign registrar's Registry Rocket interface. So that the customer can "transfer" his domain from one reseller to another whether the transferred-from reseller likes it or not -- just as he can freely transfer from one registrar to another whether the transferred-from registrar likes it or not -- the customer should be able to use another reseller's Registry Rocket interface's "transfer" feature. And, thereafter, the customer should be able to log-in to and also to renew/extend in his new reseller's Registry Rocket interface.

That's how I would set it all up if I were the king of eNom. (Wow, that has kind of a mystical sound to it, doesn't it? "The King of eNom." Sounds like something from a role playing game. But I'm rambling... er, even more... now.)

So... okay, I'm done. Someone else's turn.

Hello,

In fact they register and transfer all domains into their own single account with enom.

When you transfer a domain to them all information fields change to namechep.com and you must go and edit them again after transfer.

If you want to access your domain through access.enom.com you must have namecheap's master username and password :)

Originally posted by wmac
If you want to access your domain through access.enom.com you must have namecheap's master username and password.
Actually, that's incorrect. Even if you had the Log-in ID and password to NameCheap's master reseller account on the eNom web site (https://www.enom.com/Login.asp) (something they would not, I assure you, ever let you or anyone else have), it wouldn't do you a bit of good at http://access.enom.com

If you are a NameCheap customer and your domain is, therefore, in NameCheap's master eNom reseller account (which it would, of course, be), then you must ask NameCheap to give your domain its own password -- something they can easily do from within their master eNom reseller account on the eNom web site, but which they may or may not be willing to actually do. And the reasons why are enumerated clearly elsewhere in this thread.

Once that happens, you can manage your domain at http://access.enom.com