We tried to use Stripe coupons as makeshift gift certificates, but the logic quickly fell apart, particularly when thinking about how a gift customer would become a paid customer.

Instead, we track gift subscriptions in Cook Smarts’ database, and use Stripe’s trial period feature to redeem them.

The end results:

I buy my friend a gift subscription.

She redeems the gift subscription, with no credit card required, and has access to Cook Smarts for the length of the gift.

If she wants to continue using Cook Smarts past the gift period, she can provide billing information at any time during the gift period, and she will become a paying customer at the end of the gift period.

Here’s how we did it.

When I buy my friend a gift subscription, the app creates a record in a gift subscriptions table. It includes a randomly-generated gift code and the length of the gift subscription.

When my friend redeems the gift subscription, the app marks it redeemed in the gift subscriptions table. It activates her subscription in Stripe, and includes a trial_end date, which tells Stripe the length of the gift period. Stripe does not require billing information for a free trial (or what we call the gift period).

customer = Stripe::Customer.create(
:email => self.email,
:plan => 'monthly',
:trial_end => gift_subscription.end_date #end_date is a method in the GiftSubscription model that returns the end date of the gift period, based upon the length of the gift subscription and the date it was redeemed
)

If my friend loves Cook Smarts and wants to continue as a paid member, she can provide billing information at any time during her gift period. The app will pass the credit card, and her subscription choice, to Stripe, along with the same trial_end date. This way, she will continue on a gift subscription, and become a paying member at the end of it.

This will ensure that the trial will end on the date you pass in, otherwise the API will shift the trial end date based on the new plan you’re moving them to.

Basically, when the customer provides billing information and chooses a plan, we need to pass the original trial_end date as we do above, so that the customer is not charged until the end of the gift period.

All in all, it was fairly straight-forward to implement gift subscriptions with Stripe. The biggest hurdle was allowing customers to provide billing information at any time, while holding any charges until the end of the gift period.

If your web app uses Stripe for online payments, you should test Stripe thoroughly. For growing apps, you need both manual and automated tests. I first learned about automated tests in an awesome EdX course about Ruby on Rails, and the concept was mind-blowing for me. Your app can tell you when the code you are adding to it is having unanticipated consequences, so you can feel secure that you are not breaking your app by adding new features.

Anyway, Stripe is a developer-focused payment processing service. It’s become a popular way to process online payments, particularly for subscription-based sites.

I’ve recently had the pleasure to work on Cook Smarts, a site that I originally featured in this blog and now have actually started helping with directly.

Cook Smarts uses Stripe to process payments. Cook Smarts’ meal plan service is subscription-based, and it is essential that Stripe function as expected, so we knew we’d have to test it well.

Here are some strategies that helped. This is written from a Ruby on Rails perspective, but the concepts would apply to any language.

Separate your API keys

Stripe provides two API keys for your site – a production key that can charge people real money, and a test key that cannot. When you are developing your app, you need to be careful not to accidentally use your production key, or you could do some real damage to your customers’ accounts.

In Rails, wherever an API key is used, I put in place logic to choose the production or test key based on the current environment, like so:

Update 2/17/2015: It’s advisable to keep API keys out of your code. Use environment variables instead. dotenv is a great way to specify environment variables on development.

Test manually

Once your API keys are separated, you can jump into your app on your development environment, and start playing with Stripe. Stripe offers test credit card numbers that you can plug into your dev environment to simulate successful transactions. You can play the role of a customer that is actually buying something, and then look at what happens on your Stripe test dashboard as a result.

Test operations and webhooks with RSpec

With RSpec, a popular testing tool that plays well with Rails, and another gem called stripe-ruby-mock, you can create a fake Stripe that your app interacts with in your tests. This way, your tests do not have to call out to Stripe at all, and run much faster.

You could then perform operations on the fake Stripe customer in your test, and it would never have to call out to the real Stripe site.

We handle various webhooks from Stripe, which is just a way for Stripe to tell Cook Smarts that something happened with a customer’s account. It is important to test these. One change I’ve made is placing more of the webhook response logic in the app’s models, where they are easier to test. I have not yet figured out how to simulate a webhook with RSpec in the development environment, but thoroughly testing the steps after the webhook is initiated gets us close to full coverage. After that, keep an eye on your production Stripe event log (which shows which webhooks your app received and when), and confirm that your app is doing what it should in response to webhooks.

RSS isn’t going away, I hope. It places established and brand-new publishers on an equal playing field. If someone subscribes to me and Mashable, for instance, we both appear on their reading list. As bloggers, we should think about how to support RSS and gain more subscribers in the process.

It’s not easy. Current RSS clients – with one notable exception – are not giving publishers the tools they need.

For instance, I’d like you to subscribe to this blog’s RSS feed. How can I help you do that?

If I link to this RSS file, here’s what you see:

This site’s RSS feed viewed in Google Chrome

If I send you to Feedburner, you can choose to subscribe via Google Reader (a sign that Feedburner is not being updated), some broken image, or My Yahoo. The Feedburner subscription landing page, in most cases, adds no value for the user.

FeedBurner’s subscription landing page

(Hang in there – there’s an answer at the end of this post, promise.)

Three of the top web-based readers are Feedly, Digg Reader, and AOL Reader. (Feedly is likely the top.)

From what I can see, there is no way to provide you with a Subscribe via Digg Reader or Subscribe via AOL Reader link. How is either reader supposed to create an ecosystem without providing tools for publishers?

Whether or not you have a Feedly account, the link provides you with a description of the feed and the latest articles. If you click Add to My Feedly, Feedly asks you to login or register, and then helps you subscribe to this blog. This integrated experience serves publishers and consumers alike.

I’m creating a new WordPress theme for this site that will include a Subscribe via RSS button. It will feature two options – Subscribe via Feedly or Other. I hope to add Feedly’s competitors, once they provide the most basic of features for web publishers, a Subscribe button.

End Note:

Feedly’s integrated experience reminds me of It’s the Little Things from 52 Weeks of UX. Feedly seems to recognize that every interaction matters. You see it in other areas, too. Feedly is the only service of the three to show the number of readers for a feed, a helpful stat for publishers.

In fairness, I should note that AOL Reader has an API, but it is geared toward third-party app developers.