The only part needed?
(missed the part 1? Read it here)
Making a serie with a part 2 titled “the only part you need” is probably a little misleading. Fact is, just after having picked up Stripe as our provider and Peter Keen’s nice book, we jumped right into getting our whole payment system up, from credit card to invoicing. Time was short, but we needed that anyway.
This may be one of the reasons we missed a much faster way to get our first payments in, business speaking that I’ll outline in this post – hence the “only part you need”.
What you really need – single payment
Let’s back one minute to the business need. What you really need is a customer to be able to pay. Meaning, you need to be able to charge and invoice him.
Now, considering that you provide a SaaS, that should ideally be handled in your app: from the customer’s side, he just needs a form for his/her credit card. On your side, you don’t want to validate and store a credit card yourself (your application is most probably not PCI compliant), and those are very sensitive data. Stripe allows you to use the credit card without ever storing it yourself. This way, your system is actually PCI compliant – because the part that need to follow those rules is handled by Stripe, not by your application.
Getting the Credit Card information
You just have to create the form on your site, but the form is not going to submit the credit card information to your server.
Instead, it use a Stripe-provided JavaScript to submit it toward the Stripe server.
<form action="" method="POST">
<script
src="https://checkout.stripe.com/checkout.js" class="stripe-button"
data-key="pk_yourdatakey"
data-amount="2000"
data-name="PullReview"
data-description="1 month subscription (€20.00)"
data-image="/128x128.png">
</script>
</form>
Checkout make it very easy to have a quick working solution, but is not that customizable. If you want your form to fully integrate in your website, you can look at stripe.js that offers the same service with your form being totally under your control – with a little more work.
Should it succeed, Stripe will send back a token that your page can then send back to your server:
The token can then be used to charge the card without your application having to store or know the exact credit card information.
Note that in order to identify you, you need to send your Stripe key with all calls you do from either your page or server. As the one used on the browser is actually visible, it is a public key. For all server to Stripe communications, you actually use a (different) private key, that is never shown to any user-visible content.
Of course, you should still use HTTPS for those interactions, enabling it on your webserver and in Rails:
production.rb
# Force all access to the app over SSL, use Strict-Transport-Security, and use secure cookies. config.force_ssl = true
Charging
Charging can then be done with a single call to the Stripe API. While not complicated, we’ll see a bit below that even this part is optional.
Stripe provides a gem for this. Note the usage of the source here – we want to be sure we’re getting this gem from Stripe and no one else.
Gemfile
source 'https://code.stripe.com' source 'https://rubygems.org' gem 'stripe'
The API require you to set the (private) key before making any calls. This can be done just before calling, or in an initializer:
stripe_initializer.rb
Stripe.api_key = ENV['STRIPE_API_KEY']
Note that the API key is actually loaded using an environment variable. This has a double advantage: allowing easy switch between the production key and the test key depending on the environment (development and staging toward “test”, production toward “live”), and to avoid having the key visible in your code and version control.
That you can use like this:
begin
charge = Stripe::Charge.create(
:amount => 1000, # amount in cents, again
:currency => "usd",
:card => token,
:description => "payinguser@example.com"
)
rescue Stripe::CardError => e
# The card has been declined
end
You can actually test this on end to end, using Stripe-provided credit cards. Congratulation, you are able to sell any product or service and charge your customer for them.
What you really need – recurring payment
Now, if your good or service is not a “one time payment”, the “fire & forget” approach used above may not suit you. PullReview is sold as a subscription, so we need to be able to charge our customer each month, as long as they decide to stay with the service.
Now, remember this “one time token” we just talk about? It can actually be used exactly the same way for a very different purpose: creating a Customer in Stripe:
# Create a Customer customer = Stripe::Customer.create( :card => token, :description => "payinguser@example.com" )
Stripe’s Customer has an id field that you can store, along with some safe information about the credit card, like the card type, expiration date and four last digit (and actually any other you want, via a metadata field). It will not give you the full card info, which is again actually a good thing: it allows to store only the information you need.
It can also store the customer’s plan – something I’ll cover in a next post.
You can use the customer’s id in place of the one time token to charge:
begin
charge = Stripe::Charge.create(
:amount => 1000, # amount in cents, again
:currency => "usd",
:customer => customer.id,
:description => "payinguser@example.com"
)
rescue Stripe::CardError => e
# The card has been declined
end
But actually, this part is not even needed for now, as there is another way to charge a customer.
The stripe interface
Stripe is not only delivering a service but also an interface. On that, you can for instance look at your customer list:
But it can do much more than that: picking a customer actually allows you to charge him:
This means that once the card is in, you can do everything else manually – your system can receive payments.
Manual is ok – it is actually even good
“But I don’t want to do things manually”.
Me neither. This is one of the reasons we are programmers. But as the rest of the series will shows, there is still a lot to do before having all parts in place (logs, plans, error reactions, VAT, invoices…) – but all of those parts are provider facing, meaning you can manage them as you want.
If you’re starting or contemplating to integrate a billing system, it means you want to start charging customers, but except if you expect 1000 to signup in the first month, chances are good you’ll be able to follow up manually quite easily. If not – well, that’s a nice problem to have.
So get your calculator and text editor, compute that VAT if needed, charge using Stripe and write a nice invoice for your customer. There will be time enough to do the rest of the road – why wait when you can start charging for your service?
See you next week for part 3 – what’s happening here?
