The experience of buying your application must be painless and seamless or your potential customers will bolt before you have their cold, hard cash in your hands. We’ve spent a lot of time refining our in-application storefront, because this is actually the exact same code used by Delicious Monster Software to process all of its sales since its 11.2004 launch. This is the storefront from Delicious Library, which has won three Apple Design Awards, including “Best User Experience” and “Best Leopard Application.”
When choosing how to actually sell your software, consider that Golden % Braeburn is the only company in its market that was created by someone who uses what he sells. We didn’t write this store so we could sell the store to you, we wrote the store to sell our software to our customers, and then realized other independent developers really wanted a good, functional store, as well. We aren’t some huge company; we’re indie developers, just like you, and we know exactly what you’re going to need to run your business because we needed those things too.
Now, you could go with a service like Kagi or eSellerate, if you want to give up around 11% to 15% on a $40 sale (their rates vary based on the phases of the moon, please check their sites for details). And if you want to give up your customer experience to those guys. And you don’t want source code. (For instance, as of 06.2008, eSellerate says they haven’t gone Universal with their Mac store yet — but you didn’t want to sell to Intel Mac owners, did you?) And you don’t want to manage your customers yourself, or be able to do any sophisticated data analysis on them, and instead you trust them to some huge company. (As of 06.2008, Kagi charges your customers $5 if they want to replace their lost license codes. Yah, that’s going to make your company well-loved.) Some company has made a chart comparing prices; we don’t vouch for it, or encourage you to select based solely on price, but it’s a data point and we compare very favorably.
But perhaps the biggest problem with using another service is you look rinky-dink. You want to engender a sense of safety when your customers are buying your application, a sense that you are the real deal, and they can trust you with their money. Nothing says, “I’m making this up as I go” like all of a sudden popping up a store that says “Yahoo” or “Kagi” or whatever. It just doesn’t pass the “Mom” test: your mom doesn’t know what they are, my mom doesn’t know who they are, and you’re only confusing her and making her think, “Wait, why am I giving money to this other company? Am I doing the right thing? Is this one of those virus things I’ve heard about?”
If you love pain, you can learn about banking and taxes and speaking to Payflow Pro and credit card processing and SSL and MD5 hashes and digital signatures and certificates and databases and daemons and launchd and QuickBooks IIF and accounting, and you can write your own store. And then, just as we did in the early days, you’d get to worry about debugging it, and worry that if you screw up you’ve either stolen money from some would-be customer, lost money from a messed-up sale, or violated tax laws, and you’d worry that your system isn’t secure and some hacker will get all your customer data or steal your customer’s information from you or steal stuff from your store or break your license scheme. Even if you make no coding mistakes (we certainly made some), you still get to learn every business lesson the hard way: how to track your customers and sales, what data you’ll need for taxes, and how to do your accounting. The same lessons we had to learn.
Eventually, you’d have a working store, and you wouldn’t have to pay us a dime. Except, your time is worth money, isn’t it? You could have spent that time making your application cooler, to sell more copies and generate more buzz from existing customers, instead of re-writing the exact same code that we’ve already written. Your competitors are going to be spending their time making their actual applications better, and your customers won’t know or care that you wrote your store yourself; the only thing they’ll notice is the months and months and months that you were not able to spend making your app better, because you were working on a store. At Delicious Monster, we had to write our own store, because when we launched we couldn’t license one that we thought was decent (we tried). You have another choice.
Sign up with Golden % Braeburn, and get this Cocoa source code: our in-application store front end, our store back end (which processes the credit cards and records the transaction on your server), our expo store (a simplified front end that requires only a credit card swipe on a USB card reader and immediately prints a license on an attached printer), our remote office client (so you can issue press licenses and look up lost licenses when you’re on the road), our QuickBooks integration tool (so you can dump your transactions into QuickBooks with one click, and make your accountant very happy and pay your sales tax on time), plus our on-the-fly localization framework, our AppleScript integration framework, and more... ‘more’ because we’re constantly adding to the code ourselves, and all Golden % Braeburn clients will be sharing their modifications with us and you, so we’ll have a whole community of hand-picked developers who are constantly making your store better, for free. Want a web front-end so you can sell T-shirts, too? Well, we’re already working on such a thing. Want to process more types of credit cards? Add the code yourself, or just wait for one of our other clients to do it. You are in control, but you didn’t have to write all the code.
Look, if you’re in the market for an operating system, you don’t write one yourself. You go with one that works really well, and you build your application on top of it, so you spend your time writing the code that is new and unique to your app, instead of re-inventing the same damn wheel and axle and engine.
Use our engine to sell your application.
When choosing how to actually sell your software, consider that Golden % Braeburn is the only company in its market that was created by someone who uses what he sells. We didn’t write this store so we could sell the store to you, we wrote the store to sell our software to our customers, and then realized other independent developers really wanted a good, functional store, as well. We aren’t some huge company; we’re indie developers, just like you, and we know exactly what you’re going to need to run your business because we needed those things too.
Now, you could go with a service like Kagi or eSellerate, if you want to give up around 11% to 15% on a $40 sale (their rates vary based on the phases of the moon, please check their sites for details). And if you want to give up your customer experience to those guys. And you don’t want source code. (For instance, as of 06.2008, eSellerate says they haven’t gone Universal with their Mac store yet — but you didn’t want to sell to Intel Mac owners, did you?) And you don’t want to manage your customers yourself, or be able to do any sophisticated data analysis on them, and instead you trust them to some huge company. (As of 06.2008, Kagi charges your customers $5 if they want to replace their lost license codes. Yah, that’s going to make your company well-loved.) Some company has made a chart comparing prices; we don’t vouch for it, or encourage you to select based solely on price, but it’s a data point and we compare very favorably.
But perhaps the biggest problem with using another service is you look rinky-dink. You want to engender a sense of safety when your customers are buying your application, a sense that you are the real deal, and they can trust you with their money. Nothing says, “I’m making this up as I go” like all of a sudden popping up a store that says “Yahoo” or “Kagi” or whatever. It just doesn’t pass the “Mom” test: your mom doesn’t know what they are, my mom doesn’t know who they are, and you’re only confusing her and making her think, “Wait, why am I giving money to this other company? Am I doing the right thing? Is this one of those virus things I’ve heard about?”
If you love pain, you can learn about banking and taxes and speaking to Payflow Pro and credit card processing and SSL and MD5 hashes and digital signatures and certificates and databases and daemons and launchd and QuickBooks IIF and accounting, and you can write your own store. And then, just as we did in the early days, you’d get to worry about debugging it, and worry that if you screw up you’ve either stolen money from some would-be customer, lost money from a messed-up sale, or violated tax laws, and you’d worry that your system isn’t secure and some hacker will get all your customer data or steal your customer’s information from you or steal stuff from your store or break your license scheme. Even if you make no coding mistakes (we certainly made some), you still get to learn every business lesson the hard way: how to track your customers and sales, what data you’ll need for taxes, and how to do your accounting. The same lessons we had to learn.
Eventually, you’d have a working store, and you wouldn’t have to pay us a dime. Except, your time is worth money, isn’t it? You could have spent that time making your application cooler, to sell more copies and generate more buzz from existing customers, instead of re-writing the exact same code that we’ve already written. Your competitors are going to be spending their time making their actual applications better, and your customers won’t know or care that you wrote your store yourself; the only thing they’ll notice is the months and months and months that you were not able to spend making your app better, because you were working on a store. At Delicious Monster, we had to write our own store, because when we launched we couldn’t license one that we thought was decent (we tried). You have another choice.
Sign up with Golden % Braeburn, and get this Cocoa source code: our in-application store front end, our store back end (which processes the credit cards and records the transaction on your server), our expo store (a simplified front end that requires only a credit card swipe on a USB card reader and immediately prints a license on an attached printer), our remote office client (so you can issue press licenses and look up lost licenses when you’re on the road), our QuickBooks integration tool (so you can dump your transactions into QuickBooks with one click, and make your accountant very happy and pay your sales tax on time), plus our on-the-fly localization framework, our AppleScript integration framework, and more... ‘more’ because we’re constantly adding to the code ourselves, and all Golden % Braeburn clients will be sharing their modifications with us and you, so we’ll have a whole community of hand-picked developers who are constantly making your store better, for free. Want a web front-end so you can sell T-shirts, too? Well, we’re already working on such a thing. Want to process more types of credit cards? Add the code yourself, or just wait for one of our other clients to do it. You are in control, but you didn’t have to write all the code.
Look, if you’re in the market for an operating system, you don’t write one yourself. You go with one that works really well, and you build your application on top of it, so you spend your time writing the code that is new and unique to your app, instead of re-inventing the same damn wheel and axle and engine.
Use our engine to sell your application.
You’ll add our storefront source code into your application — your particular store will be configured by you specifically for your product, using our template. Often there will be a couple of purchasing options you’ll present to the user (ie, multiple licenses, professional vs. normal versions, discount upgrade versions), and then the store asks for her credit card info. All the user’s vitals (name, address, phone, e-mail) are automatically copied out of her Address Book, so the only thing she has to type during this entire process is her credit card info. That is seamless.
When the user clicks “buy”, your server machine (running the Golden % Braeburn store back end) is contacted, her credit card is processed, and the application instantly licenses itself over-the-wire and a license code is mailed to her (for her records). She’s ready to go, with no additional typing! There’s no copying codes out of a web browser or clicking on something in an e-mail later — your application is fully functional for your customer the instant after she presses the buy button.
Since the store runs as a sheet inside your application, it provides a very secure feeling to the user compared with launching a web browser and then opening a website somewhere. Users have been trained to fear the web, and especially fear web browser windows popping open unbidden. The buying experience is also totally customized; you won’t open up some generic storefront (possibly with someone else’s name on top) and require the customer to find your product somewhere and add it to some basket and then do the check-out dance — the in-application store has one purpose, which is to sell the user a license to your particular product.
When a user launches your app for the first time, you can decide how you will prompt her to license the application: a sheet can immediately pop up that asks if she’d like to purchase a license before continuing, or the app can run in a limited demo mode and prompt her only when she tries to do something that requires a license. Or both of those. Or something new. It’s up to you — you’ve got the source code.
When the user clicks “buy”, your server machine (running the Golden % Braeburn store back end) is contacted, her credit card is processed, and the application instantly licenses itself over-the-wire and a license code is mailed to her (for her records). She’s ready to go, with no additional typing! There’s no copying codes out of a web browser or clicking on something in an e-mail later — your application is fully functional for your customer the instant after she presses the buy button.
Since the store runs as a sheet inside your application, it provides a very secure feeling to the user compared with launching a web browser and then opening a website somewhere. Users have been trained to fear the web, and especially fear web browser windows popping open unbidden. The buying experience is also totally customized; you won’t open up some generic storefront (possibly with someone else’s name on top) and require the customer to find your product somewhere and add it to some basket and then do the check-out dance — the in-application store has one purpose, which is to sell the user a license to your particular product.
When a user launches your app for the first time, you can decide how you will prompt her to license the application: a sheet can immediately pop up that asks if she’d like to purchase a license before continuing, or the app can run in a limited demo mode and prompt her only when she tries to do something that requires a license. Or both of those. Or something new. It’s up to you — you’ve got the source code.
When your customer clicks “buy,” the storefront client code in her copy of your application will contact the store server that you will have running on your secure Mac. This machine doesn’t have to be anything fancy: at Delicious Monster we ran for years on a Mac Mini with external USB drives on a software RAID 1. Remember, you aren’t going to process 1,000 transactions a minute (this would be, like, billions of dollars of revenue a year), so the machine just has to run OS X 10.5 Leopard, and have disks that won’t crash and lose data. We actually recommend keeping your transactions on a hardware RAID since they are very hassle-free, and we can advise you on setting this up.
Continuing to trace the transaction, the store server (at your location) contacts PayPal (formerly VeriSign Payment Services) using their proprietary XML protocol (called Payflow Pro), and asks them to verify and run the credit card. If the transaction is approved, our licensing framework is invoked and a new license is created for the user. Regardless of transaction success or failure, a new customer record and transaction record are created with the results, and stored in an SQL database AND written to an XML file (for double-safe backup), so you have a complete list of all your customers, their license keys, and any fraudulent attempts on your server. Credit card information is NOT stored on your machine at any point, so even if you get hacked you won’t get sued. (There are many laws governing storing credit cards on a machine, we have decided it is best to not mess with that at all — it’s too dangerous and there’s no real advantage to it since PayPal remembers the numbers and issues refunds itself.)
Assuming the transaction succeeds, e-mail is automatically sent to the customer and the new license code is also sent over the wire back to your application while it runs. E-mail is also sent to you, so you have a third way to keep track of receipts; you really never want to lose customer data. You can even configure your store server to automatically send e-mail to fulfillment houses if you ship physical products and the customer has ordered one of them (as Delicious Monster does when it sells Bluetooth LASER scanners).
PayPal automatically deposits the money you’ve made into your main bank account every day. And voila, you’ve got cash.
You’ll notice that at no time do you personally have to interfere with this process; you don’t have to keep breaking into your day to run a separate license generation application and send e-mail to a customer yourself when you get e-mail from your store service. You can literally be on a beach all month with no network access and your store will be happily processing sales and sending out license codes (or, more likely, you can be writing code all day, and not have your flow interrupted).
Continuing to trace the transaction, the store server (at your location) contacts PayPal (formerly VeriSign Payment Services) using their proprietary XML protocol (called Payflow Pro), and asks them to verify and run the credit card. If the transaction is approved, our licensing framework is invoked and a new license is created for the user. Regardless of transaction success or failure, a new customer record and transaction record are created with the results, and stored in an SQL database AND written to an XML file (for double-safe backup), so you have a complete list of all your customers, their license keys, and any fraudulent attempts on your server. Credit card information is NOT stored on your machine at any point, so even if you get hacked you won’t get sued. (There are many laws governing storing credit cards on a machine, we have decided it is best to not mess with that at all — it’s too dangerous and there’s no real advantage to it since PayPal remembers the numbers and issues refunds itself.)
Assuming the transaction succeeds, e-mail is automatically sent to the customer and the new license code is also sent over the wire back to your application while it runs. E-mail is also sent to you, so you have a third way to keep track of receipts; you really never want to lose customer data. You can even configure your store server to automatically send e-mail to fulfillment houses if you ship physical products and the customer has ordered one of them (as Delicious Monster does when it sells Bluetooth LASER scanners).
PayPal automatically deposits the money you’ve made into your main bank account every day. And voila, you’ve got cash.
You’ll notice that at no time do you personally have to interfere with this process; you don’t have to keep breaking into your day to run a separate license generation application and send e-mail to a customer yourself when you get e-mail from your store service. You can literally be on a beach all month with no network access and your store will be happily processing sales and sending out license codes (or, more likely, you can be writing code all day, and not have your flow interrupted).
Transactions are stored using Apple’s CoreData technology in an industry-standard SQL database, so your data is yours to play with. We provide both an on-server front end Cocoa application that shows you your database and a client/server Remote Office application that you can use on the road, so if a user calls you up and says, “Hi, I’m from Wisconsin and I think I bought a license under ‘Mike’ but I don’t know if I used my old last name or my new one,” you can find his license with just a few clicks no matter where you are. And if our apps don’t currently do what you want, modify them!
Since we’re using this system to process thousands and thousands of transactions, it’s very important to us that everything be automated. As often as you like, you can run a special utility that will dump your customer sales data from your store server into QuickBooks IIF format, which you can then read in to your company’s data file. If you set up QuickBooks correctly it will automatically figure out what you owe various tax agencies, and you’ll be able to run all your financial reports inside QuickBooks.
QuickBooks is not included with our storefront; you have to purchase it yourself. It is highly recommended, but not required - you can keep track of your finances using an abacus if you’d prefer. Every accountant we’ve met accepts QuickBooks files from their clients and can pretty much file all your taxes based on two reports, so we believe QuickBooks to be a huge timesaver.
Since we’re using this system to process thousands and thousands of transactions, it’s very important to us that everything be automated. As often as you like, you can run a special utility that will dump your customer sales data from your store server into QuickBooks IIF format, which you can then read in to your company’s data file. If you set up QuickBooks correctly it will automatically figure out what you owe various tax agencies, and you’ll be able to run all your financial reports inside QuickBooks.
QuickBooks is not included with our storefront; you have to purchase it yourself. It is highly recommended, but not required - you can keep track of your finances using an abacus if you’d prefer. Every accountant we’ve met accepts QuickBooks files from their clients and can pretty much file all your taxes based on two reports, so we believe QuickBooks to be a huge timesaver.
We will provide our store to the makers of high-quality Mac software who want to run their own store. Because we don’t charge an up-front fee and each customer we take on requires support from us, we will be a little picky on who we take on... but if you are a Mac software developer and you are interested in using Golden % Braeburn’s store solution, please contact us.
We provide you with your own Subversion account on our master server, so you can download all of our store-related source code (and extra goodies), and we’ll help you (within reason) get it set up. (You should be good at Cocoa and familiar with the UNIX command-line or this is probably going to be over your head.)
You’ll set up your price list inside your version of the source code, and configure your server machine — we have instructions on how to set up your firewall and launchd to get the store to talk to the network. Your store machine will need a “fixed IP address” so your clients can find it reliably, so make sure your net provider can give you one. You don’t need a particularly fast net connection — transactions can take a second or so and customers don’t care.
Here’s the source code you get:
We provide you with your own Subversion account on our master server, so you can download all of our store-related source code (and extra goodies), and we’ll help you (within reason) get it set up. (You should be good at Cocoa and familiar with the UNIX command-line or this is probably going to be over your head.)
You’ll set up your price list inside your version of the source code, and configure your server machine — we have instructions on how to set up your firewall and launchd to get the store to talk to the network. Your store machine will need a “fixed IP address” so your clients can find it reliably, so make sure your net provider can give you one. You don’t need a particularly fast net connection — transactions can take a second or so and customers don’t care.
Here’s the source code you get:
- In-application Storefront
- Store Server (which processes the credit cards and records the transaction on your server)
- Expo Store (a simplified front end that requires only a credit card swipe on a USB card reader and immediately prints a license on an attached printer)
- Remote Office client (so you can issue press licenses and look up lost licenses when you’re on the road)
- QuickBooks integration tool (so you can dump your transactions into QuickBooks with one click, and make your accountant very happy and pay your sales tax on time)
- On-the-fly localization framework (to make internationalization and localization of your application much simpler for you and your localizers)
- AppleScript integration framework (allows your customers to add new scripted menu items anywhere in your application’s menus
- Plus, any future changes by us or any of the other Golden % Braeburn licensees
Our goal is to provide the best experience for your customers, and the least hassle for you.
There is no sign-up fee. There is no annual fee. There are no monthly fees. There’s no fixed per-transaction cost (eg, $1 per transaction) &mdash our only fee is 5% of the transactions you run using our storefront or store server software. We don’t ask you to be exclusive; you are still allowed to sell your software using any other method you want, and if it doesn’t use any of our software we don’t ask for any money from those sales.
Our 5% is on top of the approximately 2.4% to 3% that your bank and the VISA network will take from each transaction they process. You can negotiate this fee with your bank yourself, but there is no way to avoid it entirely; it’s how the VISA network makes its money. Thus, the total amount you’ll lose from each transaction will be around 8% (depending on what rate you negotiated with your merchant bank). You’ll also need to pay PayPal each month to maintain your account with them ($49 per month as of 06.2008).
Note that we’re not trying to be weaselly with the 5% + ~2.4..3% business; we separate those out because all you are ever going to pay us is the 5%. The bank will be taking their cut before they ever deposit the money into your account, and PayPal will bill you monthly. We’re trying to be fair by telling you who else we expect will want a piece of you using our current store software, but you are absolutely welcome to pick your own, cheaper payment solution and rewrite the file that does the credit card authorization to use that. (We’d love it, actually.)
You can compare this with other solutions like Kagi and eSellerate which take a much higher percentage and, among many things, don’t provide a customizable in-application storefront, don’t give you source code, don’t let you manage your customers yourself, nor access to a community of Macintosh developers working together to produce the best e-commerce solution available. Here’s a chart comparing prices, which may or not be accurate — it’s not our chart, so caveat emptor.
There is no sign-up fee. There is no annual fee. There are no monthly fees. There’s no fixed per-transaction cost (eg, $1 per transaction) &mdash our only fee is 5% of the transactions you run using our storefront or store server software. We don’t ask you to be exclusive; you are still allowed to sell your software using any other method you want, and if it doesn’t use any of our software we don’t ask for any money from those sales.
Our 5% is on top of the approximately 2.4% to 3% that your bank and the VISA network will take from each transaction they process. You can negotiate this fee with your bank yourself, but there is no way to avoid it entirely; it’s how the VISA network makes its money. Thus, the total amount you’ll lose from each transaction will be around 8% (depending on what rate you negotiated with your merchant bank). You’ll also need to pay PayPal each month to maintain your account with them ($49 per month as of 06.2008).
Note that we’re not trying to be weaselly with the 5% + ~2.4..3% business; we separate those out because all you are ever going to pay us is the 5%. The bank will be taking their cut before they ever deposit the money into your account, and PayPal will bill you monthly. We’re trying to be fair by telling you who else we expect will want a piece of you using our current store software, but you are absolutely welcome to pick your own, cheaper payment solution and rewrite the file that does the credit card authorization to use that. (We’d love it, actually.)
You can compare this with other solutions like Kagi and eSellerate which take a much higher percentage and, among many things, don’t provide a customizable in-application storefront, don’t give you source code, don’t let you manage your customers yourself, nor access to a community of Macintosh developers working together to produce the best e-commerce solution available. Here’s a chart comparing prices, which may or not be accurate — it’s not our chart, so caveat emptor.
© 2008 Golden % Braeburn