Ken Ingle

Ken Ingle

Chief Information Officer, Technology & Strategic Leader

Stripe Connect with Rauth and Django

I have been working on an application that needs to collect payments for multiple merchants.  After looking into various ways to accomplish this, I landed on Stripe and more specifically their Stripe Connect service.  Stripe Connect allows you to have access to your customer’s Stripe account in order to collect payment on their behalf.  You can then add convenience charges, and ensure that money does not transfer between multiple accounts but instead goes directly to the customer’s bank account.  All while still maintaing the flat transaction rate (2.9% per transaction as of this writing) with no monthly fee or merchant account requirement.

In order to use Stripe Connect a merchant must go through a Oauth 2.0 flow to authorize your service to access their  account.  On the Stripe website they show how to perform this basic authorization with urllib and requests.  This method works, but is a bit inefficient.  You will end up repeating things anytime you need to make an API call to Stripe or want to perform other actions.

Rauth (built on the awesome requests library) is a simple Oauth1, Oauth2 and Ofly consumer library.  It simplifies a number of the actions required to handle Oauth.  Getting rauth setup with Django and Stripe Connect is pretty easy.

Install Rauth

Initialize the Oauth2 Service

You will want to initialize an Oauth2 service for connecting to stripe.  You will want to set this up so that it is outside of a specific view but available to multiple views in your file.

There are other arguments you can pass to the service, these arguments provide the minimum required to make the connection and authorize via Stripe Connect.

Note: You should pull these values out into your settings file so that you are not hard coding client ids and secrets that may have to change at some point into your app.

Ask the User to Authorize you to use their Stripe account

Once you have configured the stripe service, you will need to generate a request to stripe to authorize your application.  This is a OAuth workflow that will be familiar if you have ever used Twitter of Facebook to authorize/login to another service.  To generate this request we will create a view that when called build’s a url with our client information requesting a authorization code.  The Rauth OAuth2Service will handle creating the authorization url and including your client_id and client_secret.

This will return a temporary code that is used to request a permanent access_token for connecting to stripe on a user’s behalf.  The return URL is specified in your Stripe Application settings:


Request the Access_Token

Once the user has authorized your application you will receive a temporary code that is used to request the access_token.  This will be returned to the callback URL specified in your Stripe application settings.  You will then need to make a raw_token post request for the access_token (due to the nature of how Stripe Connect returns the access_token payload, we will need to use the Rauth get_raw_access_token() function):

You now have authorization to make transactions on your clients behalf with Stripe.  In the above example you would NOT return to the page the access_token but instead want to save it to the database so that you can utilize the code to make payments in the future.

There are other ways to accomplish this same thing using urllib and requests directly, but Rauth definitely makes it a lot easier.  Having the Rauth service is also quite useful for additional api calls in other views and services and if you intend to use any other OAuth service in your application.

I make no claims that I have done this the perfect way, but it works.  Feel free to recommend improvements and leave feedback.


Passing URL Parameters to a Decorator in Django

I have been working on a small project where I needed to pass a URL parameter to a decorator I was writing. In an ongoing effort to follow the principal of DRY, I have found that decorators (when used at the right time) can really help. I was able to find no shortage of examples where decorators made life easier in django applications (e.g. login_required).

After a bit of searching and asking around I came across a really great blog post by Charles Leifer describing in details how to accomplish almost exactly what I needed.

For the purposes of this example, let’s assume I have a Company model where I have defined a company_admin foreign key that relates to a user object as the admin for the company (in practice I would recommend using the groups and permissions already built into django, but this is just an example).

Let’s say I have a URL pattern that looks something like this:

Initially my view (and probably many views) might have been checking to see if this logged-in user was an admin kind of like this:

I want to create a decorator that will wrap the view, take the slug and handle the verification that this user should have access to this company. I will then want to return to the view the actual company object instead of the slug.

This will give me the capability to re-use the authentication as well as have my company object (which is useful) instead of simply the slug:

Finally, my view will change to use the decorator and remove the duplicate logic:

This creates a re-usable decorator that utilizes URL parameters. I hope this helps more people than just me. Feel free to comment if there is a better way to do this or if I should change something.