Fraud is not the same thing as incompetence.

I've used them for a few personal sites and projects with no complaints.

The fee for wildcard certs (~60USD) is a one-off to verify your identity - usually via a quick phone call to confirm details from your official documents.

Once that's complete, you can generate as many certs as you need (incl. wildcards and Subject Alternative Name) from their control panel, subject to jumping through the usual hoops to prove that you have control of each domain.

I'd not picked up that the wildcard fee was a one-off - that makes it all the more attractive.

I do use StartSSL but the problem just comes from having multiple sub domains. I get IPv4 addresses for $0.50/mo/each but I'd rather not setup each subdomain on its own dedicated IP for the sakes of using free SSL certs.

You don't need multiple IPv4 addresses to make use of a wild-card (or other multi-name) certificate. A wildcard certificate will verify any matching domain so you could have many sub-domains of the same domain (using a single certificate for *.domain.tld) on one address and browsers would not complain.

Also you could run the distinct (sub)domains on different ports on the same address, though this is perhaps less useful.

Also, with SNI you can use many single-name certificates on one address (and all on the same port) using SNI. Unfortunately there are a number of significant client combinations that won't play nice with this (most notably, if you can't guess, IE on Windows XP): http://en.wikipedia.org/wiki/Server_Name_Indication#Support

I know that. I'm saying I don't want to have to pay for a wildcard certificate since you can get free certs for individual domains. The alternative for me purchasing a wildcard domain would be to get many different single domain certs for free and assign each one to a different IP address.

Nice game - how much work is something like this?

I like how the controls/movement are precise yet just forgiving enough.

Only thing, I'm not hearing any music (Chrome 11 beta, OS X).

the music server overserved its quota. for a 300kb song file, it reached 1 GB pretty fast!

I;ve just increased the quota, it's running great

I'm running Chrome 11 beta on OS X and I can hear the music.

Game has a great old school flair btw, well done!

about 3 months of work (from the very beginning of opening the manual)

I tried this and an extra field appeared above the URL allowing me to specify a value for HTTP_HOST.

Very handy - worked well for a couple of simple rules; it'd be good to see more feedback when it can't handle something (e.g. feeding it the rules from http://stackoverflow.com/questions/992565/why-isnt-this-rewr... just results in a greyed-out URL field).

Trivial nit: backslashes are doubled when rules are restored from the session.

Thanks for the feedback, should have a fix up shortly for the backslash problem and will try to improve error handling in the UI some more. That SO thread looks like a great resource for gnarly rulesets to test :)

Would advertisers be happy paying for ads that'll only ever be seen by users with a track record of not paying for stuff?

Yes. People don't believe ads work on them

Apparently, everyone's copying Google's layout.

Talk to your acquirer - they're the ones who'll be enforcing PCI-DSS compliance/certification on you if required, not the gateway.

> I've outsourced each and every bit of the handling and processing to third parties, we still get hit with the chargeback penalty.

Ignoring the flaws in most current implementations, isn't this the kind of thing 3D-Secure (VBV, SecureCode, etc.) is supposed to reduce?

Using VBV just reverses the penalty of abuse on to the user instead of the merchant, because it is 'secure', whatever that means. If and when it will be hacked there will be a bit of a problem.

I helped a friend that runs an IPSP implement it, the spec is so large and convoluted that there's bound to be holes, so the flaws in the implementations are a problem but flaws in the spec are likely to crop up as well.

I thought a merchant implementing 3DS wouldn't receive chargebacks if a customer denies placing the order, since the issuing bank has performed "enough" authentication to satisfy themselves that the transaction is legit.

If that's the case then, holes aside, it makes sense for a merchant to integrate 3DS to reduce chargebacks (not to mention some acquirers charge lower rates for VBV payments, which can help offset PSP fees). But your earlier comment suggested that you were still being stung for chargebacks - I'd be interested to know why.

(and yes, it's a lot of spec for what's essentially 3 XML request/response pairs, but that's the payments industry for you - you'll know what I mean if you've had the joy of ploughing through APACS-70 or its predecessors...)

Given that the solution suggested by the article is to use a gateway (with a payment page, instead of forwarding CC numbers yourself), the gateways stand to make more cash, especially since some charge more for storage (which you'll need for recurring payments).

Having said that, merchants at the level 2-3 size often won't have renegotiated rates agreed with their acquirer back when the merchant was smaller - doing so can soften the impact of outsourcing capture/storage considerably (perhaps even pay for it completely).

Agree that merchants should read PCI-DSS, but smaller shops may not have the expertise/time to realise/handle the implications (do you record telephone calls from customers, for instance?). For any size of merchant, to be able to say "we're unlikely to be breached as we don't store card numbers" is a good thing indeed.