macdevcenter.com
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button

The Do's and Don'ts of Shareware, Part 3
Pages: 1, 2

Payment Processing Provider Comparison

Below is a comparison table of the three Payment Processing Providers described previously. As stated above, these providers are always evolving their services, so it's important to check with them when you're ready to sign up.



  • All providers were asked for input when creating the table to insure correctness.
  • The table below does not include one-time fees to sign up for any particular service or feature.
  • The table does not include any features that were/are under development by the Payment Processing Providers.
  • All information is correct as of October 4, 2002. (See now, I'm just trying to be fair.)
FeesKagiDigiBuyeSellerate
Fee for $5 product$2.50$3.00$0.50 (2)
Fee for $10 product$2.50$3.00$1.00 (2)
Fee for $20 product$2.50$3.00$2.00 (2)
Fee for $50 product$5.00$6.95$5.00 (2)
Fee for transferring funds to author's bank account (7)$35$35/$50Free/$21
Fee to process refunds (1)Keeps fee for original sale$2.00Free (8)
Fee to process charge-backs (1)$5$25Free
Ordering MethodsKagiDigiBuyeSellerate
Accepts orders from webYesYesYes
Accepts orders from within productNoNoYes
Accepts orders from faxYesYesYes
Accepts orders from phoneYes (3)YesYes (3)
Accepts orders from emailYes (4)NoNo
ConfigurationKagiDigiBuyeSellerate
Time required to set up sales siteA long time10 minutes10 minutes (6)
Minutes to process one order< 3< 3< 3
Authors log into secure serverYesNoYes
How to add new productSpecial "Register" application or Web interfaceWeb InterfaceWeb Interface
Complete order web page customization$20/monthFreeNot available
Custom fields available at author's discretionYesYesNo
Shopping interfaceQuantity or Cart (5)Quantity or CartCart Only
Complete customer email customizationNoYesNo
Some customizations require emails to providerYesNoNo
Ordering OptionsKagiDigiBuyeSellerate
Discount couponsNoYesYes
Simple split net profit (after fees) between two or more authorsYesNoNo
Ability to sell your product through Portals NoNoYes
Automatic registration code generationYesYesYes
Accepts non-profit donationsYesNoYes
Localizable to more than one languageYesNoNo
Ease of UseKagiDigiBuyeSellerate
Ease of use for author (9)two-starsfour-starsthree-stars
Ease of use for customer (9)three-starsfive-starsfour-stars

(1) Refunds are initiated between the user, the payment processing provider and the author. Charge-backs are initiated by customers via their credit card company and result in much higher fees.
(2) eSellerate's fee is dependent upon volume. Lowest fee shown.
(3) Business hours, provider's local time only.
(4) Encrypted weakly.
(5) Cart not available with "old" store, only "new" store.
(6) Contract must be signed and faxed.
(7) Some international banks cost extra to transfer funds to. eSellerate doesn't penalize users whose banks support lower cost transfers.
(8) eSellerate keeps payment fee only if customer disputes charge directly with eSellerate. Author-initiated refunds are free.
(9) Non-objective comparison.

Although this article only discusses three Payment Processing Providers in detail, there are many others. Authors should look for themselves and compare services and percentages to find the best match for their products. A few other providers that come to mind are RegNow (20 percent commissions) and new player Plimus (10 percent commissions, see its "BuyNow" solution). PayPal's merchant solution is also an option, although your customers may not want to become PayPal members. PayPal's support is also difficult to get ahold of and its system can arbitrarily lock out accounts with no recourse. In any event, it wouldn't hurt to send an email to the tech support folks at all of these companies to see how quickly they'll respond to your questions. Such response time is usually indicative of how seriously they take their responsibility.

There is one other option we haven't discussed: setting the whole thing up yourself. There are a number of articles and books detailing e-commerce implementations. Below is just an overview of what you'll need to process sales from your very own server:

  • A server that stays up 24/7 with all of the appropriate security measures installed. (An Earthlink business hosting site costs $34/month.)
  • Scripts to drive your Web store. (PHP and MySQL come to mind as an excellent solution.)
  • A security certificate (Thawte.com charges ~$100/year via Earthlink.)
  • A payment gateway like Authorize.Net. ($20/month + $0.10/transaction.)
  • A merchant account at your local bank. (Bank One charges $8/month + $0.17/transaction.)

Now all of that sounds like a lot to keep wired together. But there is a simpler solution: Amerimerchant.com is both a payment gateway and merchant account with fees as low as 2.4 percent + $0.31/transaction. All that's needed is the server, scripts and secure certificate. Amerimerchant can also wire your payments directly to your bank account every day. In the spirit of Tim O'Reilly's penchant for Open Source, there's a real opportunity here to create a shareware payment processing system for use by the entire shareware community.

Do consider all options before signing up for a provider.

Do remember that approximately 40 percent of your sales could come from integrated eSellers.

Don't tolerate bad service. There are too many companies who want your business.

Do be sure to give these companies feedback! The good ones will be glad to get it, and hopefully add features to their package.

Do remember that 15 percent of $30,000 in annual sales is $4,500, and that's a lot of money!

Do make a spreadsheet and calculate your payments for a month. Looking at fees one sale at a time can be very deceiving.

Providing Support

We've all been there as users... working under a deadline... stuck on a problem... the software isn't quite working right... and you need help. Enter the world of technical support.

The first rule of providing support is to always be nice to your customers. No matter what profanity they send you. No matter how rude they are. No matter how demanding they are. Rise above it, and be nice. The one problem with email is it's very difficult for both the writer to relay tone and the reader to interpret tone. And words translated from other languages to English don't always express feelings and characterizations fairly. So have patience, and err on the proper side of being courteous.

If you don't stay on top of it, support can really get overwhelming at times. Don't Panic! There are lots of things you can do to seriously reduce your support load. My own general rule is that if I receive the same question more than twice, I add the answer to my shareware Web site in one form or another. This serves one great purpose: to lower my support load. And it works. Users, for the most part, are ready and willing to read your Web site to find answers to their questions. The challenge is making it easy for them to find the answers. Here's where FAQs are so important. (Oh, don't call them FAQs. Very few users know what that those three letters mean! Spell it out: "Frequently Asked and Answered Questions".) You may want to keep your FAQs in a database so they can be exported to static web pages. A little scripting will save a lot of time here.

In addition to FAQs, an "Important Notices" section on your support pages can call attention to pressing issues. Important notices are a great way to handle problems with your software that will impact all of its users. If you release a corrupted archive accidentally (and you will, at least once) you'll definitely hear about it. So an important notice is warranted to reduce that support load. Position the "Important Notices" section on the page so the users see it before they get to your support email address. If you have too many Important Notices, they will probably be ignored. Use them sparingly.

One more thing: there's a fairly common rule of thumb that says that only 1 out of 10 users actually complain about a problem. So if you're getting 10 emails on a problem, 90 others have had the same problem and didn't bother telling you about it. Keep this in mind when supporting any and all problems with your web site and software. All support issues should be taken very seriously.

There are two kinds of support: Technical Support and Sales Support. Technical Support involves questions about the installation and use of your product. Sales Support involves any questions about registration and payment. It's good to keep them separate, as users will want to help direct their questions to the correct "department". It's also easier for you, the author, to filter the questions into the appropriate box.

The #1 sales support question, without a doubt, is "I lost my registration code, can you send it to me please?" This is the most difficult kind of question to answer automatically because if the user lost his or her code, they also lost his or her order number. And chances are the user has either moved or changed email addresses since purchasing the software. So there's no easy solution. One thing that can help is a database that allows free text searches through any field. Searching for users' names along with their cities is a good way to narrow the search. Executing such a search right from your email client is a great idea that can save you serious amounts of time (see next paragraph).

My own registration code lookup works like this: (1) I select hopefully unique and descriptive text in the user's email. (2) I click a button that executes an AppleScript. My AppleScript opens my FileMaker registrations database, searches for the text in every field, and presents me with a list of possible matches. (3) I click a checkbox next to each match for all orders the user has ever made (there may be more than one!). (4) I then execute another script that creates the registration message. This script also pastes the text back into a reply to the user. The whole process takes about 10 seconds. If you have about 10,000 customers, you can expect 1-6 of these requests per day. Not too bad. But these requests will usually spike when you release an update. This is why many shareware authors will send users their registration codes at the end of their press releases. (See eMerge above.)

The above example describes why keeping a copy of your sales database on your local machine is so important. Be sure to get details on how to mirror a sales database on your machine when you sign up with a payment processing provider. (As for the Payment Processing Providers described above, eSellerate handles mirroring to your local machine by emailing authors a tab delimited text file with the previous day's sales. Kagi, DigiBuy, and eSellerate send authors an easily parseable email with every purchase.)

Do have patience for all of your users!

Do create FAQs for frequently asked (and answered) questions.

Don't assume your users know what "FAQ" means!

Do remember that it's really hard to relay tone via email. Try to avoid misunderstandings!

Do create an "Important Notices" section for items that affect all users of a product.

Do leverage your Web content against support emails.

Do create a database of sales so you can send your users any lost registration codes.

Notes on Localization

Localization is the process of translating your software to another language. Case in point: 15 percent of my sales come from a Japan. So Localization is something that should be taken very seriously.

Software named PowerGlot will make it easy for your translators to translate your software to their native language. PowerGlot is able to parse and change resources of all types (including PowerPlant), and apply translations from previous versions of the software to the latest release. It's an excellent time saver.

Go for Launch

So you've done all of this work and you're ready for the release. Below is a checklist that you can use before you upload your updated Web site to make sure many of the necessary pieces are in place. (Included are all of the items I personally have forgotten over the years at one time or another.)

One quick note: never make a release the day before you go on vacation. If you do, it is inevitable that your release will contain a bug that will take two days to fix!

  • You've tested your software on a machine other than the one you develop on.
  • All beta-version expiration code has been removed from the software.
  • Your software "Weak Links" to libraries where appropriate.
  • Verify that your registration number scheme is working as expected.
  • Verify that your timers for registration reminders are working as expected.
  • Verify that version strings have been updated in:
    • The ReadMe file
    • The product's Web page
    • The product's 'vers' resources (all of them)
    • The product's property list
    • The press release
    • The user's manual
    • This is where generalized version numbers like 1.x or 2.x come in really handy.
  • The icons are laid out correctly in their shipping folder.
  • The archives have been stuffed and uploaded to all mirror servers.
  • You've scanned for viruses so you know that you're not distributing any bad stuff.
  • You've downloaded, unstuffed, and executed the software from each archive to verify that the archives are not corrupt.
  • You've used a tool like BBEdit to verify that all of the links on your local version of your Web site are correct.
  • You've spell checked and had someone else proof read your press release.
  • If you're using eSellerate's integrated or installer eSeller technology you've verified that the preview certificates are cleared AND disabled. Same goes for your Web eSellers.
  • If applicable, you've verified that you haven't crossed international versions with the wrong archives.
  • When assembling the email list for your users, be sure you've removed all of those users that have asked to be removed from all future mailings. A little redundancy here is a good thing.
  • Verify that you've added the contact email addresses for the public news venues.
  • The links are working from your off-site web store.
  • You've verified that the return email address for the press release is working. You may want to use a special email address for this so you can filter responses easily.

Now you're ready to upload your Web site, send out your press releases, and go to bed! If all went well, you'll wake up the next day to a few dozen sales and a bunch of happy customers. :-)

Do verify every item on the checklist before you release your software!

Do be sure your product's Web page has a version number on it so it will be found by version-tracking web crawlers. (Like VersionTracker.com)

Working from the Road

Let's face it. We don't all sit in the house all day and wait for support emails to arrive. We take vacations or go on business trips. Working from the road is easy. Just dial up once per day and answer your emails. Users who expect support will be very patient with you if you're on vacation. Users understand that even shareware developers need some time off too. :-)

Find yourself an ISP that has dialup numbers around the World. America Online comes to mind. Here's where a portable computer really comes in handy too.

If you don't want to lug around a laptop, be sure your ISP supports a Web-Mail interface so you can check your mail and respond to questions from CyberCafes. In Europe, CyberCafes appear around every corner.

Conclusion

I think we've covered just about everything... from conception, creation, testing, sales, Web sites, ISPs, downloads, mirrors, sales, support, you name it. There's nothing I've described that's revolutionary. I just tried to bring all of these little facts together into one place.

Keep your goals realistic, listen to your users, and shareware can be a really fun hobby for any programmer. And that's really the bottom line... having fun with what you do.

Do have fun writing and selling shareware!!

References

Although it's nice to close my eyes and dream that I'm the shareware king of the world, when my eyes reopen I am always reassured that it really was only a dream. Nobody works in a vacuum. There are references throughout this series to articles, utilities, and other works that take different tacks on the shareware industry. A few references I couldn't squeeze into the content of this series are below.

Rick Holzgrafe wrote an article entitled Successful Shareware. This article was reprinted by the good folks at TidBits back in 1997. Rick's shareware was so good that I snapped up a copy for myself.

Although a few years old, Colin Messitt wrote an article that details cost figures for his software as well as insights into why people register. The article is reprinted here.

MacTech ran an article a while back by Tonya Engst on How to Write a ReadMe.

Chris Smolinski over at Black Cat Systems is maintaining a list of Payment Processing Providers. It's a hard list to keep up to date, so be sure to verify all values with the Payment Processing Providers themselves.

Let's not forget all of the shareware developers who blazed the trail in an industry trend that grew incredibly fast. Just about all shareware developers will give you hints and tips. All you have to do is ask. We're all part of a community here, and working for yourself is no easy task.

And a special thanks to the O'Reilly editors!

Sanford Selznick is the owner of Selznick Scientific Software, LLC, a programming, consulting, and shareware company based in Tucson, Arizona.


Read more Developing for Mac OS X columns.

Return to the Mac DevCenter.