Page 1 of 2 12 LastLast
Results 1 to 40 of 51
  1. #1

    Question Namecheap - Enom

    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 ?

  2. #2
    Join Date
    Jun 2001
    Location
    Earth
    Posts
    1,258
    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
    Umbra Hosting
    cPanel | Softaculous | CloudLinux | R1Soft | Ksplice
    Web Hosting, Reseller Hosting, VPS, Dedicated Servers, Colocation
    UmbraHosting.com

  3. #3
    Join Date
    Oct 2000
    Location
    Israel
    Posts
    1,286
    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.

  4. #4
    Join Date
    Apr 2001
    Location
    Napa, California
    Posts
    341
    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.
    Gregg L. DesElms

  5. #5
    Join Date
    Jun 2002
    Posts
    134
    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...

  6. #6
    Join Date
    Feb 2001
    Location
    Atlanta. Georgia
    Posts
    252
    Tried all of mine registered through NameCheap and got the same result - couldn't login in through access.enom.com .
    Peachtree WebWorks, LLC
    http://www.peachtreewebworks.com

  7. #7
    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.
    http://www.AQHost.com
    Fast, reliable dual Intel Xeon servers
    Excellent uptime record
    Efficient and friendly support

  8. #8
    Join Date
    Jun 2001
    Location
    Earth
    Posts
    1,258
    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
    Umbra Hosting
    cPanel | Softaculous | CloudLinux | R1Soft | Ksplice
    Web Hosting, Reseller Hosting, VPS, Dedicated Servers, Colocation
    UmbraHosting.com

  9. #9
    Join Date
    Feb 2002
    Posts
    956
    access.enom.com dun work with registerfly also
    This forum officially ****ing sucks

  10. #10
    Join Date
    Jul 2002
    Posts
    955
    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.

  11. #11
    Thanks for clearing the doubt for us

  12. #12
    Join Date
    Jun 2002
    Location
    Long Beach, NY
    Posts
    199

    access.enom.com

    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

    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

  13. #13
    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

  14. #14
    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.
    http://www.AQHost.com
    Fast, reliable dual Intel Xeon servers
    Excellent uptime record
    Efficient and friendly support

  15. #15
    Join Date
    Jun 2002
    Location
    Long Beach, NY
    Posts
    199
    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

  16. #16
    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.
    http://www.AQHost.com
    Fast, reliable dual Intel Xeon servers
    Excellent uptime record
    Efficient and friendly support

  17. #17
    Join Date
    Jul 2002
    Posts
    955
    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

  18. #18
    Join Date
    Jun 2001
    Location
    Earth
    Posts
    1,258
    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
    Umbra Hosting
    cPanel | Softaculous | CloudLinux | R1Soft | Ksplice
    Web Hosting, Reseller Hosting, VPS, Dedicated Servers, Colocation
    UmbraHosting.com

  19. #19
    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.
    http://www.AQHost.com
    Fast, reliable dual Intel Xeon servers
    Excellent uptime record
    Efficient and friendly support

  20. #20
    Join Date
    Apr 2001
    Location
    Napa, California
    Posts
    341
    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 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 (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?
    Last edited by DesElms; 07-02-2002 at 05:32 PM.
    Gregg L. DesElms

  21. #21
    Join Date
    Jun 2002
    Location
    Long Beach, NY
    Posts
    199
    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
    [email protected]
    Last edited by lbeachmike; 07-02-2002 at 06:02 PM.

  22. #22
    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

    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.
    http://www.AQHost.com
    Fast, reliable dual Intel Xeon servers
    Excellent uptime record
    Efficient and friendly support

  23. #23
    Join Date
    Jun 2001
    Location
    Earth
    Posts
    1,258
    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
    Umbra Hosting
    cPanel | Softaculous | CloudLinux | R1Soft | Ksplice
    Web Hosting, Reseller Hosting, VPS, Dedicated Servers, Colocation
    UmbraHosting.com

  24. #24
    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

    Best wishes,
    Simon.
    http://www.AQHost.com
    Fast, reliable dual Intel Xeon servers
    Excellent uptime record
    Efficient and friendly support

  25. #25
    Join Date
    Jun 2002
    Location
    Long Beach, NY
    Posts
    199
    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

  26. #26
    Join Date
    Apr 2001
    Location
    Napa, California
    Posts
    341
    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.
    Last edited by DesElms; 07-02-2002 at 10:05 PM.
    Gregg L. DesElms

  27. #27
    Join Date
    Jun 2002
    Location
    Long Beach, NY
    Posts
    199
    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

  28. #28
    Join Date
    Apr 2001
    Location
    Napa, California
    Posts
    341
    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.
    Gregg L. DesElms

  29. #29
    Join Date
    Jun 2002
    Location
    Long Beach, NY
    Posts
    199
    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 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

  30. #30
    Join Date
    Jun 2001
    Location
    Earth
    Posts
    1,258
    Well this has been the most informative thread I've seen here in quite a while.

    Thanks guys!

    Frank
    Umbra Hosting
    cPanel | Softaculous | CloudLinux | R1Soft | Ksplice
    Web Hosting, Reseller Hosting, VPS, Dedicated Servers, Colocation
    UmbraHosting.com

  31. #31
    Join Date
    Apr 2001
    Location
    Napa, California
    Posts
    341
    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.
    Gregg L. DesElms

  32. #32
    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

  33. #33
    Join Date
    Jun 2000
    Location
    Southern California
    Posts
    12,121
    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
    HostHideout.com - Where professionals discuss web hosting.

    Chicken

  34. #34
    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

    Best wishes,
    Simon.
    http://www.AQHost.com
    Fast, reliable dual Intel Xeon servers
    Excellent uptime record
    Efficient and friendly support

  35. #35
    Join Date
    Jun 2000
    Location
    Southern California
    Posts
    12,121
    My guess is that the registration wouldn't work, since they'd be logged into their account which isn't funded.
    HostHideout.com - Where professionals discuss web hosting.

    Chicken

  36. #36
    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.
    http://www.AQHost.com
    Fast, reliable dual Intel Xeon servers
    Excellent uptime record
    Efficient and friendly support

  37. #37
    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...

  38. #38
    Join Date
    Apr 2001
    Location
    Napa, California
    Posts
    341
    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.



    [edit] 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.
    [/edit]
    Last edited by DesElms; 07-03-2002 at 05:41 PM.
    Gregg L. DesElms

  39. #39

    Disturbing

    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.

  40. #40
    Join Date
    Apr 2001
    Location
    Napa, California
    Posts
    341

    Re: Disturbing

    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.
    Gregg L. DesElms

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •