Recap of the January Pinax Hangout
The purpose of the Pinax Hangouts is to engage more with the Pinax community. We want to let you know what we are working on, answer your questions, and present demos of old and new apps and starter projects. Our host this month was Patrick Altman who was supported by our co-hosts James Tauber and Brian Rosner.
Patrick talked about pinax-stripe.
Pinax Updates
What’s Going On?
We recently hit over 160 members on our Pinax project Slack team, which is awesome! If you want to find out more about Pinax or chat with us, please join our Pinax Slack team! We’ve also gotten a lot of great contributions to Pinax on GitHub, which we’re really excited about and thankful for. Please keep them coming! In December we launched our Pinax Developer Profiles interview series highlighting awesome people who contribute to Pinax. If you’re interested in submitting an interview, please get in touch. In general our blog is a great way to keep up-to-date with news regarding the Pinax project. A bunch of us will be at PyTennessee in Nashville next weekend. If you’re there, be sure to look out for us, we’d love to chat with you.
Pinax 16.04
Something new and exciting we are working on at the moment is a new Pinax distribution idea. Pinax faces a couple of challenges. Unlike Python and Django, which are very monolithic, Pinax is a collection of different individual open source projects. This sometimes makes coordinating releases and dependencies difficult. It is also difficult to provide clean upgrade paths, documentation, etc. This problem is similar to what operating system distributions in the Linux world like Ubuntu face, so we decided to try something similar to the way Ubuntu does releases, which is the idea of a time-based distribution. Sometime in April this year we’re going to announce Pinax 16.04. This will be a snapshot of starter projects and apps which are all known to work well together, decent tests, and good documentation for all of them. Our goal is to set a baseline for subsequent releases. We’ll make sure there will be an upgrade path, etc.
As part of process between now and the end of February we are going to try and get a bunch of different Pinax apps in shape. If an app isn’t in shape in time, it won’t make the cut. In March we’ll make sure that all of these apps are included in a starter project in one way or another. If certain starter projects don’t get done by the end of March, they won’t make the cut either. If you’re interested in getting involved in that process, the best way to do so is to join our Slack team or take a look at issue #84 in the pinax/pinax repository on GitHub.
Pinax-Stripe
Overview
pinax-stripe, originally called django-stripe-payments, is one of our very popular apps. Over time issues had built up, etc. and there was a recent need to get some projects integrated with Stripe so we finally rebooted it as pinax-stripe.
What was challenging about django-stripe-payments is that the API with Stripe is so deep and rich that we were wrapping a lot of methods to call the API on the model itself. This was growing out of hand. We’ve now taken a step back so the biggest difference between django-stripe-payments and pinax-stripe has been rearchitecting it to have a service layer and to decouple the Python API for interacting with Python and Stripe from the models. Unlike a lot of Django apps, you’re going to interact with pinax-stripe on a Python level more so than some of our other apps that are more plug and play.
Abstracting pinax-stripe to a service layer will also help foster contributions without people stepping on each other as there are areas of Stripe which some people care a lot about but others have no interest in using at all.
Demo
One of our biggest goals was to offer better documentation for pinax-stripe, to make the documentation fully comprehensive, and to provide a full reference guide. The reference docs still need some work but the “Getting Started” section is pretty complete. pinax-stripe will also be part of the Pinax 16.4 release.
When looking at the pinax-stripe code on GitHub you will see that the service layer is a series of models under actions providing functional interfaces. You don’t interact with Stripe directly, instead you interact with Stripe through these methods.
We also integrated 100% docstrings coverage and the entire package has 100% test coverage, which was a big upgrade from django-stripe-payments. Most of the modeling stays pretty much the same, which means the migration from django-stripe-payments to pinax-stripe should not be disruptive.
One critical thing to know is that all the data except for the linking of customers to users is just a cache from Stripe so it should be easy to drop tables and resync data.
One of the best improvements we made was creating a starter project for pinax-stripe, which shows how easy it is to have a site set up with Stripe ready to accept payments.
Setting Up the Pinax-Stripe Starter Project
In order to set up the starter project, first create a virtual environment
pyenv virtualenv stripedemo
Activate the virtual environment:
pyenv activate stripedemo
Install the Pinax Command Line Client, which allows us to quickly start a starter project
pip install pinax-cli
If you type in pinax projects into your terminal it shows you a list of projects which are available to start. We want to start this one off of Stripe. The pinax-stripe starter project is a branch off pinax-project-account, which means you get all the django-user-accounts functionality that comes with pinax-project-account but it adds in the Stripe configuration. In order to start our pinax-stripe starter project we type in the following into our terminal
pinax start stripe stripedemo
Now our project is ready to go and we can cd into our project folder
cd stripedemo
And install the requirements
pip install -r requirements.txt
Next we load the database
python manage.py migrate
And load the fixture that comes with the project
python manage.py loaddata sites
Stripe Keys
Let’s set our keys for our Stripe account next. In order to do so go to the Stripe website, create an account, sign in to your account, go to your account settings, and open the “API Keys” tab. Grab the Test Secret Key and the Test Publishable Key. Then open up your text editor and insert them on lines 143 and 144 in your settings.py file:
PINAX_STRIPE_SECRET_KEY= “your test public key” PINAX_STRIPE_PUBLIC_KEY`= “your test secret key”
Please note that there is a set of keys for test and a set of keys for live purposes. Ideally when setting this up instead of just copying and pasting the keys, what you would want to do is something like this
PINAX_STRIPE_PUBLIC_KEY = os.environ.get("STRIPE_PUBLIC_KEY", "your test public key")
PINAX_STRIPE_SECRET_KEY = os.environ.get("STRIPE_SECRET_KEY", "your test secret key")
If you plug these values from the environment you don’t have to put the live keys in your repository. By passing this in as a second argument your local test keys will just work. For our purposes we’ll just use the test keys.
Testing Webhooks Locally
Stripe works by setting webhooks to keep data in sync. For example, if you have a subscription set up they handle all the recurring billing for you but it’s important to know if a customer charge succeeded or failed so you can act, send emails to remind them, or turn off functionality. Instead of polling Stripe they send webhooks to a URL that you can configure. ngrok will give you a public URL that you can set up so it proxies it to your localhost, which is very useful for debugging things locally. If you’re on a Mac you can just brew install ngrok.
Get our local development server running
python manage.py runserver
Open up a new tab and run ngrok to that port 8000
ngrok http 8000
You can now see the publicly exposed URL to your local runserver. Copy and paste it
and add this endpoint to the Webhooks tab in your settings in Stripe. Then click “test mode”, add /payments/webhook/ to the end of the URL like this
http://<random code>.ngrok.io/payments/webhook/
then click “create endpoint”. Now any activity on the test mode for Stripe, which means anything using those test keys, is going to send any event webhooks back to this ngrok URL, which will proxy it to our localhost, which is going to hit our runserver.
If you open the receivers.py file you will see in line 61 that we create a customer in Stripe with the user that signed up. This means we call the customer service layer on a user sign up. This is going to end up sending a webhook back with other details about this particular customer.
Walkthrough
Now go to the local instance of the pinax-stripe starter project in your browser and sign up. In your terminal you can now see that the webhook got pushed back from Stripe.
In your account settings the starter project already gives you a list of your subscriptions, you can add subscriptions, etc. We haven’t set up plans in Stripe but you can do so.
There is a management command which will let you sync those plans down and once you have them in your database you can add a subscription. You can also add payment methods. You can delete credit cards or change credit card data. The payment history will show you any payments that will come in. If you have a recurring subscription they will show up as invoices. This however isn’t only true for subscriptions. You could remove this whole part and not have any plans by just removing lines 23-25 from your account/base.html file. If you wanted to disable the URLs, you would have to go and edit your urls.py file. You could set your website up for e-commerce, for one time payments to access the site, etc.
Please note that you can see any kind of activity that’s happening, any events changing data on the Stripe site, in your terminal. You may not care about about all of these activities but they are there to hook.
The pinax-stripe starter project should give you a good starting structure and provide a good way of seeing how things are integrated in a project. If you’re starting a project we would recommend for you to use the pinax-stripe starter project as it makes things really easy. If you have an existing project already, you can use this as a reference for how to integrate it in addition to the documentation.
Having this service layer should make it easier for people to at least add the Python API layer among other things they care about. Adding the front-end bits could be done in a second pass. You may prefer to interact with the Python layer more so than having a lot of front-end. For our pinax-stripe starter project we haven’t done a huge amount of custom front-end, just enough for the basics. The front-end however is all class-based views, which you can easily extend. The templates are shipping as part of pinax-theme-bootstrap.
What’s Next?
Going forward there’s a number of features we’d like to see added to pinax-stripe like ACH payments or the ability to take payments in Bitcoin.
If you’re interested in contributing in any way, please join our Slack team, ask questions, and take a look at our GitHub issues.
If you missed our November Pinax Hangout you can watch the video here
Our next Pinax Hangout will take place on Thursday, February 18th at noon Eastern time. The topic will be announced soon. We hope that you will join us for our February Hangout!