This is an archival post from my newsletter. Join the newsletter to get in the loop.

When I started UserScape I had no idea how to handle transactions in a B2B software company. For all that’s written about starting a software company and how to run a software company, there’s very little on what types of transactions you’ll need to support and how you should go about doing them. If you think you’re just going to put up a PayPal button and call it a day you are very very wrong!

Your customers have a variety of methods they like to pay with and so you’ll need to support those methods of payment. It’s also important to understand billing options and how they relate to payment options.

We currently have 3 billing options for HelpSpot. Credit Card (instant billing essentially), Purchase Orders with invoicing, and Invoices. Acceptable payment for these billing options are credit card (with some exceptions we’ll see below), check, bank transfer and sometimes PayPal.

The most common form of billing and payment is of course to use a credit card. Obviously you need to accept credit cards and you likely already knew that, but here’s something to keep in mind. There’s no reason you have to allow all purchases to use a credit card. Specifically, we currently only allow charges up to $2,000. This is high enough to cover the very popular 10 pack license option ($1,699), but low enough to keep our costs down. Credit card transactions can be very expensive at these higher price points. For example, most charges cost 3-4% of the transaction if you’re directly using a gateway like Authorize.net. Of course if you’re going through a third party processor like esellerate and the ilk, then it can be 10-15%. Even at 3-4% though this really ads up. A $2,000 charge costs me $80 or so. Compare that to the cost of processing a check which is $0 or doing a bank transfer which is generally $15. That’s a significant savings and can really add up.

At first I was concerned that the limit would be a negative. In fact the limit was actually impossed upon me by my merchant account bank. As a new company they capped any single transaction to $2,000. I tried to fight this because I was worried that customers wouldn’t buy if they needed to charge more, but they wouldn’t budge since I had no history. In practice it turns out that this is really a non-issue. Most companies spending more than $2,000 will want to use your invoicing options or at least have no problem using invoicing since it’s common practice. In fact I’ve never even bothered going back to my merchant bank to get the limit upped. In the one and a half years of selling HelpSpot only once has a customers wanted to pay by credit card for an amount over $2,000 and I went ahead and processed it as two transactions manually.

Now our other two billing options are somewhat intermingled. Purchase orders and invoices. Boy I wish I knew more about purchase orders before I started UserScape. Here’s the skinny on them. A purchase order is basically a contract, once you accept a purchase order from an organization there’s a contract formed that basically says they agree to pay you X and you agree to deliver Y immediately pursuant to the payment terms outlined in the purchase order. So when you receive a purchase order you’re are obligated to immediately ship the product (generally speaking) or in this case ship the license file. You then invoice the company for payment. The terms we use are Net 30 which means they must pay the full amount within 30 days. It’s common in many industries to actual provide discounts for early payments, but I haven’t had any collection issues so there’s been no need for this incentive.

Since there’s almost nothing out there on this, here’s the exact details of how the process usually works.

  • The customer decides to purchase HelpSpot and goes to their manager to receive approval for the purchase order
  • Once they have a purchase order they go to the UserScape store
  • In the store they select the invoice option and fill in the optional PO number off their PO
  • After completing the store form they also fax us the physical PO so we have a copy
  • Once we receive the PO fax the purchase is OK’d in our system and it’s marked as being a PO purchase
  • The order moves to a receivables queue and the license key file is sent since we’ve accepted the PO and are obligated to ship it
  • We send out the invoice, usually via a PDF attached to an email though we’ll also physically mail it if asked
  • Receive payment via check or bank transfer

It seems like a lot of steps, but it’s really not bad. Now it’s also possible for customers to be invoiced without a PO. Since there’s not the same contractual obligation there and in my eyes not the same level of commitment no license is shipped until payment is received. I will often extend trials as needed though so that the customer doesn’t have to do without HelpSpot while waiting for us to receive payment. In this case the process goes as follows.

  • The customer completes the UserScape store forms indicating the invoice option
  • We receive the order and send out the invoice, moving the order to the receivables queue, but no shipping the license
  • Receive payment via check or bank transfer
  • Send license once payment clears

That’s pretty much billing. It sounds a bit intimidating, but it’s really very straight forward. One big tip is to make sure your back end systems are expecting these type of transactions. If your CRM and license systems are setup to expect instant payments via credit card and you start doing invoices you’ll be in a mess trying to figure out what’s still outstanding and where everyone is at in the payment process.

For payment types, we’ve already covered credit cards so let’s jump into checks. I love checks! When I started UserScape I never thought I’d say that, I despised the idea of dealing with checks. I wanted to be completely virtual. Checks though have a unique quality that no other payment type has. They generally cost nothing to process. No middle men, nobody taking a cut, pure profit. When you’re looking at transaction fees potentially in the hundreds of dollars a trip to the bank now and then doesn’t seem so bad.

Another thing I knew nothing about when I started was bank transfers. Accepting bank transfers is really critical, especially if you’re selling to international customers and of course if you’re selling online you will be. Most international customers (outside the US) don’t like to pay with checks, it’s problematic. So they prefer to pay via bank transfers. In fact every international sale of HelpSpot, currently 25-30% of our business, has been paid by either credit card or bank transfer.

To do bank transfers you’ll need to have an account at a bank (duh). But make sure it’s an actual bank and not a credit union. The main UserScape account is at a credit union where I’ve done business for years. Unfortunately, my credit union (and I think most credit unions) didn’t have a SWIFT code. This code is often required for international transfers so if your bank doesn’t have one then a transfer can’t be done. To get around this I ended up setting up an account just for transfers at HSBC and that’s worked out very well. To do a transfer all you’ll need to send your customers is this basic information:

Bank: HSBC

Bank Address:
1 LaGrange Avenue
Poughkeepsie, NY 12603
United States of America

SWIFT: MRMDUS33
Routing: XXXXXXXX
Account: XXXXXXXX
Account Name: UserScape

That’s it and in a few days bingo bango money is in your account. The fee is usually $15 which isn’t too bad and will generally be less expensive than credit card fees.

The final way we accept payment is via PayPal. This actually isn’t a published option, but there have been 2 customers who have wanted to pay via PayPal so we have the account. Again I believe both were international and it was just easier to do it via PayPal for them.

This setup has worked out really well for the past year and a half. Customers have the flexibility to send payments in the way that works best for them and providing all the options doesn’t really add much to the work load for us. In fact the cost savings and increased sales more than makes up for the extra work.

Hopefully this post has cleared up a few things for aspiring ISV’s out there looking to enter the B2B space. I unfortunately had to figure out most of this through trial and error, so maybe it can save some of you a bit of time and money. If you’re an established ISV and have other tips and tricks please post them in the comments, there’s always more to learn.

Join my mailing list

Join my mailing list and get a copy of my ebook, Securing the Five Figure Sale, for free. Instantly.