22 Nov 2004: Starting with PayPal - Part IV
(discuss)(cf. #5, #3, #2, #1) Another day, another 5 dollars. Another customer who didn't get what he expected.
I'd missed out a "." (which does a string concat) in the PHP code, so instead of providing the download link, it simply reported the error
"Parse error: parse error, unexpected T_VARIABLE, expecting ',' or ';' in paypal_confirm.php on line 86".
Nice.
To fix it, I've updated my test "fake-paypal" page which calls it, since testing the full config with PayPal would cost me more than I'd get from selling the book (for the price of a pint!) in PayPal fees. I do think that it finally works now, but so far I've sold 8 copies of the book, and none of the transactions have gone smoothly. One of those was fraudulent, so I didn't get the money; the first few didn't realise that they wouldn't get a downloadable file immediately (it was a "pay now, get it by email within 24h deal" to start with). Then, once I got the download stuff going, 3 people bought it and didn't get a downloadable link.
That is incredibly unprofessional.
I seem to have got away with it, and the customers who had problems were incredibly helpful to me in telling me exactly what went wrong. Without that "at line 86" message, it would have taken me a lot of work to identify the problem. The customer went to the trouble of going through his browser cache to find the error message for me.
How have I got away with this "let the customers test the system" approach?
I believe that there are 4 key factors which have allowed me to get away with such unprofessionalism:
- Credibility - I freely admit that the content available is the same as that which is available online. Google
ranks my page highly (normally #1) for "bourne shell" and similar search strings. I'm not some midnight cowboy
with a "judge the quality once I've got your cash" deal. I'm one of those old-school types who makes useful information
available to all comers. The website is based around being useful - the purchase option is exactly that - an option
for those who want it. Google will reliably drive more traffic to your site if it's genuinely good, than if it simply
matches a few keywords. The so-called "Search-Engine Optimisers" are a hoax; if your site is of good quality, you can
expect decent search engines to rank it appropriately.
- Content - This doesn't even need to be related - a link from steve-parker.org (mainly about shell scripting) to itops.com/sysview/ (a product which produces excellent reports on Solaris systems - Mac OS X support coming soon!) has resulted in about 2 clicks per day. Not a lot, it must be said, but this is a pretty small website, and I didn't make the itops.com/sysview/ links terribly prominent. The fact that I provide this shell scripting content for free has driven some visitors to my employer's website. That has to be better than nothing. Making quality content available alongside paid-for content, in a more direct way, must be a Good Thing.
- Presentation - the steve-parker.org URL indicates that I'm an individual, offering stuff up as best I can, not claiming to be some big, powerful organisation. Websites are a great way for small firms to look as good as the big names; if I'd pitched this on "professionalscripting.com" (that domain doesn't currently exist, by the way), and the content had implied that it was the product of a large, professional organisation, I don't think I'd have got the vital feedback from my visitors. Also, the document is clearly titled "Steve's Bourne/Bash scripting tutorial", confirming that I am an individual who wants to make stuff available to other individuals.
- Attitude - Again, I don't make any claims that this is a professional operation. At every point in the process, I provide a link to my "Mail me" page. It would be very damaging to my credibility if someone's transaction failed - I got their money, and was not aware that they had not received the book). That could affect my Google ranking, starting a vicious circle. I know that the process is not fully tested, but once I'm fully confident in it, these "tell me as soon as you have a problem" links will remain. Again, it gives the customer the confidence that they're dealing with an individual who actually cares about the transaction, not a corporation who they'll have to do battle with to get their $5 back.
Come to the site, choose to buy the PDF, enter PayPal details, download the PDF.All my customers appear to be reasonably happy, though.
Hopefully, from now on, this transaction case will work painlessly, having ironed out the bugs. I'm able to manage this because it's a low-cost item, and because I am clearly an individual.
For commercial purposes, we can upgrade the PayPal account to one which allows sub-accounts, which would allow for test-transactions without setting up two "free" PayPal accounts to test the functionality whilst paying PayPal a fee for each test.
If I were to do this again, I think I'd make many of the original mistakes. I now know what data gets sent back from PayPal
when Auto-Return and Payment Data Transfer are enabled, but only by experimenting on real people, so I should be able to make
things work a little more cleanly the next time around.
I'd also set up more test-pages, passing various feedback that PayPal would supply, to my test-page, before going live with
it. If I expected any real money, I'd get a full PayPal account, as that would give me the ability to test a configuration with
two PayPal logins (sender and recipient) - standard PayPal customers can't do that, which is why I've had to leave the testing
to my customers.
Overall, I'd say that my experience of using PayPal, is that it is very simple to set up, much less hassle than setting up a merchant account for credit-card processing via your local bank, but rather expensive, and (unless you expect to make a lot of money from the operation, making it worth upgrading your PayPal account), very difficult to test.
22 Nov 2004: Crap HP FUD
Eric Schrock's blog mentions a bizarre FUD campaign by Martin Fink, HP's Vice-President. He's bought www.linuxcio.com, where he makes a bunch of, frankly, pathetic claims about Solaris - x86/SPARC, and OpenSolaris. We'll have to see what happens with OpenSolaris, I don't know, but the "big/little endian" stuff is the same (trivial) problem for HP's various architectures as it is for GNU/Linux, HP, IBM, Sun, and everybody who deals with cross-platform software. Alan Hargreaves deals with the FUD.HP's website just looks so bad, I assumed that it was written by an amateur (by which I mean, someone with even less publishing sense than myself, which is pretty far down the tree). To find that this is HP's VP is shocking. See Alan's post for a full rebuttal.
I may be a bit of a Sun/Solaris fanboy, I'll happily admit it. This is such easy pickings, and Alan makes such a good job of debunking it, that it's worth posting - HP really shouldn't be putting out such unprofessional stuff, I really thought better of them. This sounds like a desperate rant of a dying company - the standard slashdot response to anything which Sun announce. Since neither firms are even ill, let alone dying, why do HP feel the need to resort to such low (and easily-refuted) FUD?
CuddleTech has a colourful response, too (in more ways than one).
What none of them seem to notice (although it has been mentioned repeatedly on several fora), is that a hypothetical GPL'd Solaris would not really effect the Linux kernel. A Linux kernel developer who could read the SunOS (Solaris Kernel) source and legitimately apply the code/concepts into Linux would choose the concepts before the source. The trees were developed independantly. I don't know much (if anything!) about kernel development, but I've seen bits of both trees, and the way they work internally are sufficiently different that there is no value in shoving SunOS/Solaris code into Linux. Linux kernel developers might find the concepts behind things like IPMP, SVM, RBAC easier to parse from source code than from documentation, I don't know. This ability for Linux developers to read the source would also help Linux for UltraSPARCIII, IV, IV+, but again, Linux would gain nothing from being able to change Solaris' SunOS kernel. Sun's apparent commitment to OpenSolaris already gives Linux this ability - they say it will certainly be an OSI-approved license, so "read-only" is a minimum.
Alan Hargreaves (who knows more than I do about the licensing options Sun are discussing) implies that write-access to the Solaris tree will also be available, so that's a bonus for Solaris users, but makes no difference to Linux users - they will already get the benefit of Linux kernel developers being able to read the SunOS source and implement it in Linux.
Where this will take Linux and Solaris, I have no idea, but does it really matter? The OS should be some underlying
thing upon which services are based. POSIX realised this over a decade ago - I can call "fopen" under DOS, Windows,
Solaris, Linux, AIX, HPUX, SINIX, SCO, and probably even MINIX. That's a Good Thing.
I'm responsible for some software which runs on DOS,
Windows, Linux, Solaris (SPARC/x86), and Mac OS X. As it's console-based, there are only a few #ifdef's in
the code to make it work on all these platforms. Making it GUI-based would be far more problematic, but that's
a GUI issue, not an OS issue. I've not tried, but porting that code to AIX, HPUX et al should be a half-hour job.
Porting it to the Mac involved 30 minutes installing the developer packages, and 30 minutes working out the
#ifdef's - no code change was needed.
We do care about Operating Systems - Linux 2.4 is faster than 2.2; 2.6 offers hardware drivers unavailable in 2.4,
Solaris 8 offers IPMP which wasn't in Solaris 7; Solaris 10 has tons of new things - ZFS, DTrace, etc. But
what users really want is an OS which controls the hardware. Windows is great at supporting x86 hardware, Solaris
x86 is crap (but getting better) at it. Solaris uptime is measured in years; Linux in Months; Windows in Days.
We have choices available.
Sun have, for a long time, since the workstation days, aimed at the Enterprise level, where RAS matters. I love
Linux on my desktop, but it simply can't support RAS like Solaris on an SF15K - swap-out the CPU which is currently
running the kernel, and the RAM which it's using, without downtime, for example. Sun's hardware can do it, and
Solaris can do it, too. Linux feels no need, since the Linux team can't create the hardware. Technically speaking,
in the "infinite monkeys" sense, at least, Linux could do that on a SF15K, but it doesn't.
Given the SunOS source, it's possible for Linux to also support high-end machines like the SF15K, but it would take a lot of work to make this work on Linux - and, quite frankly, who is likely to by a SF15K for (approx) $1m, then throw away the support by installing Linux onto it? If you want to do that, is it really the machine you want to use in the first place? It seems an odd choice. I don't deal with sales people, and I'm sure they're "pretty keen", but I can't envisage a scenario whereby you'd sell an F15K on its hardware benefits plus an Operating System which doesn't take advantage of them. The whole poing of an F15k (There's an F25k available, too, if you've got a bit of spare cash, but as I say, I don't "do" salespeople) is that it's highly configurable. For that to work, it depends on the OS behaving in a certain way.
17 Nov 2004: Starting with PayPal - Part III
(discuss)(cf. #5, #4, #2, #1) I got an email from PayPal saying that I'd got a payment of $5 for the book, so I emailed it to the supplied address. 12 hours after the payment was made, I got another mail from paypal saying that they'd reversed the transaction. In this test case, it's no great hardship to me - I've not physically lost anything by emailing the book, I just don't get my $5. If I'd posted a hand-made necklace, I'd be rather less impressed. I need to look into this. As far as I know, the book seems to have gone to the account-holder's email address, so the fraudster never got the book.
I'll be chasing PayPal about this, though - how come, 12 hours after the transaction, they decide it was fraudulent? Did the real account holder tell PayPal "I didn't make this payment, but got phished by an email recently"? If so, is it true? If I was dealing with real money here, I would be extremely concerned about fraud.
I also got an (apparently valid) purchase at this new, low, $5 price, and sent the book to that user, too.
I've also added PDT (Payment Data Transfer) to my account - I assumed that I'd get some stuff posted back from
PayPal anyway, but it seems that I need to activate it. It gets sent as a GET, not a POST, which does seem
rather odd. POSTs are harder to spoof. With this, I have to send an HTTP[S] request back to PayPal when they
send the customer back to me - they will respond with some customer and payment details - amount, address,
email adddress, etc. That's potentially scary - I don't store any of this, but I could save customer's physical
addresses into a database, even though I only need their email address. Not had any customers in the past few
minutes, of course, so I can't confirm if my changes to PayPal's suggested code actually work!
This means that customers should now be able to download the book as soon as they've bought it, without
my interaction.
15 Nov 2004: Starting with PayPal - Part II
(discuss)(cf. #5, #4, #3, #1) Well, so far I've sold 3 copies, 2 to UK buyers. I've added a US Dollar option (PayPal seem to deal with the currency conversion, presumably taking a cut to their benefit again). The £5 cost is roughly equivalent to $9, but I've put it up as £5 or $5, with two buttons.
I've also changed to the "encrypted" button format, as I've been getting a lot of spam and viruses to "<random>@<domain>".
I have been getting a lot of downloads of the sample, so maybe this low level of purchases simply means that the product isn't much good. It's also true that the sample is available to search engines, but this is supposed to be a Good Thing - the sample is a PDF which tells you where to buy the rest of the tutorial, so that should drive more buyers here than less.
For what it's worth, Google sees about 2000 Java-enabled visitors per day (if Java isn't enabled, you don't get the ads to the right of the page, so Google doesn't see those visitors). Taking 1st November at random, Google saw 2,341 visitors, I logged 3,955 visitors. So since 23rd Oct - 15 Nov, that should mean something like 60,000 visitors (weekends get about half the traffic, so I'm not counting that. It's only approximate). That's a 1 in 20,000 ratio, for a £5 book.
For work, we decided a while ago not to use PayPal, mainly because it takes the visitor away from our site, and clearly onto PayPal's site. I spoke to them about this, and (particularly because of the phishing scams they've been subject to recently) they are not prepared to make their site look like anything other than PayPal. That's not good enough for us as a business. It's still an interesting experiment for me, though.
