Accepting posted variables to order, bypassing step 2, and passing vars throughout?

[Tim Greer]

Since I'm unwilling to pay huge fees for a registrar API, and have credits I might never have used (or worse, have too many illegitimate orders taking up all the credits and not enough time to fund the credits before a legit order comes in (and before a credit back after canceling)), I'm using the WWD storefront for reselling domains and SSL certs. This allows me to offer the cheapest price without all the concerns (and let's the clients order them on their own, separate from the hosting service offered). That all said, here's the problem:

 

I have a rewrite conditional for step 2, so it actually uses a different script for domain registration, transfer or "use my own domain" requests. This allows for better control and security, and I have my script actually check the WWD site itself and see if the domain is available and automatically capture the current price (and savings from the normal suggested price I'd be offering). That all works great. I can keep the group and product id's set and pass them around and then post this (the domain now set) to step 3. There is the problem though, the compiled order.php script dictates that someone *has* to go through the actual step 2 order process (and not the bypassed script I've created to work seamlessly), or the order will not be valid and no product, domain or pricing will show.

 

I can post values directly (via GET or POST) to the (real) step 2 order process and it will read in the group (gid) and product (pid), and that's where it starts creating the needed Smarty session for the order to be valid. What I need to do for this to work, is have an option where I can make it so step 3 can have variables passed to it (via POST or GET or otherwise), so I can simply pass the same variables as I did to step 2, to step 3 (being just the additional "domainoption", "sld[2]" and "stld[2]" variables/values to be read into step 3). I have it all set for "owndomain" even though it works for new registrations and transfers (later, after the order complete display). This keeps new clients from getting confused if I force them to first register their domain off the order form.

 

I'd prefer to have a variable I can also pass throughout the steps, such as "domreg" (for example), so I can keep track of the initial "this is a new domain they need to register" conditional. I can't enable the TLD prices since I don't use an API. I want clients to order and control their domains without feeling forced to move to or register with us anyway, so this would work out nicely. With this option, if the domain name variable itself can be passed, I can run a template conditional against it such as {if $domreg}form to Register your domain now! URL?domain={$domain}{/if} (just for an example).

 

I also can't set prices for the TLD's, because I can't charge them unless I register it, and without an API, I'd have to use my own financial information to pay for it (God forbid they do a charge-back (not that I'd expect this, but some people are unreasonable and scammers)), and I'd have to either provide access and explain to them about a new WWD account (that has my payee information on file), or have them register a GoDaddy/WWD account and go through the hassle of explaining to them and transferring it to them. Obviously, a domain registrar API is looking more reasonable all of the time, but Enom wants $1,499 of credits (Chuck-E-Cheese tokens I may never use, as far as I'm concerned) for their lowest API plan and my domain base price is $3 higher each than I get from WWD without any pre-purchase credits. To get the pricing I get at WWD, it would cost $6,999 of credits! Also, I'm still concerned about potential abuse (it can happen, albeit unlikely).

 

So, the changes I'm looking for are very simple and quick, but obviously it deviates from the WHMCS default and design. I've already taken an hour or so earlier today and created all the initial frontend logic for the domain checks and so on, but I can't post to step 3 due to Smarty sessions being unique to the compiled order.php's code, so it can only create a new, unique session, which won't work with the later order step(s). I've even played around a little by using some iframes, JS onloads, Ajax and other various calls to have the script itself make the request to the "real" step 2 process order URL with the appropriate variables/arguments passed in the query string/URI and POST, both for the script itself and the client, but again, it has to be the client directly accessing it, and the session will be uniquely different anyway. Besides, I'd still like that final "order complete" simple logic available.

 

Is there some way to pull this off that I'm unaware of, or perhaps some way I can pay to have such a quick/easy mod performed? It's really that easy (accepting posted vars to step 3 and not requiring step 2 to start the Smarty session), not having to enable any other options, simply pass a variable between the scripts with a $smarty.post or $smarty.session variable, and just have two variables available for the order complete Smarty template driven script so I can work with those variables. In all, if the code wasn't compiled, it would be a 5 minute task, but since it's limiting what I can do with the code as is, I'm curious if I'm missing something (if there's a way), or if this can be something someone with the power to, can add/mod (for a price)? I really like a lot of things about WHMCS, but this is definitely a frustrating and limiting aspect that I'd be very happy to see as a viable option.

 

For now, I hate that I have to do this, but it looks like I'll have to set a pre-order domain check, ask them to make a note and fill that in upon ordering, and then again by linking to the storefront and hope it doesn't piss them off. Anyway, I realize this is long, but I wanted to provide all of the details about it, even if it's a pretty simple request. Any idea if this can be accomplished now, or in the near future, or is that just it then and I'm forced to use an API from a registrar that WHMCS supports because I can't pass variables to step 3 like I can to step 2? Thanks for any insight, suggestions or whatever you can.

[sparky]

Why not just put your code in configuredomains.tpl

 

Remember the old order.php is being replaced with cart.php for V3.7

[othellotech]

Only WHMCS can answer the questions about the code changes - I'd suggest raising a support ticket for their sales dept, rather than waiting on a forum reply

 

Chargebacks/fraudsignups do happe, although IME no more frequently than they will with the hostinganyway, banning free email services, implementing maximind etc will cu that down considerably.

 

Suggestions...

you could just say you dont offer domains and have a link to your wwd store and remove it entirely from the equation regarding the order process - that way you pas all the domain tasks off to the 3rd party

 

if you really dont expect to do enough domain per year to warrant a large "deposit" amount or an annual fee for an API (if keeping the same registrar) then perhaps the WHMCS free Directi account or a free enom reseller from an ETP would help - yes the domain may be a couple of $ more, but when the volume is < 30/year its unlikely to make much difference

 

neither are ideal solutions, but would allow you more control and automation, saving you time (and therefore money)

[Tim Greer]

Why not just put your code in configuredomains.tpl

 

Remember the old order.php is being replaced with cart.php for V3.7

 

Unfortunately that won't work. However, I'm going to test out some ideas today. Thanks for the suggestions.

[Tim Greer]

Only WHMCS can answer the questions about the code changes - I'd suggest raising a support ticket for their sales dept, rather than waiting on a forum reply

 

I had done that, but figured I'd see if anyone had an idea here as well, so I don't have to bug them about it (I'm sure they're busy enough). The person that answered today didn't know what a Smarty session was and suggested I use a session variable, so I'm not sure where to go, but I'll try some other ideas today and see what I can accomplish.

 

Chargebacks/fraudsignups do happe, although IME no more frequently than they will with the hostinganyway, banning free email services, implementing maximind etc will cu that down considerably.

 

Yeah, but with hosting, I don't have a pool of credits that can run out and I can simply terminate the account, but I do implement all of the appropriate checks and I didn't think it would be likely, it was just one of a few ideas that turned me off on the API.

 

Suggestions...

you could just say you dont offer domains and have a link to your wwd store and remove it entirely from the equation regarding the order process - that way you pas all the domain tasks off to the 3rd party

 

Ultimately, this is what I might have to do, but I was trying to avoid them going off site, even to the WWD storefront). Out of all of the years I've been doing web hosting, I have seen that the chances of a client going off site for any reason pre-order, will increase the chances of them being confused and not finding your site again. So, they get a domain and then have to look for a web host again. WWD's storefront is okay, but the fact I offer SSL certificates forces a link at the top of the storefront that says "Web Hosting" (not mine). I could certainly remove the SSL certificate option to remedy that problem, but I don't believe it makes it easy to go back to the hosting site or order form (everything is static for links, and after the order is completed for a domain, the line on the site is pretty far down the page and small that says "Go back to $company_name").

 

Obviously none of this is a massive issue, but it can potentially be significant enough to lose a certain percentage of orders if clients get confused or have to do too much and are taken off the site. This is why I'm okay with how they access the storefront, after the order is complete or they've been invoiced. That way they've signed up, get an email and know how to access the site, remember who they're hosting with, etc. I've seen it happen too many times to count, with some major web hosts I've worked with over the years, so I'm just trying to anticipate that scenario and avoid order losses and client confusion.

 

if you really dont expect to do enough domain per year to warrant a large "deposit" amount or an annual fee for an API (if keeping the same registrar) then perhaps the WHMCS free Directi account or a free enom reseller from an ETP would help - yes the domain may be a couple of $ more, but when the volume is < 30/year its unlikely to make much difference

 

neither are ideal solutions, but would allow you more control and automation, saving you time (and therefore money)

 

I appreciate the suggestions, and I've already considered doing something such as this before opening tickets and posting here, but thought I'd try for a more seamless method. It's just that enom's lowest price is too high for what you get, but I might just have to do it anyway and avoid all of these issues. I did check out and even signed up for the Directi API account, but didn't really like what I saw and didn't use it. I'm just not a fan of the credits the API's all want you to have (I understand why it works that way) However, if it can solve the issue, even if the domains are a little more per year, I might just end up doing that. I'll have to check into it more if my mods to the order today don't give me the results I want. Again, thanks for the suggestion, and I'll likely go with the Directi API if this doesn't work and I want that intergration.

 

I guess we can consider this thread dead/closed now, since there's really nothing anyone on the forum can do, like you said. Thanks everyone.

[Tim Greer]

Just an update; I spent a little time and I figured out a work-around and it's working exactly how I want. It was a little bit of a hassle, but it is completely seamless and works perfect. I still need to do the conditional in the "order complete" template, but I can now set a method in the new "step" I've put in-between to allow for a way to check that. Cool.