Speedy Subscriptions Using Spreedly (Part 3) – The Sign-up Process

Picking up right where I left off, in this post I will review integrating Spreedly with your programs sign-up process. As is the case with most services like this, including PayPal, the quickest way to incorporate Spreedly involves redirecting the user to their website and allowing the financial transaction to take place on their servers. The user is then redirected back to your website once the transaction has been completed. This is the quickest and easiest method available and is the one I will be reviewing.

Quick Disclaimer

Spreedly has a full featured API which provides people with programming experience a greater amount of integration flexibility, you just need to be conscience of the security liabilities involved. Links to 3rd party libraries and documentation can be found on the Spreedly website. To save on time and get this series wrapped up I will not be reviewing the API.

Your Sign-up Process

Before we can get to the Spreedly side of things we first need to define how our sign-up process is going to work. It is in our best interests, as the business owners, to make our sing-up process as quick and simple as possible so that more people will purchase accounts. Smashing Magazine published a post or two on sign-up form design a while back and I recommend you refer to those poses for further information on designing your process.

The one thing I will say, as it pertains to process, is to keep your sign-up form short and sweet. We will be redirecting users to our Spreedly accounts for the actual financial transaction so don’t worry about collecting any of that data (address, CC info, etc.) on your form. Just collect the items that are vitally necessary to get the user setup and worry about the non-essentials after they log-in for the first time.

Prerequisites

As I mentioned above, we don’t need to worry about collecting any financial information on our website because all the financial transaction stuff will be handled by Spreedly. However, there is one bit of data that we need to keep track of in order to redirect our users over to Spreedly and that is the subscription plan ID. The way I have chosen to handle this is by creating a table in my applications database to hold a copy of my subscription plans and each plan will include their Spreedly ID. Come to find out I needed to create this table anyway to track the limits of each subscription plan and hold my users to the limits of the account they purchased. So in reality I simply added an additional column to this table to hold the Spreedly ID.

Now you can chose to handle this any way that works for you and your application, but the bottom line is you simply need to be able to keep track of the subscription plans you have setup in Spreedly and the unique ID that has been assigned to them.

Constructing the Subscribe Link

So now that we have our subscription process down and have defined a place to keep track of our subscription plans and their IDs on the application side we can start looking at how exactly we will be linking to Spreedly.

Spreedly makes it somewhat difficult to find your subscription plan ID so you have to go looking for it. When you are logged into your account, click Plans to view your subscription plans and click the name to edit it. The edit screen, which is shown above, allows you to make changes to your subscription plan. If you look at the URL of this page you will be able to find the ID of your subscription plan. It’s the number displayed between “subscription_plans” and “edit”. That’s the number you will need to keep track of on your application side. You should also take  a look at their documentation links in the box on the right side of the page which also reviews linking to subscription plans from your application.

OK, so now that we have our subscription plan IDs we need to determine what the URL is going to look like.

https://spreedly.com/signupsheet/subscribers/84736/subscribe/1019/screen-name-for-84736

The URL displayed above is a sample URL for the basic subscription plan.  Let’s take a look at this URL piece by piece to figure out what we need to modify:

So that’s it. All URLs will be the same except for the 4 pieces identified above (in red): your short site name, an account/user ID from your system, the subscription plan ID and a user/account screen name. By customizing those segments you should now be able to successfully redirect your users to Spreedly for credit card processing.

Passing Additional Data

It’s also worth mentioning that you can pass additional data to your Spreedly subscription pages like the subscribers name and e-mail address. If you are already collecting this data on your applications sign-up form it would be helpful if these fields were already filled in on the subscription page. You can easily pass this data along to Spreedly by adding some GET variables onto the URL we constructed above:

If we use the above GET variables to pass additional information to our subscription forms, then our final Spreedly URL is going to look something like this:

https://spreedly.com/signupsheet/subscribers/84736/subscribe/1019/screen-name-for-84736?email=someone@someplace.com&first_name=someone&last_name=special

That’s all there is to it. Once the user inputs their credit card information they will be redirected to the URL which you specified in the subscription plan settings. You can also modify this on the fly by providing an additional GET variable to your URL: return_url. Using that variable you can dynamically redirect the user wherever you specify upon successfully completing the payment process. This comes in handy if you need to pass any kind of dynamic information along with your user when they are redirected back to your site.

What’s Next?

If you followed along you should now be up and running with using Spreedly to manage your applications payment processing. You may however notice one thing is missing… we have no way of knowing whether the payment was processed successfully or not. The user simply gets redirected where we say and that’s it. We also have no way of knowing when their subscription expires (unless we track that ourselves). In the next post I will look at how we open up the lines of communication between Spreedly and our applications so that we know more about whose paying and whose not.

Related posts:

  1. Speedy Subscriptions Using Spreedly (Part 2) – Account Configuration
  2. Speedy Subscriptions Using Spreedly (Part 4) – Checking for Updates
  3. Speedy Subscriptions Using Spreedly (Part 1) – Overview & Account Setup

Programming

If you enjoyed this post, please consider to leave a comment or subscribe to the feed and get future articles delivered to your feed reader.

Comments 

2 Responses to “Speedy Subscriptions Using Spreedly (Part 3) – The Sign-up Process”

Leave Comment

(required)

(required)