#499545 - 03/14/1002:27 PMRe: Domains and registration
[Re: keymaker]
Ben Dover
Colorectalogist Emeritus
Registered: 06/12/09
Posts: 709
Loc: Sunnyvale, CA, USA
Well, since I know zero about MobileMe, you might want to check if it is a secure site - There's a good chance it is, because of things like Mail, etc. However, it doesn't necessarily have to be secure for an e-commerce storefront, since the sensitive data part of the transactions would temporarily occur on secure PayPal pages before returning to a page on your MobileMe site that you've specified (I would guess that normally would be either the last page or some sort of confirmation page). This secure stuff is pertinent only if you care to bring in a logo image to properly brand your PayPal pages, else the secure PayPal page will throw an erroneous insecure transaction prompt due to images coming in from a non-secure source.
And to correct something in my first post, I believe that Bluehost has a free shared SSL certificate that should suffice for branding images. The free shared SSL certificate works on specific links that you cite, whereas an SSL certificate is domain-wide. Also, a static IP address and an SSL certificate is $75/year.
Website Payments Standard (IIRC, that's what it's called) is a "free"/pseudo-"free" PayPal service whereby they charge you a decreasing cut of sales, depending on volume (ranging from 2.9%-2.2%, IIRC). Incidentally, I know several brick and mortar merchants who pay 5-9% ( I think there's a guy who pays 13% ) on their merchant account, so PayPal's vigorish/juice/take is eminently reasonable.
I know little of Website Payments Standard, however, but basically that's how it works. This would be the way to go if you don't have a tremendous amount of product, or product change occurring, such as a high volume of new products occurring regularly. If your product lineup or changes are small and/or lean more towards the static versus dynamic on a scale, this is probably the way to go.
Basically, what's different in the customer interface is the checkout experience. With Standard they checkout at PayPal then return to your site. With Pro they checkout on your site.
However, the difference to the website/shopkeeper is significant between Website Payments Standard and Pro.
Both charge a reasonable vigorish/cut per transaction. Standard has a $0 monthly fee, i.e., basically free except for vigorish. Pro has a $30 monthly fee in addition to the vigorish.
Both accept major credit cards as well as PayPal payments.
However, with Standard, PayPal maintains the sensitive customer information, but with Pro, since the entire transactions occur on your website (with PayPal processing it invisibly in the background), you the website owner shoulder the burden (and real/legal fiduciary responsibilities and liabilities) of sensitive customer information. So, although Bluehost webserver accounts are defaulted reasonably secure and hardened, a little additional incentive/subject matter familiarity on your part would be recommended (regarding additional hardening directives you can take with the webserver software and the e-commerce software you elect, databases, via .htaccess and php.ini).
Checkout pages (per product or per cart) with Standard are made on PayPal, and when last I used Standard (some time ago), the make-ready process was more convoluted than making them up in the storefront side (e-commerce software, or html store pages such as you would have in MobileMe, as you would be able to do with Pro), so checkout pages in Standard require a little more effort. However, with Pro, since the entire transaction occurs on your website, the checkout pages are made up in the e-commerce software (very simple and low effort) or in the case of MobileMe, on the page, in html/iWeb/whatever (again, much simpler than making them up in your PayPal Website Payments Standard account). However, it's not as bad as it sounds, to make up pages in PayPal - But, if there's a lot of product, it goes much faster and easier to make them up in e-commerce software or something like iWeb or a CMS/DreamWeaver/whatever, than in PayPal, so if you want to do that (lot of product, faster, easier), that onsite make-ready only happens with Website Payments Pro.
E-commerce software makes everything easier, simpler and faster, if you have a lot of stuff to sell, but normally does cost you that monthly Website Payments Pro $30 charge (I'm not totally sure if that's entirely accurate, though - You would want to research various softwares to determine any that support Website Payments Standard). Perhaps even OpenCart does - I should know that, but don't. Also, I'm not necessarily recommending PayPal, either, but it is the cheapest and is robust and well-featured enough with various management things. Another thing, too, with e-commerce software (well, I'm talking OpenCart here) is the flexibility, especially regarding things like myriad shipping things, using and applying coupons, various discountings, etc. The make-ready for that stuff in DreamWeaver, a CMS, iWeb, whatever is a little more daunting. However, for a fairly simple e-commerce thing, not an extremely large number of product or changes in the product lineup, fairly static shipping options, no coupons or other discount things, etc, Website Payments Standard in conjunction with just making up a storefront and product pages in iWeb, Dreamweaver, a CMS or blogging platform, whatever is good enough.
Boy, I have really failed at stating this stuff simply
Ed
Incidentally, in the event that you do spring for Bluehost or any other shared server hosting, and elect e-commerce software, install it into a subdomain of your main domain, instead of into a subfolder of your main domain.
To a visitor, in the browser, a subfolder installation would look something like this: http://domain.com/store.
The difference in the actual directory structure is this
For a subfolder installation:
public_html or www (this is your website root level, which is one of many other folders {such as /etc, /mail, /tmp and files at your user/home folder level)
domain
store
For a subdomain installation:
public_html or www
domain
store
The reason is that if you elect to have a dynamic site utilizing a CMS or any other database-driven software (such as a blogging platform like Wordpress) for your main domain, some CMSes such as Drupal are strict about their structure and reject/disallow a "foreign" folder in their CMS structuring scheme, while other CMSes that allow that can get confused by another database-driven installation within their installation, i.e., major conflicts can happen. The ModX CMS has no problems with other database-driven installations within its installation, however it is still good practice to have disparate database-driven installations independent/wholly isolated from each other.
To a visitor, the subdomain is linked/whatever to your main domain via host's NAT, DNS mapping, etc, if you've properly added the subdomain, rather than just creating a new folder at public_html/www root level (which doesn't get associated with any re-mapping).
If your main domain is just going to be static html, such as with Dreamweaver, iWeb, hand-made-up html, then it doesn't matter whether you install e-commerce software into a subfolder or a subdomain.
#499634 - 03/15/1012:01 PMRe: Domains and registration
[Re: Ben Dover]
keymaker
I invented modding!
Registered: 12/14/07
Posts: 5916
Thanks again - everything is noted. I spoke to Bluehost today on their live chat system which was pretty cool... looks like there are no international probs so I'm going grab my domain with them. Unfortunately com and co.uk have gone but I can get org.