CloudContacts Archive

A month ago, we switched our payments on CloudContacts from Paypal and Google Checkout to the new payments service from Stripe. I’ve been meaning to post about why we switched and since Greg Taylor posted today about his switch to Stripe, I figured this was a good time to start my string of posts about my online commerce payments research I’ve completed over the past few months. There is a good discussion of Greg’s post on Hacker News. Greg mainly discusses moving from Paypal to either WePay and Stripe and ultimately selecting the latter.

When I launched CloudContacts two years ago, I made the decision to use Paypal and Google Checkout as the payment services we would offer because after speaking with friends and colleagues, it seemed like people trust these services and as a new service, customers might be more likely to pay with one of these services. Initially we used a shopping cart with E-Junkie.

Shortly thereafter we created a custom checkout which had the following flow:

• CC Order Form > off site > PP/GC > back to site >CC Thank You

It seemed like everything was going well — every once in a while we would get an inquiry from a potential customer that they wanted to pay with a credit card and we explained that you could use a credit card on both Paypal and Google Checkout.

And then I started to do some analysis and realized the biggest mistake I’ve made with CloudContacts to-date. What I found was that a number of customers filled in our order form, went off to Paypal or Google Checkout, but never completed the order. Many of our business customers aren’t web savvy and the fact that they had to input their info twice if they needed to create a pp/gc account was just a headache. I know we all think that everyone has a Paypal and Google account but this really isn’t the truth and even if someone has a Google account, it doesn’t mean they have set it up with Payments (now Wallet) access and information.

I emailed a few of them and asked if they would explain why they didn’t complete the purchase and the overwhelming response was that it was just too much work and that they didn’t have Paypal nor Google accounts.

Continue reading “Moving to Stripe: Fixing the Biggest Mistake I’ve Made to Date” »

Over the holiday break, I decided to look into creating a CloudContacts app for placement in the Google Chrome Web Store. I’d like to share some thoughts on how the process went from both the developer and usability perspectives. I looked around at a number of the apps in the Chrome Web Store and found that many were just bookmarks to the actual website. Some apps, like the Amazon Web Shop looks like it is a full app using HTML5 which provides a pretty neat store browsing experience. Seesmic CEO Loic Le Meur confirmed that their social media app provides additional functionality when installed via the Chrome Web Store.

One note…I only have experience using the Google Chrome Web Store via the Chrome web browser. I don’t have the Google Chrome OS or one of the new Google Cr-48 netbooks.

I won’t go deep into the development of the app here, I will write another post later this week on HTMLCenter. The basic decision is whether you want to build an installable web app or a packaged web app.  You can also publish a Chrome Theme or an Extension inside of the Chrome Web Store. Installable web apps can be as simple as a bookmark to a website similar to what I created for CloudContacts or can be more robust as in the Seesmic and Amazon examples I noted above.

Creating the basic app is easy — just a few lines of code in a text file, an icon of your service and a zip file containing both files. You are required to pay $5 fee to “register” as a developer before you can publish any apps to the Chrome Web Store.  After you upload your app, you are taken to a control panel for the app. Here you can set items including pricing, categories, default language, detailed description of the app and other items including if the app has mature content. You can select to tie the app into a Google Analytics account and select to use OpenID for authentication. Lastly, you can upload a variety of screenshots including some promo screenshots in case Google decides to feature your app (Seesmic is one of the featured apps).

After all of the selected changes are complete, you can publish the web app to either a selected list of testers or to the world. I found the usability on this testing functionality to be lacking. Like any good developer, I decided to send the app to CloudContacts team members and to other colleagues so they can test and provide feedback. After I received a number of suggested changes, I was ready to hit the big button and make the web app live to all. Unfortunately that isn’t possible. The publish button was replaced with the following text, “Publishing to test accounts will make the app available only to trusted testers you choose. You will need to create a new listing to publish your app to all users when you are done with testing.” I had to manually copy over all of the elements into a new web app and then publish that app to the world.  This is just not good practice because the typical process is to move forward to production with an app that has been tested. Instead I had to just hope I copied everything over correctly.

Continue reading “My First Experience Developing An App for the Google Chrome Web Store” »

Last month at the SXSW conference, Twitter executives announced the launch of @Anywhere — their simple service which allows websites to connect with Twitter. Mathew Ingram at GigaOm has a recap of the initial announcement including a video with Twitter CEO Evan Williams.

At the Twitter Chirp developer gathering last week, the @Anywhere functionality went live. Nick O’Neill has an overview of how to integrate Twitter @Anywhere into your blog.

Continue reading “My First Experience With Twitter @Anywhere” »