More soon!

No related posts.

Related posts:

1. Selling Campaign Monitor to Your Customers
2. 10 Reasons Why Campaign Monitor Rocks
3. Turn your RSS feed into an e-mail newsletter!

I’m just as guilty of this as the next guy… your number 23 on hold for phone support or your routine has been disrupted by product changes or something you have no control over and you fly off the handle at anyone or anything without thinking. Like SitePoint I recently made some modifications in one of my programs that users didn’t quite understand and instead of engaging me in open and civil dialog I received a number of very pissed and clearly unhappy e-mails. Why is it that when these sort of things happen we rush to anger instead of calmly and collectively reaching out to the person or companies involved to see if there is anything that can be done to correct what we see as a problem?

Your thoughts?

Related posts:

1. Your thoughts: Do web apps need offline components?

One of the difficulties when selling software that needs to be installed is making sure the software is compatible with the users computer/system. I know this is supposed to be a responsibility of the user, but if they make a mistake they will be contacting you for support. Fever takes a unique approach to confirming users are installing the software on compatible machines. Shaun has created a process that links a compatibility check with his checkout/licensing process so that users can only purchase a license if they are installing the program on a compatible machine.

Before you can purchase a license you first download a small package that you upload to the location where you intend on installing the program. From there the package checks your systems compatibility and asks for database information (shown in the image above). Once entered, and after privileges have been checked, you are provided with a link back to the Fever site that populates the purchase form with a unique ID. This ID, I assume, matches your site with the compatibility check performed and then you continue with purchasing the license.

This process is genius! It allows the developer to prove the user is going to be installing the software on a compatible machine before selling them a license. I can image this process greatly reduces, if not eliminates, the support requests having to do with system compatibility and installation issues. Very cool idea!

No related posts.

For those viewers following along at home, if you look at the configuration page, I’m going to cover each section in reverse order wrapping up with setting up your subscription plans.

Site Details

The site details section is where, you guess it, you enter the details of the site you are going to be integrating with Spreedly. The information requested on this form is pretty straight forward so I’m just going to touch on 2 parts.

URLs

About half way through the form they ask for 3 URLs:

1. Subscriber Changed Notification URL

   Since you are using a system that is external to your application to handle payment processing you will have to work out some way to sync the two so your sure people have only those accounts they have paid for. That’s where the subscribers changed notification URL comes into play. When subscriber data within Spreedly changes, the service will POST a comma separated value list of subscriber IDs to the address you specify here. It then becomes your responsibility to process those changes and sync them with your application.

2. Individual user URL on your site

   This is the address that users visit to view their specific information in your program. Spreedly uses this address to redirect users back to your program from their update screen.

3. Subscription selection URL on your site

   This is that place in your program where users can upgrade/downgrade their account. Again, Spreedly uses this address to redirect users back to your program from their system.

I will come back to these URLs later in the series so go ahead and leave them blank for now.

API Authentication Token

At the bottom of the site details form you will find your sites API Authentication Token. This is the token you will use when interacting with the Spreedly API. Be sure to handle with care and keep it a secret… you can always generate a new one if you need to. Make note of this because we will be using it in the posts to come.

Manage Site Users

One of the really nice things about Spreedly is that you can add as many users to your account as you wish without hitting any limits. So, if your organization has a 10 person support/accounting team (wishful thinking perhaps) you can add them all with their own access information from the Manage Site Users section.

Payment Gateway

The Payment Gateway section is where you will go when you’re ready to take your site out of testing and into production. You will have to upgrade your Spreedly account from a test site to a production site and either sign-up for the monthly pricing option or bite the bullet and get a Kickstart package. For the time being, the page just displays some example CC numbers you can use to generate different errors.

Subscription Plans

Now to the important stuff! The Subscription Plans section is where you setup your applications different subscription plans and pricing. By default, Spreedly has setup one example plan to give you an idea how things work. I will issue one word of caution here, you CANNOT delete subscription plans. I hope this is coming soon, because I have made a mess out of my other account, but for right now it can’t be done. Just keep this in mind as you enter your plans.

I want to draw your attention to 2 pieces on this form:

Feature Level

The feature level is the name with which you will refer to the subscription plan through the API. You want to keep this simple yet specific so you can easily match it up with a subscription type. I typically just repeat the plan name as one word lowercase just to keep it easy.

Plan Type

The type of plan is where you can specify if this is a regular subscription, gift subscription or free trial. This really gives you a lot of options when setting up your applications pricing structure. You can set the amount of time each plan is valid for before charging the user again (number of days or months). You can also specify if you want to require auto-recurring purchases (you only accept auto-recurring payments) or not. The sky’s the limit!

That’s it!

After you play around with your settings and subscription types a little bit you will have a configured Spreedly test account ready to accept subscribers. In the next post I’m going to take a break from the Spreedly specific stuff for a little while and talk about planning your sign-up/checkout process and determining how that’s going to work with your newly configured Spreedly account.

Related posts:

1. Speedy Subscriptions Using Spreedly (Part 1) – Overview & Account Setup
2. Building Applications using CodeIgniter (Part 2) – Configuration

What is Spreedly?

Aside from the best thing since sliced bread… Spreedly is a service that takes the hassle out of collecting subscription fees for web based services/applications. Developing applications that use 3rd party payment gateways and that sell recurring subscriptions is a difficult and often expensive undertaking. Spreedly simplifies the process by handling the complex task of subscription management and payment processing for you so you can focus your time and money on your product.

After configuring your Spreedly account and entering your subscription types and pricing scheme, the service will handle all the payment gateway interaction and user subscription management for you… no muss no fuss. Accepting payments literally becomes as easy as redirecting your user to a Spreedly URL and having them enter their credit card information. That’s it!!

Supported Gateways

It’s important to understand that Spreedly is not a payment gateway. Spreedly simply acts as the middle man between your application and your selected gateway using APIs. This means you will still need to find a payment gateway and merchant account (if necessary). The simplest, and cheapest, option is probably PayPal because it’s a gateway and merchant account all-in-one. But if that doesn’t work for you, Spreedly currently supports the following gateways:

• Authorize.net (Only US dollars)
• Beanstream (Only Canadian dollars)
• eWAY (Only Australian dollars)
• PayPal Website Payments Pro (also UK)
• PayPal Express Checkout (also UK)
  (does not currently support automatically recurring subscriptions)
• Sage Pay (formerly Protx)
• USA ePay (Only US dollars)

They are constantly adding new gateways to the service so be sure to visit their site for the most updated list. If you don’t see your gateway listed above the odds are good that they can add it for you. Just contact their support team and they will research what’s involved.

Pricing

Accepting credit cards online is an expensive proposition… that’s why I have avoided it up until now. There are bank fees for merchant accounts, fees for each transaction, monthly fees for the payment gateway, etc… not to mention the percentage of each transaction that certain parities take just because they can. It’s enough to make you dizzy!

The pricing for Spreedly is pretty straight forward:

$19 per month + transaction fees

• 3% on the first 50 transactions per month
• 2% on transactions 51 through 5000
• 1% on all transactions after 5000

The thing to point out here is that the Spreedly fees will be on top of whatever your payment gateway charges. In the end you are still probably looking at a decent sum of money… but odds are it’s still cheaper (programming included) than if you went it alone or with another service.

If there are too many monthly fees for you to handle, Spreedly also has another pricing option called the Kickstart package. For one single payment of $699.00 you can get a Spreedly account for life with:

• a frozen per-transaction fee of 1%
• no monthly fees
• and it never expires!!

It pays to keep an eye on the Spreedly site (and maybe follow their Twitter account) for special offers because when they first launched Kickstart the price was $499.00 for a limited time. So there are opportunities for picking up deals if you pay attention.

Account Setup

Now that you have a basic understanding of what Spreedly is, let’s go ahead and create a test account. Spreedly makes it super easy to get your bearings and see how the system works without spending any money. You can sign-up for a free test account (which gives you access to everything you need) and see if it will work for you. To create your account, visit https://www.spreedly.com/signup and fill out the form.

After signing-up you will be directed to your test site overview page (shown above). The overview page gives you a summary of your account in terms of transactions and subscribers. You can click around the interface if you like but it’s going to be pretty empty until we start submitting transactions (which we’ll get to later in this series).

That’s a wrap

That does it for the Spreedly intro. In the next post I will review how to configure your account and setup your subscription plans/pricing scheme.

I’m just getting started with Spreedly so stay tuned!

Related posts:

1. Speedy Subscriptions Using Spreedly (Part 2) – Account Configuration

Related posts:

1. Implementing Facebook Connect (Part 1) – What is Facebook Connect?
2. Implementing Facebook Connect (Part 3) – Accessing Data from Facebook
3. CI Inferno

“The National Center for Missing & Exploited Children (NCMEC) has been instrumental in improving the recovery rate from 62% to 96%.” – NCMEC Timeline

The NCMEC is the nations resource for child protection and is celebrating 25 years of service in 2009. In this day in age when kids can log onto the Internet and befriend anyone with a screen name it’s more important than ever that we have organizations like the NCMEC to aid in the recovery of lost children and prevention of child exploitation. That’s why I’ve chosen the NCMEC as by cause to blog for. You can learn more about the NCMEC by viewing this promotional video available on their website.

This blog post is part of Zemanta’s “Blogging For a Cause” campaign to raise awareness and funds for worthy causes that bloggers care about.

No related posts.

So far in this series I’ve discussed my typical application structure, configuration and helper files when developing apps using CodeIgniter (CI). In this final post I’ll review creating code templates for quick consistent development.

There is nothing really functional/technical about code templates. Templates are a set of simple files that have the basic document structure for the specified file (controller, model, library, etc.) that you use as a common starting point when creating any new file for your app. Your template should contain common elements to all files like the header comment block, class declaration, constructor, etc. There is no need to come up with your own standard when creating your templates because CI has a very nice style guide you should follow.

CI Style Guide

A few versions ago, CI added a page to their users guide entitled PHP Style Guide. In this section they do a great job at outlining the proper format when declaring variables, writing comments, naming files, etc. This is a great place to start when creating your templates. If you don’t already, you should think about getting in the habit of following these standards (even if you aren’t programming with CI) because they will help keep your code clean and consistent.

Template Files

Before I start coding my app I typically create a template file and place it in the controller and model folders. The templates are different of course, but they both create a nice starting point whenever I need to create a new file. It’s important to note that you don’t necessarily have to create physical template files to accomplish clean and well formatted code. Some tools like Coda and TextMate give you the ability to save bits of text and reuse them in your files. So you could create your header comment block and save it in your editor and just call upon that whenever you create a new file. Doesn’t really matter how you do it, it just matters that you do.

That’s a Wrap

OK… lecture over. That does it for the building applications using CodeIgniter post series. If interested, you can download a copy of the final CI install that we’ve created over the last 4 posts with helpers, code templates and all.

I hope by sheding some light on my process and explaining how I do things you came up with some ideas on how you can improve your own CI apps. As always, feel free to leave any questions or feedback as a comment below.

Related posts:

1. Building Applications using CodeIgniter (Part 1) – File Structure
2. Building Applications using CodeIgniter (Part 3) – Helpers
3. Building Applications using CodeIgniter (Part 2) – Configuration

What belongs in a helper?

Something I’ve struggled with in the past is determining when a certain function or process belongs in a helper file and when it would be better off elsewhere. There is no cold hard rule for determining when something belongs in a helper and when it doesn’t but you do need to be aware of the following:

“Unlike most other systems in CodeIgniter, Helpers are not written in an Object Oriented format. They are simple, procedural functions. Each helper function performs one specific task, with no dependence on other functions.”
- CI Users Guide

This means that in order to access libraries and models within your helper functions you will need to get a CI instance:

$CI =& get_instance();

With the technicalities out of the way let’s take a look at the 2 helper files I’ve developed: display_helper.php and  flash_helper.php.

display_helper.php

A lot can be accomplished with CI’s built in templating but there are still some things that require logic and therefore fit nicely within a helper function. The display_helper.php file holds a number of common HTML display functions that I use throughout my program view files. To see what this file looks like, download an example. The functions in this file are pretty self-explanatory but I will briefly describe what each does below:

display_error()

The display_error() function displays a properly formatted HTML error message. I have this function setup so it can display 2 types of message: standard and form. When using the form_validation library I use the set_error_delimiter() method to wrap my error messages in list item tags and then display form error messages as unordered lists. So, I can easily accomplish displaying both types of messages using this function just by passing some variables.

display_msg()

This function just displays a properly formatted HTML message. This doesn’t necessarily need to be in a helper function because it’s so simple. But, the nice thing about having it here is if I ever decide to change the format of my messages I just need to come here in one place and make the update. So it consolidates my code nicely… but the same could probably be accomplished by using more generic CSS ID names.

req_field()

You should always identify required fields on your forms so users know what they need to fill in and what can be left blank. I’ve put the display of this flag in a helper function again to consolidate my code. As with the display_msg() function, if I ever decide to change my required field flag I just need to come to this one place and change it instead of going into all my view files and going a find and replace.

js_confirm()

JavaScript confirmation messages come in handy when you want to check with a user to make sure they are sure of something before you do it. You can accomplish the same confirmation by writing more PHP but that takes more work. The js_confirm() function, when used with the default CI URL helper anchor() function, displays a browser pop-up message with whatever text I pass to the function. If I’m in a hurry and don’t provide a message the function just returns a generic “Are you sure?” message.

Your display_helper file might look much different than mine, this is just an example of how I use it. But you want to be on the look out while your coding for repetition and little details here and there that might be changing down the road. If you can consolidate those things in a helper file you will end up saving a lot of time updating down the road.

flash_helper.php

CI added flashdata to it’s session library a few versions back and I for one was happy to see it. Flashdata allows you to pass messages for display between pages.  Simple status messages like “record added” or “record not found” can be placed in a flashdata variable and then displayed after the user is redirected to another page. A very handy tool for letting your users know the results of their actions.

While I do like this functionality, writing $this->session->set_flashdata(’item’, ‘value’) and $this->session->flashdata(’item’) every time I need to set or get something is a lot of typing. So the flash_helper is a pair of wrapper functions that handle the job of setting and displaying flash messages for me. To see what this file looks like, download an example.

display_flash()

The display_flash() function displays a selected flash message in a view file. Simply provide the name of the flash variable and it will display it in a properly formatted HTML div.

set_flash()

This function sets a flash variable with a value I specify. Since I use flash variables for a lot of different messages, which I may need to format differently, I also use this function to store some formatting data along with the message. That way when I display the message it is automatically displayed using the CSS style I intended.

The flash_helper file is based on the same concept that Michael Wales posted about a while back. I would link to the post but I can’t seem to find it anymore.

Last up: Code Templates

That wraps up the 3rd installment of this series. In the next, and final post, I’ll discuss creating code templates to help you maintain consistency between your files.

Related posts:

1. Building Applications using CodeIgniter (Part 2) – Configuration
2. Building Applications using CodeIgniter (Part 4) – Code Templates
3. Building Applications using CodeIgniter (Part 1) – File Structure