hey,

i just installed enom's php api, and it seems everything works properly.
I just emailed Enom and asked them to set up test account for me. I was just wondering if any of you use Enom API and how did you set up credit card processing? Can You please post URL of your web site here (or PM me) and how do you process credit cards? manually, through third-party cc company or your own merchant account?

I know that you can set up cc processing somehow through register.php file but no clue how...

If You can help me set up the API please PM me. I'll pay.

regards,
thomas

Thomas...

I got to the stage where I managed to setup both the Perl and PHP api to work with resellertest.enom.com - I was able to register domain names thru the resellertest account - the problem came when I wanted to test out the CC clearing facilites... I don't have a clue how to go about doing this .... so, I'm stuck as well.

Royong, thanks for info.
Hope someone have clues how to do this and will help us

come on guys, HELP US :D

guys, you need to get some real merchant account provider that also provides API to real-time credit card processing gateway. Then, you need to incorporate it together with enom API:) I hope this helps..correct me if I am wrong

Originally posted by apollo
guys, you need to get some real merchant account provider that also provides API to real-time credit card processing gateway. Then, you need to incorporate it together with enom API:) I hope this helps..correct me if I am wrong
No, you're not wrong. The eNom API, as downloaded from the eNom web site (http://www.enom.com/resellers/InterfaceInfo.asp), is intended exclusively for eNom resellers who wish to sell domains using their own credit card processing merchant account, not eNom's.

The Registry Rocket interface, you might have noticed, looks remarkably like the eNom API as downloaded from its site. That's because the Registry Rocket interface pretty much is the eNom API -- only running on eNom's web site instead of your own. Of course, as such, the Registry Rocket interface uses eNom's credit card processing merchant account. But when you run the Registry Rocket interface on your own server, it's not called Registry Rocket any more. It's called the API. And you have to provide your own credit card merchant account.

That's the first step. And as part of that first step, you need to make sure that the provider of the merchant account has some sort of customizable API of its own that lets your web site communicate in realtime with the provider's gateway. It would be easiest if said API used the same scripting language as the version of the eNom API that you selected. So, for example, if you selected the PHP version of the eNom API, it will be easier to make the eNom API "talk" to the merchant provider's gateway API if said gateway API is also written in PHP. Or, absent an API, the merchant account provider may offer extremely detailed information about what kinds of commands you need to sent to his gateway in order to process orders. In that case you would have to modify the PHP (or the scripting code in whatever version of the eNom API you downloaded) with the commands needed to "talk" to the credit card processor's gateway.

The second step is to get an SSL certificate from Verisign, Thawte or any of the other providers that have been talked about so much in these forums. Do a search and read the threads and figure out which one you want for your site and install it so you'll have the secure socket layer (SSL) running on any of your pages where your customer will key-in personal data.

The third step is to actually make the eNom API "talk" to the merchant account provider's gateway by whatever means it supplied you to do so. And, yes, the register.php file is but one of the places where you'll have to screw around with the code in order to make it all work.

It's not rocket science (no Registry Rocket pun intended), but it's not for the faint-of-heart either. And the fact that there are little peculiariarities in the API code, and that some of it is a little outdated, plus there are things in the API code that simply don't jive with or were written before the existence of some of what eNom's site now says is it's current list of all possible parameters (http://www.enom.com/resellers/CommandManager.asp), plus there are things in the test server that either don't work as they do on the live server and/or flat-out don't work, all come together to make customizing the eNom API a bit of a challenge. It's by no means impossible -- after all, just look at what a terrific job of customizing the API some of eNom's biggest resellers have done. But it can definitely be a challenge. And you should make sure it's one you want to tackle and over which you believe you can prevail before you get too bogged-down in it.

All that having been said, if you're a pretty darned good PHP programmer and you can dig in there and successfully customize the output pages so they look like all the other pages on your site, and if you can keep the transaction parts of things from accidentally creating security issues, it all works pretty darned well. In the end, once you get past the problems, the eNom API is pretty hot and does it's job quite nicely. So if you need it bad enough, and if you're good enough, you can definitely make it worth the trouble.

Nice post DesElms!

Enom should copy it to their reseller web site:)

Nice post DesElms.

There is one thing however I think you are not correct (and note I say I think). I signed also for a Enom reseller account through one of their resellers, and I'm working out the API. It was very easy to setup. What I think is not correct on your post is that you realy can use the CC processing on Enom to process your customers payments. When you use their API you have two options: You use your own processing gateway, and then you have to make a provision for the domains you will buy ($100 I belive) or you use THEIR CC processor and you just pay as you go. In this last option you have to pay a fee (you have too if you use your own CC processor anyway). I got stuked at same point as you guys. Just sent an e-mail to the support to clarify those issues. I will let you know. I belive the trick is to create a Registry Rocket link. It have options to setup a bunch of parameters, including your own prices for each domain TLD.

BTW (off topic) Simon from AQhost is a great guy.

Originally posted by reisve
There is one thing however I think you are not correct (and note I say I think). I signed also for a Enom reseller account through one of their resellers, and I'm working out the API. It was very easy to setup. What I think is not correct on your post is that you realy can use the CC processing on Enom to process your customers payments. When you use their API you have two options: You use your own processing gateway, and then you have to make a provision for the domains you will buy ($100 I belive) or you use THEIR CC processor and you just pay as you go. In this last option you have to pay a fee (you have too if you use your own CC processor anyway). I got stuked at same point as you guys. Just sent an e-mail to the support to clarify those issues. I will let you know. I belive the trick is to create a Registry Rocket link. It have options to setup a bunch of parameters, including your own prices for each domain TLD.
You may very well be correct. My eNom API information is dated since I don't use it. When I first downloaded it, Registry Rocket did not exist. The only option at that time was to use your own merchant account. The only thing I've done regarding the API since then has been to fiddle around with it more and, in the process, discover some of the weaknesses I itemized above. I was mostly concentrating on getting the output pages to match the look and feel of everything else and to do it with some reliability and precision, and I was experimenting heavily with commands that are now listed on the eNom site's command reference, but which are not even used in the API that you can download from eNom. Actually, that part of it was what I was doing more than anything else... seeing what else was possible, in effect. In the process of all that, I never circled back and even bothered to notice if eNom had begun offering its merchant services to API users. I don't remember reading anywhere that it was, but for all I know you may be right. Let us know here what you find out about that, okay?

But even if you're right, I still contend that eNom's API was created with the intention of allowing resellers to sell domains on their own sites using a backend that properly communicated with eNom's registration system, and eNom intended -- at least what that API was written -- for its resellers to use their own merchant accounts. And while, if you're right, that last part may have changed to now include either their own merchant accounts or eNom's merchant account, I'll tell you that the API has not changed as a consequence. It's the same one they offered a long, long time ago. Or, if it's different, it's certainly not different in the area where the CC processing is handled.

Originally posted by reisve
BTW (off topic) Simon from AQhost is a great guy.
I don't know Simon. But I've exchanged posts with him in other threads. And I've snooped around his web site a bit. And from all indications, you would appear to be correct. Or at least that's the opinion to which I'm rapidly coming.

I only know this one they are offering. And you are right: On the API there is nothing to take us to their CC processor. However there is nothing also, to set up URL forwarding, and you can offer that to your customers. Looking again to the downloaded files, they called the directory where the scripts are, Sample Site. Maybe it is just that. And one thing they keep saying on their site is you can write your own scripts with the information they give about the commands. Maybe it is only that: a sample site to help you writing your own API.

Anyway, did you manage to have your own API working?

Originally posted by reisve
Anyway, did you manage to have your own API working?
I got all the basics working. In other words, I got the basic scripting that comes with the API to do what it was advertised to do. I got the sample site to work and I got the scripting to work with pages of my own design. And all the management stuff worked, etc., etc. It was rough getting there, though. And that was a while ago. I have no idea if it would work now. Some things at eNom have changed a little since then. But I think it would and, if not, would only require minor tweaking.

But domain registration is such a tiny part of my business. I am by no stretch of the imagination a "big" eNom reseller. So the API just didn't seem worth the trouble in the end. Registry Rocket fills the bill for me nicely -- butt ugly though it may be. I usually don't have to sell my clients on using me for domain registration. Most of them are only referred to my pages where they can register domain names after they ask me how to do it. They're buying from me because they're already clients in other areas and, therefore, already trust me. So it doesn't matter to them that the look and feel of the interface would gag a maggot.

And for as few domains as I register, paying eNom a little more for merchant services than I could get myself elsewhere is just no big deal. Having that whole thing be "turnkey" really, really appealed to me. It freed me up to worry about other things while still allowing me to offer the service when I need to.

And for precisely the same reason(s), PDQ appeals to me even more. The turnkey nature of it is exactly what I need so that I don't have to screw around with precisely the thing we're talking about, here: eNom's little API and all its peculiarities.

I think there are others who agree that eNom's API is clearly okay and that, with enough TLC, it would work just fine. But many of them decided, in the end, that it's easier to just use one of eNom's tools and be done with it. I think with the advent of PDQ, we'll be seeing even more of that, frankly.

And I think I remember Chicken, for example, saying in another thread a while back that he, like me, certainly liked the idea of the eNom API, and he could clearly see that it would work if he spend enough time fiddling around with it, but in the end he found it to be just squirrely enough that, in light of eNom's other tools, he started to ask himself why he was even bothering. That's a gross paraphrasing of his viewpoint, of course. And I may have misunderstood him. So, Chicken, if you're listening, chime-in, here. And please forgive me if I misstated your opinion on the matter. If so, please set the record straight.

Originally posted by reisve
And one thing they keep saying on their site is you can write your own scripts with the information they give about the commands.
So are you saying that that suggests to you that, when it comes right down to it, that's probably the best approach? If so, I think you're closer to being correct than you realize. One approach, if you're a good PHP, Perl or ASP coder, would be to dig-in to eNom's command reference and compare it with the code in the eNom API and do some experimenting and get to the point where you truly understand how to "talk" to the eNom system. Then develop a generalized script that contains in it handles to every single eNom command and which uses easily-created template files with special tags for output. Then you'd have a flexible API of your own -- more flexible than eNom's, I'll tell you -- that you could not only use yourself but maybe even sell to other eNom resellers who discovered, as you are discovering, that the eNom API is good but not great and requires a great deal of fiddling around with to make work properly.

And, okay, I admit it, that's sorta' what I had in mind to do back when I had more time and I was fiddling around with the eNom API. I saw a niche and I thought maybe I could fill it. I was even going to build into it turnkey, plug-and-play interfaces to the top five or so payment gateways. And then sell the thing for $49.95 or something like that. But, again, that was a long time ago.

And if you were of a mind to steal that idea (and you're welcome to), I would strongly advise that you hold-off until we see what this new .NET version of the eNom system (that they've got in beta right now) is all about and how, if at all, it will affect a reseller's ability to communicate with the eNom system using either the API or custom-built code.

Just my .02 worth.

Writing an API from scratch is something that crossed my mind already. I did it (almost finished) for another domain registrar. Quit when I found the results I was getting from their test server were not what they were supposed to be and even their own API didn't work. The support was very helpfull but we couldn't sort out the problem. That was when I found this new reseller. It was only yestarday... so, I may end up writing an API from scratch for Enom. Selling it?? It is agood idea...

Originally posted by reisve
Writing an API from scratch is something that crossed my mind already. I did it (almost finished) for another domain registrar. Quit when I found the results I was getting from their test server were not what they were supposed to be and even their own API didn't work. The support was very helpfull but we couldn't sort out the problem.
I think you'll find that eNom's servers will respond better and once you get past the fine tuning it will all work fine. Be aware, however, that there are things on the eNom test server that behave in ways that the real server does not behave. That will definitely throw you off. It's not insurmountable, and there's a guy whose alias/handle (whatever you want to call it) in these forums is "lbeachmike" who says he's done a lot to make eNom fix a lot of what's been wrong with the testing server. He's one of those kind of guys who rides 'em 'til they submit. And I think he's gotten a lot of the test server cleaned-up. So my warning, above, may not be as relevant now.

Originally posted by reisve
That was when I found this new reseller. It was only yestarday... so, I may end up writing an API from scratch for Enom.
Yeah, well... if you do it, begin at the very beginning making everything so flexible and modular that it will appeal to as many different kinds of resellers as you can imagine. So it will be complete, include handles to every single command in the eNom reference, including switches to control variables. Obviously some commands will never be used by most resellers. But include 'em anyway.

And keep in mind that some may never work right. AQHost mentioned a command in another thread that he's had a lot of trouble getting to work. You might want to chat with him about eNom commands that seem like they're gonna' work and that tech support says should work but, for some reason, just don't. Gratefully, there aren't a lot of those.

Next -- and this is really important -- to make it easy for the reseller to make the script kick out results pages that truly seamlessly integrate with the reseller's site, you need to create a cool system of results field and location tags that can easily be plugged into, and in any place on, any web page. A series of generic template pages should be included, either for demonstration, or for actual use, or both.

Also, just as a matter of practice, make the script read server- and account-specific variables from external text files so the reseller never has to modify the script itself. Better yet, make the script read variables from a comma-delimited flat database text file so you can create a series of web pages that are driven by yet another script -- could (and probably should) be a Perl script -- that reads from and writes to the flat database text file so you can have a web-based configuration interface.

Next, search in these forums and figure out the top five credit card payment gateways that everyone uses and build right into the script that ability to plug right in to any one of them. In fact, store the different gateways' methodology and account variables in that same comma-delimited flat database text file so the reseller can simply use the aforementioned web-based configuration interface to specify which payment gateway is being used and can then be taken to another page where he can key-in his the account information for said gateway and it's all written to the flat database text file.

Finally, ask someone like me -- in fact, just ask me -- to write the user manual for it so that the damned thing will practically sell itself; so that there will be so many useful analogies, plain-spoken conceptual explanations, and practical illustrations, that a reseller would have to be brain damaged not to know how to use it. And also so that you won't have so many support tickets.

Originally posted by reisve
Selling it?? It is agood idea...
Well, when you're all done and if you do decide to sell it, call me, because I know a sure-fire way that I'll bet a thousand bucks you haven't thought of and never would. And, no, I'm not gonna' tell you what it is here and now, so don't ask. Just build it, if you think you can. Then call me and I'll see to it that they will come. And if I'm wrong then I'll buy ya' the Director's Cut DVD edition of Field of Dreams so you can at least see an example of where that whole "build it and they will come" thing actually worked out for somebody.

:D

Don't worry with me. I know what I'm doing. But no. I will not use coma-delimited databases or text files. Neither will use Perl.

I'm going to to use PHP / MySQL.

Since my early days of web progammer when I had modify the configuration of one of my first scripts that I learned that there are files called config.pl, include.php init.cfg or whatever you want to call it. And latelly I learned another thing: settings table. Isn't this nice.

Thanks for your offers. If I go ahead, you can be sure I will contact you.

Originally posted by reisve
I'm going to to use PHP / MySQL.
PHP: Fine. Presumably the rest of the API would be in PHP, so it makes sense that the script that drives the configuration utility should be in PHP as well, I suppose. No biggie.

MySQL: I wouldn't. For starters, it's just a configuration file. It's not fancy. It will never get large. And, most importantly, some of the resellers who would buy this thing are on shared hosting servers. Most of them are just resellers of hosting services themselves and don't own their own server. And, as such, they may have to pay extra for more than 1 MySQL database. You'd be asking them to waste one on a mere flat configuration file that probably wouldn't even be 100K in size.

I'd re-think that one if I were you. But that's just me.

Originally posted by DesElms

... they may have to pay extra for more than 1 MySQL database. You'd be asking them to waste one on a mere flat configuration file that probably wouldn't even be 100K in size.

Take a look around all of the offers for reselling or just hosting here on WHT: unlimited MySQL. But that is not the big issue. Would you store a password on a text file? Not me. I did it for some time untill I get my hands on MySQL but not anymore.
A database doesn't solve all security problems, but for sure it is a lot more secure than just a comma-separeted flat database.

Originally posted by reisve
Take a look around all of the offers for reselling or just hosting here on WHT: unlimited MySQL. But that is not the big issue.
People (and it's happened to me, too, so this is not pointing the finger at you) who spend a lot of time in these forums and who become accustomed to the prices they see for things here get their perspective distorted. All the best deals are concentrated here. Spend enough time here and one begins to think that what's here is the norm; that what we see here is what the average customer sees. Thousands of virtual hosts charge extra for additional MySQL databases. And that's just a fact. But it's a fact that is taking us widely off topic.

Originally posted by reisve
Would you store a password on a text file?
In a heartbeat. The format of a file -- even if encrypted -- cannot be its protector when all it's doing is sitting on a hard drive. If the intruder can see the file on the drive he has won, no matter what its format. Even encryption only has value at the transport layer.

Originally posted by reisve
Not me. I did it for some time untill I get my hands on MySQL but not anymore. A database doesn't solve all security problems, but for sure it is a lot more secure than just a comma-separeted flat database.
A database-formatted file (as opposed to a text file) doesn't solve -- or even begin to address -- any security problems. In it's stored state, it is no more nor less secure than any other file and is endowed with no inherent, additional level of security because of its format. If one considers a file's format an element of its security, then one has no security. How and where one stores a file -- and the barriers to intrusion that one erects between the medium on which it's stored and the outside world which seeks to find and obtain it -- is what determines whether there is a security problem. Format is irrelevant.