I'll admit that, for the sake of a concise discussion, I glossed over the messy details of how those trust/security logos actually work (and how they can be forged, whereas the padlock icon and https: URLs cannot), but speaking as a former corporate Webmaster for a regional ISP and Web host who was personally responsible for all aspects of SSL enrollment and implementation for both that company and all of its eCommerce hosting clients, I assure you I am quite familiar with the issues.
It's true that the SSL CAs (certification authorities, such as GeoTrust) have a vested interest in pushing their brand and logo onto every page they can, so they strongly recommend to merchants that their trust logos should be displayed on their site. In reality, I have yet to encounter a single end-user who looks for those logos, or even knows what those logos are for exactly, let alone how they work, or how to use them to verify the identity of a site. However, every consumer who at least knows and cares about security, privacy and encryption knows to "look for the padlock", and the tech-savvier ones look for the https: URL, but most tend to regard the logo as nothing more significant than a simple branding display, nothing more.
There are several reasons why the logo would not work as-intended within the context of our system, and this gets into how, exactly, those logos actually work:
When the page is rendered, the IMG tag for the SSL CA's logo calls for that image from a URL on the CA's site. The CA's site first confirms that the base URL (i.e., the fully-qualified domain name, or FQDN -- e.g., "www.e-junkie.com") of the page requesting display of the logo is the same FQDN that logo tag is certifying, and that the same FQDN is actually enrolled for an SSL/trust cert with that CA. For instance, the GeoTrust logo at the bottom of this page disappears for me if I use an alternate domain we happen to have that points to the exact same server. Once all that is confirmed, the CA allows the page to display their logo, usually including a fresh date/timestamp indicating when they verified that the page URL matches the certified FQDN which matches their SSL cert enrollment. Thus, our CA's logo could not be displayed on your own site pages, since our domain and business are the ones being certified, not yours.
Now, any forger could just mockup a logo image with some scripting that throws a fresh timestamp over it on every view, so the CAs also expect users to click on the logo, to get a popup window showing what company and URL/FQDN is being certified by that CA, so users can compare the company name and domain name with the outfit they think they've been dealing with; however, even the popup window can be forged, so you're back to the user having to "look for the padlock" and scrutinize the popup's FQDN and https: URL (if that's even displayed in the browser popup) to manually confirm that the icon and popup are not also forged.
In theory, if you were operating every aspect of your own shopping cart software in-house yourself, you would have a consistent domain in your URLs across every phase of the buyer experience -- from shopping to checkout to payment. Buyers could visually confirm that they never left your site, the domain is always the same, and particularly on pages where they are providing financial or other private data, they could verify that same, consistent domain is owned by a legitimate business identity which has registered with that CA to obtain an SSL encryption/trust certificate, which same cert is encrypting that very page where they are providing their sensitive data.
Now, with E-junkie's service, we relieve you of the burden of administering your own shopping cart software installation and maintaining your own SSL cert, since you are using our remotely-hosted cart software which uses our own SSL cert instead of yours. We conceal most of this "cart outsourcing" from your buyers by having the nice cart screen that overlays your own pages, which hands the buyer off to a third-party payment processor (PayPal/Google/etc.), so in most cases our cart is not even handling any sensitive data nor transaction funds -- the payment processor is handling all of that data, and they already have their own SSL cert and CA logos in full effect on their own checkout pages.
The only place where an E-junkie cart page would be accepting sensitive data directly would be for Merchants who are using either PayPal Website Payments Pro or Authorize.Net to accept card payments directly. In those cases, we certainly display our own GeoTrust logo on the payment-info checkout screen; despite the fact that the E-junkie business name and the https://www.e-junkie.com/... URL do not match that of the actual Merchant, at least we can backup the fact that we are indeed using SSL encryption to handle their transaction data, and that our business is indeed confirmed by that CA as a legitimate legal entity which owns that domain.
