 All right, it's five-ish or close enough. So we'll go ahead and get started. If you are here to learn about recurring billing, subscription billing, taking someone's credit card and charging it over and over and over and over again, then you're in the right room. If you're not, you can leave and go find what you're looking for and I won't be offended. So introduce myself a little bit about me. My name's Joe Schindler. I'm EOJ The Brave on Drupal.org, Twitter, pretty much anything on the internet. I work at Lullabot. Lullabot is a company that does Drupal consulting, training, and development. I'm the lead trainer at Lullabot, so I do a lot of standing up and talking to people about how to build your first view or how to create sites using Drupal. In addition to doing that, I also work on the Drupalize.me team. I do a lot of Drupalize.me's video recording. In addition to that, I also do a lot of development on the site. And this is actually where a lot of my information that I'm gonna be sharing with you comes from, from having spent a lot of time working on the subscription platform that we use for hosting our videos, allowing people to sign up for a monthly subscription and watch those videos. I think it started, I think it makes sense to just talk a little bit about what exactly is recurring billing. Basically, at its simplest form, recurring billing is when you give someone the permission to charge your account at a regular interval. Whether that's giving them your credit card number and saying, go ahead and charge my account once every month, giving them a bank account and saying, yes, you can debit my bank account for my mortgage payment on a monthly basis, anything like that where you're basically saying, go ahead and take money from me on a recurring interval. Recurring billing or subscription billing is how we often see it. Some examples of that might be something like a newspaper or a magazine subscription. You sign up for a magazine, you pay them 10.99 a month and they send you a magazine in the mail. If you stop paying them 10.99 a month, they stop sending you the magazine in the mail. Other common examples that we're probably used to, something like an ISP, an internet service provider. So not necessarily a physical good but a service that you're giving someone. Your Comcast charges you X dollars per month in order to provide you a service. If you fail to pay them and they're using some kind of subscription-based billing system to charge you or they may just send you a check or a bill in the mail but they're still billing you on a monthly basis, you fail to pay that bill, maybe not right away but eventually they're gonna shut down your account and no longer provide you with that service. Netflix is another common example. There's also the software as a service model which is becoming pretty popular and probably something a lot of people here are interested in. You're building some kind of web-based application and you wanna charge people for access to that application. Again, you're providing them a service, things like Basecamp, Pantheon, Unfuddle, Yammer, all these tools where we sign up for an account based on how much we pay them, we may get different features or it may just be like a, you sign up, you get an account, pay one rate and you get all the features. Whatever the case, you have to pay for that on a regular ongoing basis and if you fail to pay, they'll eventually shut down your account and you don't get those features any longer. And then there's things like paying rent is a form of recurring billing. In a sense, you have an apartment, you have to pay the landlord on a monthly basis. They might not have a whole subscription-based platform in order to charge you, they'll probably just show up at your door and knock on it if you forget to pay them. But at the same time, it's still some kind of recurring billing. I also realized that this session takes place at 5 p.m. on the second day of DrupalCon. So it's going to be the end of the day and everybody's had their brains kind of filled with a lot of stuff. You're probably waiting to head out to the bar and have a beer. So if you take anything away from this session, this is going to be the five minute version of how you can do recurring billing. So the five minute version of my session is, if you can, use a service. Use somebody else to do the recurring billing for you. Focus on building your application or your platform and let somebody else do the hard work as much as possible. This is going to vary a lot. You might end up with a scenario where you can offload some of that work to someone else and do some of it yourself. A good example is if you were in the previous session, they talked a lot about PCI compliance. You might want to offload some of the credit card data storage to a business that specializes in doing that so you don't have to spend a lot of time working that out yourself. If you do have to build your own system or even when you're using an existing service, try and simplify your needs as much as possible. I think we tend to look at these things and go into it with this. I need all these features. I need to be able to do all these crazy things and we end up kind of complicating the problem. A really good example of this that happened with the Drupalize Me site is when we first started building it, we spent a lot of time figuring out how to handle trial accounts. Somebody signs up for a trial account, we want to give them like a one month free and then after that we'll start charging them X dollars a month. But it was always weird because in order to get their credit card, we would have to charge their credit card something or it was weird to say give us your credit card but we're not actually going to charge you anything sort of from like a customer relations standpoint, that was kind of bizarre. Things like that, we were able to sort of just simplify the idea a little bit and then we stepped back and said, what are we really trying to do? What we're trying to do is give somebody the opportunity to experience what our site would be like if they had an account on it without having to commit to paying the $45 a month. So we just made some of the videos on our site free and it's the exact same experience that you get if you sign up for an account. You just don't get it on all the videos, you get it on a handful of them and that was awesome because it's really easy to do that in Drupal. You just check a couple of boxes and change some permissions and you're done. You can give away an account to somebody and they can get a trial of what your site is like. So things like that, figuring out ways to simplify your needs. I highly recommend that you test the crap out of everything you do with recurring billing and billing in general. For a couple of reasons, when you're doing recurring billing, you're charging people money for some service. If you mess up charging people money, they tend to get pretty upset about it. The other part of it is, if you fail to charge them money on a recurring basis, your business model isn't doing very well because you're not making money. So testing things becomes really important. We'll talk about some tips for that. Finally, focus on communication and building relationships with your customers. When you're doing any kind of sales, but especially with the recurring billing type of stuff, focusing on building good relationships with your customers becomes really important. We find at Drupalize Me, when complicated things happen or when something messes up, it's a lot easier for us to talk to our customers when we've already established a good relationship with them. They don't come at us and are really mad that something was broken. They come and say, oh, hey, I noticed on your site that this was a little bit out of whack and could you please fix it? And we say, sure, yeah, no problem and we'll give you a free month and be friendly about it. It becomes much easier to maintain your customers. So that's the five minute version and then there's the longer version because the truth is, if you are doing this kind of stuff, you're gonna spend a whole heck of a lot more time than five minutes working on sorting it all out. It's actually a fairly complicated problem, not only within Drupal itself, but just sort of in general, doing recurring billing has a lot of moving pieces to it. So like I said before, this is all based on my experience working with recurring billing for DrupalizeMe. DrupalizeMe is a Drupal 6 site so a lot of my knowledge is based on UberCart and that system, I've also done some looking into the commerce subscriptions for Drupal 7 though I haven't used any in a production environment yet. And I've also spent a lot of time talking to people from various services like Recurly and Chargeify and just kind of picking their brains about this. At the end of the day though, I don't know that I have all of the answers to how to do recurring billing. You're not gonna be able to walk out of this room and download these five modules and turn them on and magically start doing recurring billing, but we can hopefully help get you pointed in the right direction. So one of the first questions that you need to ask yourself when you get into this and in that five minute overview, my first step was if you don't have to, let somebody else do it for you. So you need to be able to figure out should I roll my own recurring billing service system or should I use a service? In this context, by roll my own or building our own system, I'm saying that if you're building the system in Drupal using something like commerce or Uber cart, you're in a sense building your own. If Drupal becomes the business logic that is responsible for charging once a month or make it whatever it needs to do, it needs to contact the gateway or charge the credit card or whatever it needs to do on a monthly basis to charge that card, we're gonna refer to that as we're building our own system. So if Drupal's performing the majority of the business logic, we're building our own system. If we can offload that to something else, then we're using a service. There's various parts of it that we can offload to other things. And there's a lot of different types of services. So by a service, I mean something like Chargeify is a common one, Recurly, there are a lot of billing subscription management platforms that exist that basically have an API that you can use in order to charge somebody's credit card on a regular basis. In a very simple level, how they work is somebody fills out a form, whether that's on your site or on their site and adds their credit card data into it, hit submit. Once that service, like Recurly, has successfully charged a credit card, it then pings your server. So it calls back to Drupal and says, hey, there was a successful charge made, or hey, this charge failed, and then Drupal can do something, like add a role to a user if the charge was successful or remove the role if the charge failed. There's other types of services too that are sort of at a little bit different level. So in addition to doing that, something like Recurly provides you with a lot of reporting, it gives you Dunning management, which we'll talk a lot about, how to handle errors, what happens if I try to charge somebody's credit card, but they actually got a new credit card or they changed the dresses or something like that. Services like Recurly provide a lot of tools for handling that for you as well. There's other things like PayPal or Stripe or Authorize.net has their ARB, Automated Recurring Billing System, which do part of this. They do the part where they essentially act as a credit card data store and a cron tab. So they store your credit card data for your users and then on a regular schedule, whatever you've defined as a plan, they'll charge that card so that maybe we'll say that's once a month, they'll charge the card, they'll call back to your server and say whether it was successful or not. In these cases, that service like PayPal or Authorize.net is still the one that's responsible for that business logic of actually knowing when to charge the card and doing so. And then finally, there's gateways in sort of the build your own using something like Authorize.net or Braintree, but not using their ARB system, but just using them as a card store and you perform the logic to charge the card. We'll talk more about that. Of course, there's the question, what is this going to cost me in order to build this kind of system? And this plays a really important part, I think, in trying to determine if you're gonna use a service like Recurly, you're gonna pay them a fee in order to use that service. If you're gonna build it yourself, you're gonna pay yourself or your developer's a fee in order to build all the business logic behind it. And it's an important question to ask. I have some slides where we kind of break it down a little bit more and we'll talk about that. You also have to ask how much time is this going to take? Am I gonna spend a lot of time integrating with some third party service versus am I going to spend a lot of time building it myself? Time and money, those two often go together. Sometimes you have not very much money, but you've got a ton of time. If you're building it yourself, you can spend maybe as much time as you want to, or maybe you have a lot of money and very little time and it's kind of managing that scale. And then finally, there's the question of, if I'm gonna use this service, does it provide me with the flexibility that I need in order to perform whatever plans I've come up with? Plans, in this case, being something like, I'd like to charge people once a month, or a plan might be I'd like to charge people every six months, or I'd like to charge people once a month, but I'd like them to have half off on the first month and so forth. So figuring out your plans doesn't provide the flexibility that you need. So services, we talked a little bit about this. There's a whole bunch of them out there that perform this service of basically acting as both the credit card data store and the business logic that does things like bill at a regular interval every 30 days or whatever the case may be. In addition to that, these also provide a lot of reports that you can go and look at. They provide interfaces for managing things like dunning, so dunning management being when their credit card fails, how do I send them, do I send them an email, do I contact them about it or not? So lots of services that provide that. I like the idea of these services and I think that if it seems to be a good fit for you, I would highly recommend going with one of these services. Let them do the work of things like automating the billing and dealing with all of the security and so forth because then you get the opportunity to just focus on your application, focus on the thing that you're good at. You know, it duplifies me. The thing that we're really good at is recording videos that train people on how to do things. And we'd rather spend our time working on recording new videos than spend all of our time in the background working on writing some kind of logic in order to perform this dunning management when we could just pay somebody else a fee to do it. So, build your business and not your billing system. We also talked about other types of services like PayPal or Stripe, which are kind of a hybrid between a payment gateway and a full-on recurring billing service. Again, PayPal is a really good example of this. They can do both taking your credit card and charging it and you can set up a plan with them where you say charge this card every 30 days, ping me and let me know that it was successful. Both of these types of services, whether it's a PayPal service or something like Recurly, on the Drupal integration side of it, basically what you need to do is you have to have a URL that these services can ping and they'll ping with a status code that basically says this was a successful transaction or was a non-successful transaction depending on the service they have different status codes and you need to respond to what their status code is and take the appropriate action on your side. So that becomes really all your application has to do. It's generally something like remove a role from somebody because if they don't have the role, they no longer have permission to see the things that they're paying for and so forth. And then there's the sort of standard payment gateway side of things. Let's get a question. I guess this is not too bad a time to mention this. This one's a little unusual as an alternative kind of a service. It's only really relevant if you could also use like email management and CRM features. But we have this thing that's called InfusionSoft and it is email marketing, CRM and e-commerce. And we actually also use UberCart and we use DrupalSite because the basic shopping cart that's in InfusionSoft isn't as flexible in general as I would like, doesn't have multiple currencies, doesn't handle lots of things. But it does actually have a really good recurring billing feature and it covers all kinds of things including the done process and there's a way to get a portal that people can come in and fix their credit cards or update their credit cards, all those things, not too expensive. I think one seat is like $59 a month or something. PCI compliant, so it takes care of a lot of things but mostly you would use it if you also are interested in their email facilities and CRM and there is some basic integration for Drupal. There's one module out there called InfusionSoftAPI I think. There's another module that I wrote that is only in a sandbox called InfusionLink. Okay, so it's called Infusion. Yeah, so basically there's a lot of different services InfusionSoft being another one that I personally have not heard of. But I would say any of these services that you're checking out, you're still gonna need to ask yourself those same questions. Is it worth the cost of me paying for this service or even if it's a separate piece of software that I'm down licensing and installing on my own hardware, there's that cost tradeoff to pay that licensing fee versus writing the code myself and now I own it. So I wanted to mention this gateway thing, this concept of a gateway being something like Authorize.net. You have a merchant account. Authorize.net is responsible for, you hand them a credit card number, they charge that credit card number, they deposit some money into your bank account. It's sort of a very high level. A lot of these also offer some type of recurring billing service, similar to what PayPal does where it has, you can set a plan and then it'll automatically charge the card every 30 days and ping you and let it, you know if it worked or not. In addition to that, a lot of these gateways provide some sort of credit card storage or a vault. Braintree calls, there's the vault. Authorize.net has their CIM customer information manager. There are packages that you can add on to your account with Authorize.net that says I'd like you to store credit cards for me. So this is really important, both if you're using a service like Recurly or if you're building your own. You're gonna need to have a gateway that can do the charging of the credit card and something that's storing that credit card data for you. Some of these services like Cheddar Getters, one that provides their own gateway as well. But at the end of the day, they're providing two things that they're providing the recurring subscription management software and they're providing the gateway. So at a bare minimum, no matter what route you take, you're gonna need some kind of gateway. And I would highly recommend that you use your gateway as your credit card data store rather than trying to store it yourself because you're gonna run into all kinds of complications with PCI compliance in order to do that. There's no reason not to use a third-party service to do that part of it for you. So what is this all gonna cost? I did spend some time kind of looking into it and researching and looking at the numbers of what it would cost to use different services. At a base, if you're gonna use Authorize.net at your gateway, it's gonna look something like this. There's gonna be a $99 one-time setup fee. You're gonna pay them $20 a month in order to keep your account and then you're gonna pay approximately 10 cents per transaction. So doing the math of saying I have 100 subscribers that are each paying $10 a month, it's gonna work out to be about $30. Or sorry, you also have to pay monthly for the CIM or Customer Information Manager. So you're gonna pay $20 a month just to have your account and $20 a month to use their credit card vault. Then you're gonna pay 10 cents per transaction. Basically, with 100 users at $10 a month, you're gonna be paying about 5% of your total profit to use Authorize.net's gateway as charging credit cards and storing credit cards. So at a bare minimum, you're looking at something like that. The cost to use a service like PayPal is a little bit steeper, but you're also getting more out of it. They're doing the automatic billing part of it for you. They're doing the business logic of saying, I'll take that plan that you set up, charge every 30 days and ping you. Looks something like this. Works out to be roughly $130 per month for 100 users at $10 a month in order to use PayPal as your subscription billing thing. In this case, you're still gonna be responsible on your end for implementing a lot of logic to deal with Dunning Management and so forth. They don't really provide that. They also don't provide that much in the way of reports that you can look at. Not the same way that a service like Recurly or Chargeify might provide. I also found this interesting website, Billingsavvy.com, which you can go to and basically, it uses some of the more well-known and popular subscription billing services. You plug in how much you're gonna charge a month or how much you're gonna charge at what interval, the number of subscribers that you have and it gives you this chart that says this is what the cost is gonna be. I will point out on this site that Stripe is a little bit misleading because while it's on this site and it's become really kind of like a popular hot topic Stripe is pretty cool right now. It doesn't provide you nearly the level of services that something like Recurly or Chargeify does. Stripe is much more equivalent to using something like PayPal in terms of the services that you'll get for doing subscription-based billing. So it can be a little bit misleading. I kept adjusting the numbers and then putting them in an Excel spreadsheet and then doing the math off of it and basically figured out that if you're in the 100 to 300 subscribers range, you're looking at paying a service like this somewhere between 50 and 20% of your profits in order to just use that service. Keep in mind that this service also includes things like the gateway, so authorized.net or whatever, that 5% that we were already talking about. So really you're looking at maybe like 10 to 15% just to use something like Recurly but you're still gonna have to pay the gateway as well. So then the question becomes, is it worth it? I can't answer that question for you if 15 to 20% of your profit at 300 subscribers is worth it. I will note that the more subscribers you get, the lower this percentage is gonna go and I look at this and I kind of say, oh, it's hard because then as a startup you might think 300 subscribers is awesome. Like holy cow, I finally got the 300 subscribers but you're still paying 20% of your total income. Or you may be looking at a business model that you'll only ever get 300 subscribers. So you kind of have to weigh that. So then there's the cost of building it yourself. Building yourself again, referring to, I'm using something like authorized.net as a credit card vault but I'm doing everything else, all the business logic and stuff myself. I can't make sure exact numbers but I kind of did the rough calculations on the amount of time that we've spent working on this on DrupalizeMe. And I figured out that over the last year and a half we've spent roughly about, we'll say 8,000 hours working on the site in total across everything that we do on the site. And then if you estimate that like, let's say 10% of that time was working on developing features related to recurring billing. Whether that's adding in reporting, extending the UberCart or UC recurring module to do things that we needed to that it didn't, or just dealing with customer relations and dunning management and that kind of stuff. And at that it ended up to be, I have to check my numbers here. So over the course of a year and a half that worked out to be about 300 hours spent doing that. And if you're charging a developer, let's say $30 an hour, when you're talking $30,000 just to build and maintain that yourself, what's the non-trivial amount of money? How much time is it gonna take? Again, I don't really have a good answer for this one. I can tell you that no matter what system you use you're gonna end up writing some custom code yourself. Whether you're using Recurly, whether you're using Commerce or UberCart or any of the solutions existing in Drupal, there isn't anything that is so fully baked that you can just download it and install it and turn on the module and it'll work and solve all of your problems. Recurring billing is a tough place thing to figure out. No matter what you do, you're gonna end up spending time writing some of the code yourself. How much of that code you write is gonna vary depending on whether you're using a service or you're responsible for all the billing logic and so forth. Does it provide the flexibility I need? Can I implement plans that are necessary if you're my business? When we launched the Drupalize Me website we started building it and we're about four months into building it and we said there are two things that we absolutely have to have figured out in order to launch this site. One, we need to be able to serve videos because we're all about streaming videos and people being able to watch them. Two, we need to be able to take people's money when they watch our videos. Everything else was kind of a moot point but those two things had to work flawlessly. We launched the site on PayPal initially using their recurring billing system. A couple months into it, we switched to a different provider. We also ended up switching video streaming and stuff as well. We totally got it all wrong. We launched the site, we said, yes, finally and then we went, oh, let's switch everything. Okay, let's try this again. We ended up switching off of PayPal because two months after we launched the site we decided that we wanted to lower a subscription from $55 a month to $45 a month. And with PayPal we had no way that we could lower the subscription for all of price for all of our existing customers. Because the way it worked with PayPal was somebody signed up for an account. We sent them a credit card number, a dollar value and an interval. And so an interval being say a month or 30 days. PayPal said, okay, I'll store all of that. I will charge this credit card, this dollar value at this interval and I'll let you know if it was successful or not. Once you've set up that plan on PayPal you can't actually ever change it again without customer interaction. So that meant that we could offer all of our existing subscribers a $10 a month reduction in the cost of their plan but we'd have to send all of them an email and say you actually need to cancel your existing account and then sign up for a new one at the new rate in order to get that cost. Which when you get into recurring billing as we'll talk about you get to that stage of telling people that you're gonna charge them money and how much you're telling them. It's kind of interesting waters to navigate. Part of the whole business model as you sign up for an account I'm gonna charge you $10 a month and you might forget about it. I have a Netflix account that I use like once every two years or so and I see it on my credit card bill every now and then and I go oh yeah that's right they're charging me money. I should cancel that and I usually don't get around to it. And then like six months later I'm like oh yeah that's right they're charging me money. Eventually I reduced it to just the streaming instead of the DVD thing but that's a lot of how this people are thinking about doing these recurring billing systems and so when we had to deal with let's email all of our customers and tell them go cancel your account. Suddenly that rose a bunch of red flags being like let's not actually email our customers and tell them to cancel their account. So PayPal ended up not providing us with the flexibility that we needed in order to reduce the cost of a plan and in the way that we wanted to do it. So that's the kind of thing that I would think about with flexibility. Another thing that becomes important to think about too that we deal with a lot is if people have a bad day or if we really like somebody we wanna be able to give them a free month to our service. You know maybe we just wanna be nice and say hey you can have a month free. Does the service that you're using or whatever system you're using allow you to do that? I would say at a bare minimum what you are gonna wanna be able to do is change the price of a plan especially when you're first launching something. You launch it, you have this idea of what people are gonna wanna pay for it. Two months into it you're gonna know what they really wanna pay for it and you're gonna change your price. The other thing that you're gonna wanna be able to do is comp somebody a month. Those are like the two bare minimum things that you'll need to be able to do. And that comp somebody a month can be really handy for a lot of scenarios. So being able to do that without having to tell somebody yeah just cancel your account and then sign up again in a month cause they won't. We also talked about this concept of a card store or the CIM in authorize.net or the vault and brain tree. Basically someone that is storing credit card data on your behalf in order to keep it secure but so that you can charge it at a regular interval. The way that most of these systems work is you authorize.net, you send them a credit card number and say go ahead and create me a customer based on this credit card number. Store the credit card number and then create a token and send the token back to me and I'll store the token on my end. So I'm not actually storing any insecure data on my end. I've just got the token or at least I'm not storing credit card numbers. And then I can use that token and I can say authorize.net charge this token X number of dollars. So that's like if you're using the UC recurring module or the commerce recurring module this is essentially what you're doing. You're setting up a scenario where somebody else is acting as your data store on in Drupal you're storing a token and then your Drupal implements all the logic to on Cron once a month. Take that token and charge it X number of dollars. Authorize.net says cool I've got the token here's the credit card that matches it I'll charge the credit card I'll let you know if it was successful or not. Most of the time they'll let you know sometimes they forget. So you gotta store your credit card data somewhere. When you're building a subscription based system your customers are your most valuable thing. And in fact it's their credit card numbers that are really your most valuable thing because with that you can charge them every month. So you need to be aware of the policies that these gateways have for storage of the credit card data and whether or not you can get it back from them if you ever need to switch or ever want to switch to another service. Technically they're all supposed to be able to give you a method to extract your data from your credit card data from their service transfer it to somewhere else. There are lots of standards about how that is done so that the credit card data gets extracted and encrypted and then moved somewhere else and they decrypted and imported into their system. But if I wanted to move from something like authorize.net to world pay I want to bring all of that data with me. So at a minimum make sure that whatever you're using as a gateway will allow you to take that data with you when you're ready to go. Portabilitystandard.org is an initiative to start to standardize mechanisms for transferring credit card data between payment gateways. So you can look at that and you can get an idea of some of the gateways that support this already. I would also recommend like if you're gonna go with something like authorize.net or brain tree get somebody on the phone and ask them before you sign up. If I ever want to leave you guys can I take my data with me? The other thing that you can do too is if you are in a scenario where you've already got a credit card store with a company and you want to move somewhere else call the company that you want to move to and ask them to contact authorize.net or whoever you're with on your behalf. Most of them will be pretty good about that because they're like sure we want your business and they're generally in a better position to talk to the techs at that place about how that data can be transferred in a secure format. Why do we want to do something like this? Because PCI tends to be quite a pain in the butt if you were in the previous session you heard a lot about this. You don't want to store people's credit card numbers on your server. Period. Pay somebody else to do it for you. It's worth it. All of the complications of doing it and how much money you would spend in order to do so definitely outweigh the 5% that it costs you to use authorize.net's customer information manager. Another thing that I evaluate and think about a lot when I'm trying to determine whether or not I want to build this system myself or use an existing service is this process of dunning management. Like we said, dunning is the process of when I charge somebody's credit card there are a lot of reasons that that charge could fail. The first time I charge it, no big deal if it fails I don't send them the product that they bought. But if I'm doing it on a recurring basis I want to have a process in place to kind of deal with these failures. And I also want it to be smooth enough and simple enough to deal with that my subscribers will most likely stick around. That's that whole scenario of not really wanting to remind people that you're charging them some money. But in this case you definitely have to so you want to make sure that it's a smooth process. Example being somebody, we try to charge somebody's credit card on a regular basis. If it fails the first time we say, oh that sucks, but we'll extend your subscription for three days and then we'll try it again and see if it works. So we'll try again three days later to bill your card. And if it fails the third time we say, oh that really sucks but we're pretty nice so we'll actually give you two more days. So you get a total of five days and we try to bill your card three times. If we fail on the third time we cancel your account. During that time we'll also do things like if it fails the first time we'll send you an email that says, hey we just tried to charge your credit card and it failed, here's what we can glean about why it failed from the gateway. Most of the gateways are actually pretty cryptic about the messages that they return. Authorize.net has something like 400 possible transaction responses that it can return. And you have to kind of figure out like what does this one mean? And am I telling somebody that their credit card changed or that it expired or that they changed their date or that I don't actually know what their real name is and lots of different errors. But basically we want to email them and say, hey this didn't work. Can you, here's why it didn't work. Can you take action? Can you update your credit card number? Can you update your address? Whatever the case may be. You also then need to provide them an interface to do so. So that's one of those things that starts to get a little bit complicated to do it yourself within Drupal. And why I do like the idea of using a third party service. A service like Recurly has a team of who knows how many people. I guarantee it's a lot more than three. Working on their billing system and the process for doing dunning management. They've got better integration with the gateways. They'll be able to respond with more informative emails to your customers. They have processes in place for dealing with the dunning management. They have the ability to provide them with forms where they can update their data. You can do this in Drupal as well. That's how we do it. But then it ends up being just more and more and more custom code that you end up having to write yourself in order to handle all of these things and in a way that makes sense for your business. The other part that's hard about it is dunning management changes potentially a little bit depending on your needs. So it's hard to write one end all be all solution for doing it. Yeah, see, there's a lot of steps to this. This is just sort of the like, oh yeah, how do I pick? Whether or not I'm gonna use a service or write my own. So that's the easy part of subscription billing. Now we can talk about the stuff that's actually hard. When I was doing research for this, I came across this quote on Twitter which says, easy, subscription billing was striped. Still annoying. Reporting to users, their invoice history, plan changes, cancellations. You could add a whole bunch of other things in there. But basically I took this to say, the part of subscription billing that's really easy is charging somebody's credit card once a month. And there's a lot of services that do that. Drupal can do that for you really, really well. There's a lot of other aspects of this that get more complicated. There's a lot of things that have to do with reporting. In this case, not all of the services or Drupal itself are equal. This is something that I would spend some time researching if you're gonna use a service like Recurly or Chargeify. Is it gonna provide you with the sales data that you need in order to monitor whether or not you're successful? Same with using Commerce or UberCart. Both of these solutions have basic reporting built into them so they can tell you how many of this product have you sold? How many of you sold this month? What's the dollar value that you've earned this month? The things that we found to be lacking in that are user retention reports. So I wanna be able to view a report that says somebody signed up but how long did they stick around for? Did you do more people cancel on the first month or the third month and those kind of things? So reporting can be interesting with that. If you're gonna build your own service using Drupal, my suggestion would be anything that deals with the business logic side of things. When you charge someone what happens, log all of that information. If somebody changes from one role to another because their subscription canceled so they lost the role or they just paid again and renewed their account and now they gain the role again. Every time something like that happens, log it somewhere and then expose that data to views and you can use views in order to create a lot of these reports for you. The trick is making sure that it all gets logged. There's a lot of modules for dealing with things like that whole thing of removing or adding a role on Cron basically but you wanna make sure that whatever solution you use, you're tracking the data so that you can have over time use it to generate reports. Other things that are complicated about this that are sort of not just the standard I need to charge your card once a month but you also are gonna wanna keep in mind. We talked a little bit about the allowing for trials thing or that whole first month free. This is something that a lot of the services will offer but it varies what they do offer. There's a lot of possible things that you're gonna wanna do when you're charging someone once a month and a lot of possible ways that you may wanna deal with say, I wanna give you a $10 discount on the first month. I wanna give you the first month free. I wanna give you $10 off the first three months but then after the first three months I want it to go to the full price. Or it might be I wanna give you 15% off the first three months and then go to the full price. There's a lot of variance on that. Coming back to the keeping it as simple as possible. So deciding on one or two basic plans that you're gonna implement and sticking to that. I highly advise that. In, on Drupalize Me, we have this whole super advanced system for dealing with coupons, mostly provided by the Uber cart module and then a bunch of stuff that we've done around that that makes it so we can do all kinds of crazy coupon things like that $10 off the first month, $10 off two months, $10 off the first month and the third month and then 5% off the sixth month and it's advanced. We can do a bunch of fun stuff. We don't use any of it. At most we say you can have $10 off the first month. You can have $10 off the cost of a year but all of these other complicated things that we thought, wow, this is really cool that we can do this. We end up not using it. So we spent a lot of time writing a lot of code and figuring, testing things that we just don't really need. And then other things. We talked about providing UI for updating your account. You also wanna deal, you're gonna need to be able to deal with people who wanna put their account on hold. Again, that may depend on your needs but on Drupalize Me, we wanted people to be able to put their account on hold for three months. So we're not necessarily losing them as a customer. We got a lot of, we don't want them to cancel their account and then have to come back and sign up three months later because they're not going to but if we say you can put your account on hold for three months and we won't charge you until three months later but then we'll start charging you again and that's actually helped a lot for us in order to keep people around. You pay $45 a month for something. If you're gonna go on vacation for two months you might cancel that account on Drupalize Me because you're gonna be gone for two months and you can't watch any of our videos and then you're gonna come back two months later and you may or may not sign up. If we give you the opportunity to put, suspend your account, you're much, much more likely to stick around after that two months just because you don't have to go through the hassle of signing up again. We talked a little bit about making sure that you test your recurring billing system. This is something that we've spent a lot of time figuring out how to do on our sites and I just kind of wanted to share some of this as well. So this is the five commandments of testing. Thou shalt test everything. Even the parts that seem hard to test. Recurring billing, it gets a little bit tricky to test things because you might sign up for a dummy account on your site and then you have to, the part that you're testing is whether or not the role gets removed when my credit card fails to get charged a month from now. So you have to sit there and wait for a month to see if it happens. You don't actually have to wait for a month, but it makes it tricky because you have to get into the database and basically change timestamps and fake things so that when I run Cron and all my business logic fires, I can check and see if it does what I'm expecting it to. Make sure you're doing those things. It's important. Sanitize your data. When you pull data off of production or off of a QA server onto your laptop to start testing things, sanitize it. Remove anything that could reference that person, that account, back to their credit card on authorize.net. So remove that token. One of the things that we actually do is when data comes off of production, we actually parse through the entire database and change everybody's plan to use a dummy gateway instead of authorize.net. So then when it's on my laptop and I'm testing things, I don't accidentally charge somebody's account while I'm running Cron on my laptop to test out a new feature. And I recommend, if you can, using some kind of dummy gateway to do this. There's like both Commerce and UberCart provide this feature, but basically you just want something that is very quick and easy. You don't even need to ping authorize.net's developer account. You just need to send off into nowhere and say, return my own response, but make sure that you're testing using some kind of dummy account. Once you've tested with a dummy account, you should also test with a developer account on whatever service you're using, just to make sure that that end of things is working. All of these gateways and services provide the ability to have a developer account. And finally, you should test with real data, but not real credit card data. One of the things that we discovered with DrupalizeMe is that as the site's been around for a year and a half, our data isn't like perfect lab clean data anymore. We've done things over time to people's accounts in order to just kind of tweak it. We might have added a couple of extra days to someone's account here or there by going into the database and tweaking things. There's a lot of forms that you can tweak in Drupal in order to remove a role or add a role or all these kind of things. So we don't have pristine data anymore. One of the things that I really like to do is when I'm testing this in new features, I'll actually commandeer existing accounts on our site. So I'll just log in and change the username and email address and password associated with some account that already exists on the site to mine, and then I'll use them in order to log into the site and test things out. And just it's a nice way to make sure that everything is really working outside of this perfect lab environment. We also do a thing where we've got a couple of, instead of just having one settings.php file, we actually have two of them, one that includes the other. We store all of our keys for APIs that we use in order to do billing in settings.php. And we also, so that it's not in the variables table. In addition to that, we have it set up in a way that in our settings.php file, which is stored in version control, we have either no keys, like we set all of our keys to false, or we have the keys for a developer account for that API. And then on the server, we have a settings overrides file, which gets included by the settings.php. The overrides file contains the actual keys that are used to interact with, say, authorized.net or PayPal, but those only exist on the live server. They're never checked into version control, they never make it onto a developer server. That's a nice precaution, because even if I fail to do all of those other sanitization things, if I don't have the appropriate keys, I'm not gonna be able to charge your card. So then we do this where we put settings.php and those developer versions of all the variables into version control. And then on the live server, we put the actual keys. And this has been really important because you add new people to your team over time, and they're gonna need to grab your code, start making use of it. You don't wanna have to have a really long document that's like, oh yeah, and when you're setting up your development environment, don't forget to change the live keys to the developer keys because somebody will forget. Another thing that we do that is sort of a not as well-known, if you have the develop module installed, you can tell Drupal to route all of its email that it's sending through the develop module instead of using the built-in like SMTP or post-fix stuff. And what that does is develop will just log those outgoing emails to the watchdog, but never actually send anything. And this is really nice for when we're testing all of our business logic stuff because we might run cron, and even if I'm not testing cards, if your account has expired, our site attempts to send you an email that says your account was expired, and I don't wanna accidentally double up when I do that with data that's on my local machine. Other ways to do that are use a development server that doesn't have post-fix installed, so it's impossible to send email, but sort of blocking that from happening. Yeah, a lot of things outside the scope of Drupal and just sort of billing in general. In Drupal, these are some of the things that I've looked into, and to use to varying degrees of success. On DrupalizeMe, we're using UberCart in the UC recurring module and a handful of other customized bits that we've added in there in order to meet our business needs, and that's actually working really well for us. I've been very pleased with that. In Drupal 6, there's also a implementation of the Chargeify API. I've not used it myself, but one of my coworkers has made good use of that and said good things, and he really liked Chargeify. In Drupal 7, right now, it's an interesting space. There's a lot of people looking into how to do the recurring billing. My experience so far is that there isn't any one completed solution yet. There's a lot of stuff in progress, but nothing that I would trust to use in production yet. There's a mostly implemented Recurly module, so that would possibly be a good way to go if you're interested in using the Recurly service. There's also Commerce module and the Commerce Recurring, and all these other associated modules, which basically does the same thing that UberCart and UC Recurring does, though it does it in a bit more cleaner way. So there's a bunch of, if you're interested in that aspect of building your own, start with Commerce Recurring and follow the trail of umpteen billion dependencies to get all of what you need and start getting things set up that way. But like we said at the beginning, if you're gonna be doing Recurry billing in any form, you're gonna end up writing code. And part of that is just because there isn't a solution yet in Drupal that has it all perfectly figured out. And finally, we kind of touched on this a little bit, but basically when it comes down to figuring out how into doing Recurring billing and sort of the thing that has worked the best for us, the secret to I think why this has been successful for us isn't the services that we use, and it's not the code that we've written, but it's the people on our team and the customer relationships that we've built with everyone. Haley is one of my coworkers and she is amazing at responding to people when something goes wrong. We've had incidents where we talked about a lot of things to look out for testing. You learn these kind of things by trial and error over time. When we have errors, it's been really nice to be able to contact our subscribers and say, we messed up, we're sorry, we have the ability to comp you a free month and we'll do so, but having that kind of customer relations is gonna become really important, because like we said, customers are your most important part here. So focus on communication and customer relations. Use a system that's going to allow you to focus on building your applications and communicating with your customers, whatever that ends up being. So as a recap, I recommend trying to use a third party service if you can, something like Recurly, Chargeify. Again, even doing that, you're gonna need to write some code in Drupal just to get all of that working. Write some, be prepared to write a lot of code if you're not using a third party service. My experience so far is things like Dunning Management is virtually non-existent in the Drupal space. It's there, it can do things like email your customers if you failed to get to charge the credit card, but it's not really smart enough yet to do things like say, fail to charge your credit card and these are the reasons why and so forth. So you're gonna end up doing a lot of work to figure that stuff out. Try and find a way to simplify your needs as much as you can, and then charging someone isn't really the hard part. It's pretty easy to set up a cron tab that charges somebody's credit card every 30 days. It's everything else around that that gets to be more difficult with this. That's what I got. If you wanna ask questions, I'm happy to answer them. We do ask that you come up to the microphone so that it gets recorded. I think it's on. So it sounds like there's not really any kind of solution at all for Drupal 7 without writing custom code. I'm not a coder. I'm using ubercarauthorized.net. I've got errors on the recurring billing after the first month's tread to charge. I'm wondering what I do because I really don't wanna spend more time or money than it takes to do this, and so I'm looking for any, even just something manual for now? I don't know. If you're looking to continue to, so the question was, what do I do if I can't actually write the code? If you're using a system that's based off of existing Drupal modules and it's totally failing to work, it's possible that that's a bug in the code. So file an issue in the queue, try and contact the module maintainer and provide them with details about what you've tried and what is or isn't working, and hopefully they can help you get that sorted out. If you need like an interim step, like the most manual process would probably be something like using PayPal or Recurly, but not having it integrated yet with Drupal at all, but you could log into PayPal or Recurly and set up that account and let somebody enter their information and charge them, but then you would have to be responsible for managing the business logic part of it on the Drupal side where you add the role to their account or remove it if it doesn't work. That would be my recommendation. I would start though with contacting or trying to file bugs in the issue queue for that module providing information about what's not working. Well, I'm using the UC Recurring module for Drupal 7 and I guess I'm not storing credit card data, so maybe that's where the error is coming from. I'm not sure, it's like really over my head, so I don't know, but I mean, I've not used UC Recurring for Drupal 7, but if it's anything, I imagine it's a lot like the version for Drupal 6, they have the same name in fact, and so what that module does is use a service like Authorize.net, so I assume then you have like an Authorize.net account or something like that. You also have to have the Customer Information Manager or ARB stuff set up in Authorize.net. It works in six with those, so it may just be a settings problem too, but again, talking to the people that are more familiar with the code and maintaining the module would be probably your best bet there as a starting point, thanks. Yeah. I actually had a question. You mentioned part of when you cleanse the database information, like removing customer information that you would change the payment gateway you use. My experience is that the Recurring module in Drupal 6 actually uses one payment gateway for the entire site and that's like a configuration. So I was just wondering if it was hard for you when you wanted to switch from PayPal to Authorize.net, like do you have now customers who are on boats or like one system in the different media? Yeah, so there's a couple questions there. One of them regarding sanitizing the data and switching to a test gateway, and then the other one being how do we deal with the fact that we switched from PayPal to Authorize.net. Dealing with the test gateway thing, it's actually not that complicated. UberCart allows you to have multiple payment gateways enabled at the same time. You just set one as the default and whichever one is the default is the one that actually gets used. But you can have more than one turned on at any time. But what we do is we actually have a custom Drush script that pulls data from our live site and when it does that, I don't remember the table name off the top of my head, but there's a table that stores a transaction and the gateway that was used for that transaction and we just update that column and set every value in that column to be, in UberCart, it's test underscore gateway is the test gateway. And so that's how that works. And then in that whole settings override process, since those are just variables in the variables table that says what gateway is being used, we set that in our settings.php. Okay. With the PayPal and Authorize.net thing, our service now actually has some subscribers on both. We're over time getting away from PayPal as those people cancel their accounts, but we still have a handful of them that are on PayPal and it works because you can have multiple gateways enabled. When somebody signs up for a new account, they all go to Authorize.net. We don't allow signing up for a new account with PayPal, but we have maintained those old ones because that was the easiest solution for us. And also when you store information, you talked about making reports with views, but you have to store some information. Do you store that inside the order and then pull that from views? Because I think it's a little harder sometimes to hold that order information. I usually log in of all that information that's going on and transactional stuff. I tend to write a separate module that listens for hooks that are fired by either Commerce or UberCart when things happen and I record that thing happening. And generally I do it in my own table and just reference it back to the transaction, but I like to try to keep it as separate as possible and then just expose that to views. Thanks. Yeah, you bet. Yeah, have you found any services that kind of work really well in a mix and match type situation where you kind of want a payment gateway sometimes, but a lot of the times you're going to end up doing recurring billing and is there any that works kind of better for a both case scenario? So most of your transactions are single one-offs, but then occasionally you do recurring billing or vice versa? Correct. If you're talking about using a full-on service like Charge-A-Fire or Recurly, a lot of them do offer the ability to do single one-off transactions through their service as well. So you can use it primarily for recurring, but then say, oh, I need to charge somebody for the t-shirt that they bought too. Most of those services allow for that in my research in doing so. If you were doing it yourself, then it's just a matter of making sure that your gateway that you're using supports both the one-off transactions and some kind of card store. Yeah. So I'm using a system pretty similar to Drupalize.me with the UC recurring on Drupal 6, and I just ran into an issue where we had to raise prices like last week and I saw on an issue queue that the price was kind of separated from the order, and after I raised prices, the first payment would go through as the raised price, and then the recurring charge would go through as the original price that I had set, and I was wondering if you knew what table or where that was being set. I don't know the table off the top of my head, but I can tell you what it's doing. So the problem is you tried to change the price, and then it worked the first time, but not every time after. Right. The way that the system works is it creates an initial transaction, and that first transaction, it charges you $55 a month, and then it stores that transaction, and every time it recurs, it's actually creating a new transaction based off the first one. So it's not reusing the same order, it's creating a whole new order each time, using the data from the first order. So if the first order that was made for the user's account was $55, it'll always use that. So you need to actually find the original orders for each one, and change the price on that in order for it to... So these are new orders, actually. On new orders? Yeah, so the new order it came through at the higher price, and then the recurring price was set at the original. I don't have off the top of my head solution, but grab me afterwards, and I would be happy to brainstorm with you. Thanks. Yeah, you bet. Awesome, that's it, it's $6.01. If you guys could take a minute to fill out the survey for the session, that would be awesome. Otherwise, thanks for coming.