Can My Customers Use Paypal Without An Account?

Yes.  This fact isn’t very well documented and I’ve seen folks who have sold $100,000+ with Paypal tell you it is impossible.  However, not only is it possible, it is actually exceptionally easy for customers.

Briefly, a prospective customer arrives at the start of the Paypal Express (fancy term for “Paypal hosts the checkout flow”) funnel by either clicking on checkout in your shopping cart or clicking on a buy it now link.  That page is presented differently based on whether the customer currently has a cookie with Paypal or not.  

If the customer is cookied:

They are told to log in to their Paypal account.  Here’s an example (I have used my own site’s shopping cart, so you’ll see my payment email address and the name of my product in both screenshots):

If the customer is not cookied:

They get a split screen.  One half of the screen presents a checkout workflow which they can enter immediately.  The other half presents a sign in/sign up with Paypal dialog.

Why Paypal does things this way:

In a word, because it makes them money.  You have to understand that Paypal’s primary source of revenue is interchange fees.  And their primary expense?  Also interchange fees.  When somebody pays $24.95 for a copy of Bingo Card Creator, Paypal makes $1.02.  And if that person paid through a credit card, Paypal now owes about 70 cents, give or take, to the credit card company.  

If, however, that customer had a Paypal balance and paid through Paypal, completing the transaction is free to them — all they have to do is a database update on their own records.  Ca-ching, tripled their profit!  Or, if the person has no Paypal balance but has linked their checking account to their Paypal account, Paypal can do an ACH debit on the checking account for much, much less than 70 cents.  Again, more profit.  

Then there is also the matter that conversions are much higher when all you need to do is convince people to signin and click “Purchase” rather than filling out a dozen fields in a form.  However, for those folks who are holdouts about getting a Paypal account, requiring them to get one costs conversions and thus costs Paypal money.  This is why they continue to prominently offer the “guest” checkout to people who do not have a Paypal account yet.

What this means for you:

Have no fear — Paypal’s check out experience is optimized to make them money, but as a side effect that means it is also optimized to make you money, by automatically presenting all prospective customers with a purchasing option which is appropriate for them.

Comments Off

Book Recommendation For Budding Bloggers

Almost a year and a half ago, Stephane Grenier approached me about contributing a chapter to a book he was editing, at the time entitled Interview The Pros.  The general gist was collecting the thoughts of several dozen successful bloggers in interview format.  I was honored to be included (it still amazes me that I could credibly be included in a list of names including Seth Godin and Jeff Atwood), dashed out a chapter, and forgot about the project for 18 months.

Then on Tuesday the mailman stopped by my little apartment in central Japan and dropped off a package.  Five promotional copies for me — whee!  It turns out the book has been retitled Blog Blazers, an act I think Stephane owes somebody a beer for.  (The importance of titles is a major recurring theme in the book.)

I promptly updated ye olde resume to include “published author”, gave a copy to a friend of mine who was starting a business, and set about to reading it.

Structure 

The basic style of each of the 40 chapters is a question/answer session with the interviewee.  The questions are identical.  Representative sample:

  • What makes a blog successful?
  • How long does it take to be a successful blogger?
  • What is your biggest tip on writing a successful blog post?
  • What are your main methods of marketing your blog?
  • How do you monetize your blog?

The sheer diversity of answers to these is amazing — the book includes everyone from folks whose blogging generates a full-time income from AdSense, software consultants who are looking for professional contacts, an online weightloss diary, some guy with an interesting fascination with shoes (who wrote the funniest chapter, by far), and one computer programmer who should probably listen to his own advice more:

Speaking of timescales in blogging — recognize that you will be blogging until you stop blogging.  That sounds simple, but many peopole start out with a burst of post-every-day fever, which they cannot sustain over the long haul.  Pick a pace which is predictable and sustainable.

In my defense, it sounded a lot more credible when I wrote it.

My chapter focuses mainly on blogging as a small business and practical tips you can use to achieve success that way.  (A few of the other chapters are a bit more inspirational in nature, although most of them have some actionable advice.)

In Which I Disagree With My Marketing Idol

Example from my chapter:

I personally can’t stand the “Top Ten Ways To Write A Blog Post” type articles, as aside from being boring and aesthetically unpleasant they turn your blog into a commodity provider of lists.  Instead, absorb the lessons that style of writing provides which continuing to have unique positioning for your blog.  The important lessons are “titles which promise immediate benefits are a good idea” and “judicious use of formatting such as bullet points, bold text, and pictures can turn a scanning surfer into an engaged, active reader.”

Seth Godin’s take on the issue:

Use lists.

Write short, pithy posts.

That is one of many, many disagreements the authors have with each other, and I find them fascinating.  (A few other points of contention: the importance of monetization, the ideal post length, and the importance of SEO.  You’ll find many well-argued solutions to all of these in several chapters… and the right answer in my chapter, naturally.)

Single Best Advice From Me: 

I recommend… that you get familiar with two groups of websites in your niche: the folks who have achieved something close to what you want to achieve, and the folks who are on the path to success but just a wee bit farther than you are.  The first give you examples to emulate and objectives to strive for, and the second should become your new best friends, because a) they’re not too busy yet that they have millions of admirers and b) their support can really kick start your blog and help you both get closer to your goals.

For the other 200-odd pages of advice, you’ll have to buy the book.  At $16.95 I’d honestly say it was a steal, even if I had no connection to it whatsoever, because the value a blog can drive for a small business is immense.  (See my chapter, and several others, for elaboration.)

You’ve got two options for getting it.  One is to buy it directly from the Blog Blazers‘ site (where there is an e-book option).  I’m going to encourage you to sidestep them and purchase from Amazon instead.  My big reasoning for that is that publishing is a winners-win game, and purchases through Amazon increase the book’s Amazon rank, which results in more prominent placement on the site and also results in indirect marketing opportunities (“buy Blog Blazers, currently #1234 on Amazon”).  (At time of posting they only have two copies left.  Small order to start out with = book languishes in obscurity.  Break the cycle — buy a book today ;) )

As usual, I don’t have any monetary interest in the book or in your purchase of the book.  (i.e. those are not affiliate links)  I contributed to the book because Steph asked me to, and it was a pleasure to contribute a small bit to something which will hopefully provide value to people.  If you’re one of those uISVs scratching your head thinking “So I’ve heard them say 432 times ‘Blogging helps for marketing’ but I don’t consider myself an expert at this yet”, read the book.  I guarantee you you’ll learn something.

P.S.  Seth Godin is one of the world’s best living theorists about marketing.  I am not Seth Godin.  You are not Seth Godin.  Please, for all that is holy, don’t write list posts.

P.P.S. uISVs will recognize more than a few names: Ian Landsman, Bob Walsh, and Andy Brice all contributed chapters.

P.P.P.S Remind me to get the contact details of whomever did the cover design if I ever publish anything.

 

Cover of Blog Blazers book, depicting man with BB on chest standing atop world.

Cover of Blog Blazers book, depicting man with BB on chest standing atop world.

Comments Off

Rails Fails To Update Serialized Columns On Save

One of the problems I hit earlier today, which literally cost 2.5 hours to resolve, was that I have a Rails model which uses a serialized column in it.  The column contains a hash of options for the object.  Fairly simple stuff.

As it turns out, after overwriting one of the parameters in the hash and saving it, the object in the database would be out of sync with the ActiveRecord object still in memory (even though save returned true), which lead to hilarity the next time someone grabbed the object from the DB and got partially out-of-date data.  (Inconsistent out-of-date data.  Failure.)

As it turns out, the issue is a new feature Rails 2.1 — partial updates of database records.  Rails keeps a list of which attributes are “dirty” and only updates those when you call ActiveRecord#save.  Unfortunately, touching the contents of a hash does not mark it as dirty.

I was absolutely clueless how this was happening (I stupidly upgraded to 2.1 on a whim, thinking that I hadn’t written any significant code yet so incompatibilities wouldn’t bother me — true enough, the only incompatibility was with my mental model of how ActiveRecord worked), but I successfully diagnosed the why — a dirty bit wasn’t getting set for the serialized object.  OK, no problem, the same thing happens at the day job with our Java system — which means I can use the same hacky solution to the problem.

def before_save

  options_hash_clone = options.clone  #shallow copy of options hash

  options = {} # sets dirty bit for options hash

  options = options_hash_clone # restores options hash to original content, ensuring save updates it in DB

end

which will, indeed, set the dirty bit. 

As it turns out, there is a cleaner way to do this if partial updates aren’t a requirement for your model:

#there are a number of places you could put this — the model class itself strikes me as decent

ModelNameGoesHere.partial_updates = false

A big thanks to this post for putting me on the scent of the problem.  Seems I missed quite a bit of discussion on Google about it since I was not hitting the right keywords apparently.  The fact that this is on by default appears to be one of those opinionated software practices where “opinionated” means “it is our opinion that you should be as familiar with the change log as the core team before you install a new production release”.  (Sorry if I sound bitter.  2.5 hours.)

Comments Off

Introducing Widget Bakery

After 8 very productive hours with my designer today, I have a bit to show.  We worked at his house and, in between random banter with his wife and eating some very nice Japanese-style pizza, he banged away at the design of the page and default widget behavior and I got to work on some heavy duty Rails/Javascript magic.  Sadly he is much better at design than I am at web programming, so I did not progress quite as far, but things are looking up.

So the project name, which I haven’t mentioned to anybody yet, is Widget Bakery.  I’d encourage you to go open that up in another window — there is a full design for the front page posted, less much of the content.  As should be obvious, everything is heavily in development so don’t expect you’ll see any of the verbiage or design work stay there permanently, but I thought I would get the ball rolling so that people didn’t think I had completely abandoned the Sprint.

On the functionality front, I’m afraid that because Widget Bakery’s fundamental behavior involves being responsible for content on 3rd party websites, I really can’t show you anything useful this early in development.  Database schema and whatnot are still in a state of flux and anything which I post, and which you might subsequently post to your blog, could suddenly break.

Plus I would really, really hate if one of my widgets actually became popular before I had, oh, put indexes on the table ids or turned on caching… almost melted my poor laptop today during testing.  Word to the wise, kiddies: despite it being so obviously necessary you’d expect them to do it for you, Rails will not automatically slap database indexes on your id columns, and then you get to do full table scans every time you pull in linked objects.  Gotcha!

So in lieu of live functionality I give you this screenshot of a widget which does actually function:

Sample Widget

As you can see I sort of have my work cut out for me on the CSS front, to get that footer text working properly.  You can’t see all the “fun” I had playing with iFrames, Javascript, and the DOM model to be able to inject that sucker into (just about) any page on the Internet and have that plus button bring up a Lightbox in the middle of their page to give instructions on how to embed the widget.  There still needs to be quite a bit more tuning done there — if you don’t hit the “close” button for the Lightbox at the moment there is no way to cancel out of it, which is quite unfriendly to the user.  (I’d like to get back the old “click anywhere to dismiss” Lightbox functionality, which is going to require further DOM spelunking.)

The RSS parsing, though, is done.  It needs to have error handling and some caching added, but after that I’ll have one widget ready of the baker’s dozen I hope to launch with.  Unfortunately, at the moment actually making that widget requires access to the server console and typing things like

@widget.version.latest.options[:rss_url] = “http://www.example.com/rss”

I’m going to have to get that functioning in a nice, easy to use GUI.  And then repeat or reuse that GUI for each type of widget, while making their internal differences fairly transparent to the user.  Lots of work to do, no time to do it — time to shake and bake!

Comments Off

Leveraging OSS As A Software Developer

Cards on the table: I sell proprietary software, do occasional OSS work on both a volunteer and paid basis. and have been known to post to Slashdot on occasion about my love of Windows Vista.  This either means I’m sort of an agnostic in the wars of religion over software business models, or that I really love making enemies.  But I’m more of a fan of making friends, so I’m perpetually trying to convince members of both warring camps that they can get a lot of what they want out of the others.

One perpetual worry on the Business of Software forums is that some OSS developer (invariably a grungy, marginally employed coder with Jolt stains on his T-shirt) is going to come along, clone your application, and eat your lunch.  As a result there is a certain amount of hostility among small software developers towards OSS, which is a shame.  I spent some time earlier trying to address myths about it, but I thought I’d go one better and focus on ways OSS can make you money.

Concentrate On What You Do Best.  Let Other People Do Everything Else

Currently I’m finally getting restarted on my latest project, which is a web service that helps small businesses do content syndication across the Internet.  There are a number of interesting technical challenges here, including both server-side (“How do I let a person who is potentially only paying me $9 a month generate tens of thousands of pageviews without the server bills putting me in the poorhouse?”) and client side (“How do I use Javascript to make the whole process pain-free for non-technical end users?”). 

As it turns out, I’m a fair hand at some portions of the puzzle, but portions of it are complex.  Very complex.  You have no idea how far down the rabbit hole goes in web development, Alice.  I honestly think that it is impossible, flat out impossible, for any one person to be expert at all the technologies which are implicated by a trivial web application running on a modern web stack.  This includes everything from HTTP to the DOM model to Javascript to the database to relative velocities of the little spinning bits of metal that make everything work. 

Thankfully, programmers get this lovely tool called abstraction, which means we can concentrate on one bit of the problem at a time and treat the rest of the world as a Solved Problem.  For example, when I’m working on Rails, I am not thinking about the L1 cache policy on the server.  In fact, although I really appreciate my $150,000 CS degree, it is entirely possible that I will grow old and die without ever once worrying about L1 cache.  Smarter people take care of that stuff for me.

OSS Is About Smarter People Taking Care Of That Stuff For You

One key feature of my content syndication widgets is that they be able to spread without requiring user action away from the host site, to avoid antagonizing hosting site owners.  This was going to require some serious work on my part to achieve — probably several days worth, as Javascript is not my bag.  As it turns out, Lightbox Gone Wild (a variant of the Lightbox project which I’ve previously used to business-enhancing effect) took this from several days of work to about five minutes of integration. 

Lightbox Gone Wild is made by Wufoo, a company which doesn’t specialize in wild-and-crazy Javascript, but rather in selling a service which makes data collection easy for people.  Note that key word selling – OSS developers are typically not poor aesthetics who need to beg for their next cup of coffee.  Since wild-and-crazy Javascript doesn’t make Wufoo money directly, they release it back into the ecosystem for someone to extend (much as how they themselves extended the previous Lightbox project), with the added benefit that they may get to incorporate the extensions later and in the meantime people who have no interest in HTML forms nonetheless say good things about them.  (If you need form input and HTML scares you, go to Wufoo.  There, did my good deed for the day.)

In turn, I’m going to tweak their script a few times to add usability enhancing features (like backporting my “escape button closes the layer” tweak to the original Lightbox, which is a big win for non-technical customers), which increases the aggregate value of free OSS available but still gets me incrementally closer to making money from my paying customers. 

In fact, taking stock over what I’ve accomplished so far, I realize I’m doing a whole lot of this borrowing from OSS.  From classic infrastructure components (database, web server, application stack) to user interface elements (editing controls, charts) to a zillion pieces of behind the scenes wizardry, I’m probably literally using several thousand man months worth of software, adding two man months worth of glue and secret sauce, and then if all goes according to plan making a bit of money off of it.

Code Base By Writer

That’s the OSS Business Model

I often hear folks wondering whether they’ll make more money if they stop charging for their main application and OSS it.  Survey says no in most cases.  Rather than being engaged 100% in the production of OSS, you can OSS contributions you make which are boring, routine, and only tangentially connected to the main business of solving specific problems for your customers.  This allows you to lower development costs very modestly, but the social benefits are very nice for a bootstrapped software company. 

Giving away free stuff directly to your customers is a time-worn capitalist tradition, but giving away free stuff to other people works pretty decently too.  We live in an era where, for better or worse, GoogleBot is a judge of character and strongly prefers people who share.  (OSS users/developers have, on average, extraordinarily high levels of technical expertise and are solidly members of the linkerati.  They make good folks to influence from an SEO perspective.  You also get direct benefits from having vocal, technically capable, engaged people interested in you personally — although those direct benefits may not extend into them actually buying your software, but then again they weren’t in your niche to begin with so no harm done.)

OSS as a Barrier To Entry

But wait, there’s more.  It seems funny to say, since OSS is making it vastly easier for me to build my website, but I think that it functions as a barrier to entry for competitors.  You can’t just whistle your fingers and snap together 15 diverse and unconnected OSS projects into a usable application — the design and integration of complex systems is still a skill, and it is one that is in many ways more difficult than straight-up application development in some domains.  This turns skill with particular OSS projects, or generalized methods and patterns of integration, into one more competitive wedge you’ve got in your arsenal.

Additionally, OSS raises something of a quality cliff in front of prospective competitors who are not using as much as you.  Consider the typical graph of development effort expended versus value to the customer.  Typically, this gently slopes upwards for the first portion of the graph (“20% of the effort secures 80% of the value”), and then it plateus for a very long time as the easy wins are exhausted and the long, arduous process of software development begins. 

The curve for a developer using lots of OSS doesn’t look different in asymptotic behavior, but it contains numerous discontinuities along the way.  Every time you spend a small quantum of effort to integrate a new feature (that you didn’t have to write), your user-perceived quality gaps up.  Someone running along on your old curve, trying to keep up, runs straight into the quality cliff-face. 

Example: assume you and hypothetical competitor Bob include analytics in your application.  Both of you decide, sensibly, that the screens require a visual component.  Bob starts coding his.  You quickly integrate Google Charts, which while not strictly speaking OSS is the same general principle.  Now Bob isn’t just running the race against you — he’s running against the team at Google doing the Charts development and you’re already done and busy working on your next feature.  It makes OSS a great force multiplier.

Sidenote

Speaking of Google Charts: wonderful output, neatly solves the problem of graphing without requiring massive server-side resources or Flash-capable browsers.  Terrible, terrible API from a programming standpoint — you write uber-ugly incomprehensible URLs and their servers return the appropriate charts.  Luckily, folks have already extended it by offering wrappers in many popular programming languages (I mentioned the Ruby one already), which is another example of collaboration making a good thing better. 

I’m planning on eventually releasing a bit of magic myself, which will let you treat the charts as if they were being produced locally.  (There are decent reasons for this, from branding issues to future-proofing your site in case Google decides to cancel the charts project and you don’t want holes developing in all your old content all of a sudden.)

Comments Off

Bad News and Bad News and Good News

A situation that has been really stressing me out recently has resolved itself.  Sadly, it did not resolve itself to my benefit, but it is no longer hanging in the air, which means I can get on with life.  Unfortunately, as I’m looking at the remaining days on the calendar, it looks impossible to recover the time I lost these last two weeks worrying about it, so I’m likely not going to have a saleable application at the end of 30 days.  Ahh well.  I’ll throw myself into the work again from tomorrow, and continue supporting the rest of y’all, with the new goal to have something to show in public by the 1st and then do the actual release sometime after that. 

I would happily launch with a half-finished app that doesn’t even have billing integrated, but the nature of widgets is that they exist on third party sites, and half-finished could very well mean that widgets break on third party sites, which is just not good behavior.

Comments Off

Eight Amazingly Productive Hours

Keith and I just put in a full day’s work on the program.  It is shaping up nicely — well, the design at any rate.  I spent most of the day fighting old, outdated versions of Capistrano and Deprec to let me get Rails to a deployable state from my Vista workstation to my shiny new 512 MB Slicehost slice.  I expect that I’m going to really, really need the extra memory to have enough MemCaching and Mongrels available to serve all the requests, since many of them will be originating off-site and the entire point of the system is to help people go viral.  (Hopefully not TOO viral…)

I also found some wonderful OSS to integrate in with my planned features today.  More news on that later, as I think some of them will not hit the shipping window, and I only want to show off stuff that will, for the moment.

My rough sketch of the implementation agenda:

  1. Skeletal widget implementation (i.e. what I have for BCC, except generic)
  2. Widget rototype including the Lightbox implementation
  3. Widget creation workflow
  4. Widget maintenance page
  5. Account creation
  6. Account/user management
  7. Billing (ugh — not even decided on a payment processor)
  8. Admin backend
  9. Stats tracking, graphs, and all that jazz
  10. Emails
  11. Periodic tasks
  12. Home-rolled Analytics
Comments Off

Day 13: Early Proof of Concept

Finally I got a chance to do some programming!  I have worked the kinks out of my incredibly edibly basic early proof of concept of the widget functionality and have incorporated it into the live Bingo Card Creator site. 

You can see the distribution of the proof-of-concept widget at my most popular bingo cards page and the actual widget itself displayed on my stripped-down mock-up page.  Before you click there, let me warn you: it is boring as all heck.  I would like to say that is because I wanted cross-website compatibility, but mainly it is because I am not meeting Keith (my good friend and the CSS guy who will be assisting me a bit this month) until tomorrow and, independently, I have the artistic ability of paint.  Not MSPaint, no, just paint.

I also took out the embedded viral distribution for the proof of concept because a) its late and b) I’m lazy.

Hopefully this shows off why a small businessman would want to pay for this functionality.  Imagine that spread over a few dozen teacher blogs — it propagates itself, for no marginal cost whatsoever, spreads the content I spent so much time and money creating, and gets me new visitors and eventually customers at a bare fraction of the cost of CPC advertising… all the while allowing me to deepen my relationship with my core followers by giving them free stuff that they like.  That is a win-win-win. 

Now if I can just generalize it and make it possible to do without a few hours of Rails programming, I can start printing money hats.  Small, modest money hats to start with. 

Comments Off

Antair Moving On And Moving Up

I had been wondering what happened to the Antair guys.  It appears they’re striking out for the big leagues, moving in to brand new digs and everything.  Why don’t you go over to wave and congratulate them on their successes?

I remember back when Andrey was still comparing his sales to mine to see if he was on a good track.  Suffice it to say that he’s since made it necessary for me to play a wee bit of catchup.

Comments Off

How To Use E-Junkie Without Your Customers Seeing It

Hideho folks.  I’m taking a bit of a break from progress updates on the 30 Day Sprint (not progressing as much as I wanted to but I have Saturday blocked off with a designer buddy to get some stuff together) in order to answer a common question. 

I love e-junkie, the service.  So much so that I have been called Robin’s local sales rep.  And that is probably closer to the truth than I would like it to be.  But I really, really can’t stand the name — it says absolutely nothing positive to my customers about my business.  So I go to some pains to avoid them seeing it.  Since it will help other uISVs and e-junkie, I thought I’d give a rundown.

Issue: Customer lands on e-junkie page after checkout, to receive CD key

Resolution:

1)  Go to your e-junkie product settings. 

2)  Click the box next to “Product Requires: … Redirection”.

3)  Click Next.

4)  Fill in the Redirection URL.  Point it to a page on your own web server.

5)  On the page on your web server, you will want to display the CD key and instructions for installing it, plus regurgitating all the other stuff you put in your thank you mail.  (Make it big and bold because people do not read this page unless you give them a darn obvious reason to.  Getting them to read it saves you support costs, trust me.)  You can handle the content.  If e-junkie has a CD key, for example if you uploaded a list to them or they run a script to generate one for you, they’ll put the CD key in a URL variable “key”.  So if your URL was http://www.example.com/thanks.htm, your customer will end up seeing http://www.example.com/thanks.htm?something=here&somethingelse=here&key=yourkey .  Your mission is to get that key onto the displayable page.  If you can do server side programming, for example in PHP, this is pretty trivial.  If you can’t, you can grab it with a bit of Javascript

Either way, please secure your website against ye-olde insert-arbitrary-content-by-rewriting-the-URL trick.  You’ll thank me later.

Issue: Customer’s mail server is throwing out your mail

1)  e-junkie generated mail originates from one of (as of the last time I checked) three e-junkie.com servers.  It carries your name as the sender.  Bad news bears, this means that many automated checks on that email will say “e-junkie.com is spoofing honestmicroisv.com, oh no, its spaaaaam!”  What you need to do is publish an SPF record telling the world that e-junkie.com is a legitimate source of email for you.

2)  You’ll probably want to read the docs for your individual web hosting company on how to do an SPF record.  GoDaddy‘s interface is rather sweet.

Issue: You have links to www.e-junkie.com all over your page.

1)  You aren’t using the Fat Free Cart?  OK, fix that right now.  (And watch your conversion rise!)

2)  You might be worried about folks seeing the links by looking at their address bar really closely after clicking on the links.  Personally, I doubt my customers are nearly that savvy, but maybe yours are.  What you need to do is publish a CNAME DNS record, aliasing store.bingocardcreator.com (example) to www.e-junkie.com .  Then, every time the GoDaddy docs say e-junkie.com, you just subsitute your local alias.  This will not work with https (customers don’t know what that is, either) but it will get rid of the e-junkie.com in the URL bar in most browsers that I am aware of (some might resolve the CNAME and then update — I don’t know which off the top of my head), and it will get rid of the URL on hover in every browser.

And that is your tip for the day.  Check back this weekend, I’ll be back to coding and writing up a storm.

Comments Off