Building powerful subscription sites that scale on WordPress
At WordCamp Sydney 2019, Ben May from The Code Company and Adrian O’Hagan from Private Media spoke about how a different way of building paid subscription functionality on WordPress.
READ MORE: Building Subscriptions and Memberships on WordPress for Growing Digital Publishers including a download with more information on how to select the right approach.
WordCamp Sydney 2019 Talk Video
You can access the slides here.
Video Transcript
Ben May:
Thank you, everyone. I’m Ben and this is Adrian. Today we want to talk about building subscription sites that scale in WordPress. So, to set the groundwork, cover off a few simple definitions. First of all, for the purpose of today’s talk, where we talk about subscription, we’re also talking about membership. I know the original site talk was about subscriptions or memberships. The definition I’m trying to sort of, I guess, use, is membership is usually a benefit of a subscription to a site of some sort, so just from a naming convention. Scale means two things for us when we work with clients. It means the technical scaling. So, as sites grow, we talk about hundreds of thousands of users or pages or content, things like that, numbers of transactions per day. So there’s the technical scaling aspect to building big sites.
Ben May:
There’s also the business scale, so as a business grows from a smaller operation to a larger operation, things internally change. Very often you’ll have a founder of a publication do everything, and then they start bringing in different people, so that might mean a product manager or a subscription manager or different teams. So, the website and the subscription system has to all play along as the business scales, and it has to work as the site scales up. Subscription are not a new concept, and Netflix started notably back in the ’90s doing DVD on demand as a subscription concept. Spotify very commonly for music subscription, and the world has exploded in the subscription economy.
Ben May:
Two more clever ideas, we see people like New South Wales Transport experimenting with subscription models around public transport, Nike launching shoe subscription services. Subscription has been a really big economic changer in terms of people wanting to own less stuff and moving to a more elastic billing model, and there’s a whole bunch of stuff to go through about that if you’re interested in the subscription economy that we’re sort of transitioning into maybe or not. Back home, Zora, who are a subscription enterprise consultancy, said a little while ago that in the next couple of years, over 70% of businesses in Australia will be offering products in some way or another through a subscription pricing strategy, whether that’s product or even professional services.
Ben May:
So, narrowing the definition down a little bit more, digital subscription has two really main pieces that I’m sort of using as a foundation today. The ability to log in somewhere and the ability to restrict something, and usually by the means of a payment. So, I can log into where I subscribe and I can access something if I pay for something. That’s a digital subscription in a nutshell. Last year, Reuters did a survey of top publications worldwide, and over 52% ranked subscription as the highest priority for a revenue perspective for publishers as the most important, beating things like ads and display, natives, donations and all that other sort of stuff. That’s where both Adrian and I both work in the publishing world, so today’s talk is going to be slightly balanced to publishing, but a lot of the principles still apply in a lot of different business models.
Ben May:
So, subscriptions in digital publishing have obviously helped do revenue diversification for publishers, and as publishers are moving from print to digital, translating that into subscription based economy has helped publishers in that respect. The other advantage for people in digital publishing where we work is the ability to start knowing more about our audience, because they’re logging in and we can start to do things like profiling and progressive profiling and understanding people’s behavior over long periods of time because they’re not anonymous. We now know who they are.
Ben May:
So, bringing that to WordPress then, what we’re talking about, and building subscription products in WordPress, which we’re going to talk about some projects we’ve done this year, is three main parts to how we want to focus WordPress and subscription offerings. So, that’s making sure we’ve got a robust architecture of how we build subscription integrations with WordPress, so it needs to work from a technical perspective, it needs to be flexible when other developers join a team or different agencies work on different parts of the subscription ecosystem. The business autonomy, so, again, when a business might start working with a subscription, one person might be doing everything. So, what we’re looking for is the ability for a business to be able to change a price or upgrade a membership tier or move a user or do things like that without having to write code, log into a database, do anything like that. We want the business to have autonomy that doesn’t need the development team to manage these kinds of things.
Ben May:
Then of course scalability. We want growth, we want the business to be able to do things. We want to have lots of customers and all that sort of stuff. So, there’s four ways to do a subscription, broadly speaking, in WordPress. An off the shelf plugin, or more likely than not a series of plugins to put that together, building a plugin, so going and starting from scratch and building a bespoke plugin to do exactly what you’re looking for. Going down a microservice, which would be the more common way of describing it, but building a standalone application in another framework or another platform, and then integrating that back into WordPress. The fourth option is the SAS integration with an on demand cloud product, which is what we’re going to talk about in a bit more detail today, is working with SAS products.
Ben May:
So, just quickly going through the four options in a tad more detail, off the shelf products often are great to get a proof of concept up and running. There’s no shortage of WordPress plugins that will do membership software. But again, if you’re working in a large business that is, say, doing a million dollars in subscription revenue, the economics of using a plugin that costs $100 that powers this entire business is not a usual comparison you’d make in any other part in a business decision matrix. So, often quick way to get started, but long term implications, and getting out of that plugin ecosystem can be very tangled and complicated and painful. A lot of these plugins are often, I guess, more generic built to suit the masses because they’re a plugin. As businesses want to do nuanced or specialized features, you now have to now either try and reverse engineer the plugins, stop gap solutions, multiple plugins, things like that.
Ben May:
So, the last thing with plugins that we’ve found or been burned with as well is debugging performance. So, lots of traffic going through a subscription process, trying to understand where server performance is lagging or where database performance is lagging, and understanding these kinds of things. Again, if you’re paying $200 a year for a plugin that does everything, it’s very hard to sort of have high expectations of it can do everything that you’re wanting it to without knowing. Building a bespoke plugin is slightly better in that you’re now going to have more flexibility, you sort of know exactly what you’re building. It’s going to be able to work the way a business may want the subscription product to work. But it’s a long term commitment to make sure the plugin continues to work. You’re now taking the risk of managing things like Stripe API integration, and if Stripe updates their API, you have now got to update your corresponding API to make sure that works.
Ben May:
So, you have to explain to either your stakeholders or your client or whoever that is, that it’s a long term investment to make sure that this continues to work. And if you’re like anyone who we work with, are always wanting to do new features and exciting things that excite clients or excite subscription customers rather than saying we have to upgrade an invoicing API, which is a very unappealing concept to spend money when there’s more things to be doing. Yeah, it’s the investment in sort of maintainability. Going down a microservice sort of architecture of building something in, say, a Laravel or a coding note or 100 other different products, maybe a bit quicker, but you’ve now broken out of the WordPress ecosystem, so you’ve now still got that long term commitment of managing these two different things with the risk of that you’ve now two tech stacks, so maintaining that is also going to become more complicated, as well as maintaining API integrations with things like payment gateways, you don’t have to manage that with WordPress as well.
Ben May:
So, some quick advantages in working with specific frameworks for this, but there’s a higher cost of ownership over a long period of time as well. Brings us to the fourth, which is our flavour at the moment, which is integrating with a SAS solution. These are cloud based vendors, the likes of Chargify, Recurly, and things like that, that are a business model of building subscription products and basically tying in integration between WordPress and Chargify or whatever the product you want to talk about is. It allows you to focus on business development on the site that is subscriber facing, so building features that subscribers are seeing, and not having to build stuff that is not fun or exciting from a business perspective. It allows business users to deal with a product that’s exactly designed for what they’re working with, and having a seamless integration sort of will speed up day to day operations and things like that.
Ben May:
So, they’re four ways of doing it. We’ve been doing a lot with the SAS way, and we’ll go through how that’s done in a minute, but to sort of give some background, Adrian’s going to talk about his history with Crikey and their evolution of going through some of these options, and then I’m going to talk about a client that we’ve done, and their last three to five years of going through a subscription system and how that’s scaled and stuff like that. I’ll hand over to Adrian.
Adrian O’Hagan:
Thanks, man. So, yeah, as Ben mentioned, I’ve been with Crikey for some time now. When I first started, they were actually extremely hesitant to bring on someone who is both a product manager and a technical person. The reason for that was they’d had an extremely bad experience. The experience that they had had was they had an existing subscription service. It was custom built for them, something called Subscriptus, you can look it up. It doesn’t really exist anymore. It was kind of a thought bubble. It was weird. To cut a long story short, they decided this isn’t working for us. It’s not meeting our business requirements. We’re going to migrate to another platform. These guys are fantastic, we’re going to move over to them, and everything’s going to be wonderful.
Adrian O’Hagan:
They did their due diligence, they thought everything was going to be great, they thought they had all their ducks in a row. It was like, “Right, we’re going to move from subscriptions to these new people.” Someone flicked the switch and they did not take a payment for the next two months. So, now you’ve got a business where you can’t really concentrate on work because all you can hear is your management grinding their teeth, and everybody is stressed. It’s not really a very fun place to be. When it came time to take on a new person such as myself, that was a very long interview process, because they did not want to have that issue again. One of the very first priorities that I had when I came on board was to take us away from this new platform that they’d signed up to.
Adrian O’Hagan:
So, what was so bad about this new platform that we’d signed up to? Well, firstly, we lost two months of payments, where Crikey is an organization that lives and dies by its subscription base. If we’re not getting paid, we can’t really operate. It’s just not good. Then, of course, there’s the product itself. Now, for those of you who have subscriptions, and I dare say most people in this room have got a subscription of some kind, whether it’s a Spotify subscription, Apple TV. Heck, some of you may still be getting the newspaper delivered. That is probably the oldest subscription model that is around. It’s totally valid. Subscription models, they’re not new. They’ve been around for quite a long time.
Adrian O’Hagan:
So, as far these subscriptions are taking place, we have a monthly subscription, we’ve got a quarterly subscription, we’ve got our annual, we’ve got our concession rates that we offer to people. We also have student prices. So, we’ve got multiple tiers of subscriptions. But with this product that we’d moved to, it was like, “Well, what if we’ve got all these people on a monthly plan and we want to move them to an annual plan? Well, we can’t do that. Oh, okay. So, that was a problem. Then it was like, “Right. Well, we want to run a campaign and we want to offer people 15% off or 20% to come on board and become a new subscriber.” Oh, so if we do that, then we actually can’t do that with our product, we have to create another product which has got 20%. Okay, we can kind of work with that.
Adrian O’Hagan:
So, by the time I started working with Crikey, they’d been with this vendor for quite some time. The first thing I did was I looked at the products. I’m like, “Why is there like 150 products? They’re all the same thing, right?” They’re like, “Yeah.” “Well, which one’s the main one?” “Most of them.” I was like, “Okay, well, how do you work out who’s about to churn?” For those of you who don’t know, churn basically means that when you reach the end of your subscription, you don’t renew. For companies such as ourselves, that’s really important. “So, you get to the end, so, how many people are about to churn?” “We don’t know.”
Adrian O’Hagan:
It’s like, “How do you know how many people renewed this month and how many people took out a new trial, or how many people took out a new subscription?” “We can’t tell that with our data.” So, there was a wealth of problems with this particular service. Shortly after I started and was kind of realizing what a mess I’d walked into, it was a case of, “Okay, well let’s see what I can do. Let’s see what’s going on.” Then I got a Slack message from one of my colleagues in support, and she said, “Adrian, it’s not accepting payments at the moment. I think the API is broken.” I’m like, “Oh, okay. Can you give me a contact number?” “Oh, we don’t have a contact number.” “Well, what’s their chatline?” “They don’t have one. You can email them.” I’m like, “Okay.”
Adrian O’Hagan:
They’re based in Germany, right? So, we had to wait 14 hours for a response during one of our biggest campaigns, we have two major campaigns every year. End of financial year, we’ve got our Christmas campaign. I might have mentioned that subscriptions are the bread and butter of our business. None of this was great. The whole experience made me really, really evaluate what do we need to get a better solution? What is it that we want? What is it that’s not working for us? At that point, I started making a list. Not only did I do that, but I had a separate list, which was basically keeping notes of every single outage, every single time they didn’t respond. I was making a shopping list so that if they came to me and said, “No, no, you’re still in contract, you have to do this,” I would basically say, “You’re kidding me, right? You guys are incompetent. You are costing us money. Like the amount of money that we’re paying you, we’re losing exponentially more because we’re not able to take payments effectively.” So, that is the background of Crikey. From there, we moved onto a SAS service, and I’ll talk about that more shortly.
Ben May:
Yep. So, Mumbrella are a client of ours we’ve worked with for like, I think, eight years now. About five years ago, five, six years ago, in a very rare series of events, we got briefed with about two weeks notice to build a subscription product for them before they announced it at their annual conference they have every year. So, with no designs, no brief, no idea, we started building something. It got launched, and it was essentially a log in restricted site that they called the source, and it was like a contact access database. It had a whole bunch of research and stuff. That’s very important if you’re in the big end of the media marketing industry in Australia and things like that.
Ben May:
At the end of the day, it was basically a gravity form that I think set up like a eWay token that we stored as a meta. We did the base camp thing. We just got that part done and live and then figured out how we charge people after that once it was already live, so we were really playing with fire, but that was really our only option at that point. That sort of grew from this single user having a subscription with an expiry date set as a meta field that then we checked when they logged in. Is that before today’s date? Okay, they can keep going. And they had to back and update a gravity form, and that would set up a new token. It was very, very poorly done, but it got launched and it got done.
Ben May:
They then continued to invest in this product over time, and we’ve now built this site with a very questionable foundation that we then started dealing with things like, “Well, how do we have a five user account?” It’s like, “Okay, well, we’ve got this flat structure, there’s no way of doing that, so, okay, we’ll just use meta to connect user IDs laterally, and that will never backfire on us.” Then about six months later, they started wanting to do things. Well, how do we change the primary account holder to somebody else? We’d have to log into the database, move all this meta to another user and then join that and it continues to work, and then hopefully eWay’s still recognizing it. Okay, that’s fine.
Ben May:
Then that evolved even further to wanting to access more features and more sort of just general my account stuff. Again, it’s not making their subscription any more inviting for people to sign up. It’s just how do we do this stuff? Then we had to try and migrate that whole data schemer, which was very poorly done and built on top of to a slightly more advanced one, which is now like a custom post type that stores the account object, and then we have meta that connects those to users so we can easily switch them. The eWay token is now connected to the subscription entity, and then there’s another custom post type where we define the subscription products, and then that’s all connected through more meta, then we have look up tables to join all that meta because there’s now hundreds of thousands of meta fields and it takes like three hours to do a chron.
Ben May:
We had problems on this old server that it ran where we had to run a cron to restart PHP once a day, I think it was, because of a hidden memory limit. We could never move it because it was hardwired to how this was set up. But then at the same time, we figured out at one point because the payment cron was taking longer and longer to go through and do it, that PHP thread was doing its reset, which meant by about the fourth transaction, it was now resetting and losing the crons, and then we were sort of lagging in payments and it would take a week to catch up. It just continued to be a real joy to work with, and Scott, who works for us, was really tasked with a lot of this fun because no one else would touch it.
Ben May:
I think Zach did a bit of a rebuild and then went on leave and Scott had to launch it, so that was even more fun, especially trying to understand that data schemer. So the source was really fun and great to work with from a technical perspective. It doesn’t even go into how much pain the internal team at Mumbrella had to deal with managing this on a day to day or trying to understand how things like users and things were built, but it was that classic problem of we don’t have time to go back, we just need to keep going forward, going forward. Then finally one day they sort of from a business perspective decided, “All right, we need to rethink how we’re doing our subscription product,” and more from the product perspective, but it was a great trigger for us to say, “Let’s clean house with the backend,” because you’re spending 10 to 20 hours a month just on keeping the thing alive, just on support. Like, why can’t this user review an invoice? Because they have a customer mount that was in 2012 and then they migrated.
Ben May:
It would just be this log of going through the database to understand things that were happening every day of the week, which is not how a business should run, and we weren’t spending any time on the product for them. So, the source died. We deleted all the code base one line at a time therapeutically. But we rebuilt Mumbrella Pro, which was their new product. They wanted to bring it closer in with their branding, and they’d sort of gone through a corporate rebrand as well. Part of that was building a fresh site, fresh content taxonomy, and all of that was great. We decided to not build a subscription engine. We wanted to go to a various SAS product, so we didn’t have to have an arms length with anything to do with invoices, billing, GST, refunds, upgrades, downgrades, trials. We don’t want to know anything about that. We don’t want to have to get asked to create coupon codes or custom types of coupons. Any of that sort of stuff is just a waste of our time.
Ben May:
So, Chargify was top of our list, and we’ll go through how we arrived at that, and we were able to do a migration out of this custom WordPress integration into a new WordPress site. Chargify, what it allowed us to do, actually, to migrate tokens out of our custom bespoke thing into Chargify, and it just picked up and continued to bill as if nothing had ever changed. We migrated hundreds of users without a single payment failing or going wrong or anything like that. So, in that sense, we were able to destroy this old site that was very hardwired how everything was built to an incredibly clean system where WordPress is just running content and users, and Chargify is doing all of the business logic. We don’t get asked to run reports anymore. We don’t have to do anything like that. It’s all managed through a platform that’s designed for that, and it gives us that ability to move at different speeds. So, I think finding a platform was back to you and your process going through.
Adrian O’Hagan:
Yeah, thanks. Thanks, Ben. Ben, you actually reminded me of some of the other issues that we faced.
Ben May:
It’s like therapy. We could spend the whole afternoon probably talking about what we’ve worked on.
Adrian O’Hagan:
Look, when I was putting this presentation together, I was talking to some of my colleagues. I’m like, “Do you remember when…” they’re like, “Oh, God.” There was just terror in people’s eyes, which just goes to speak that when you come to a solution and you move forward with it and you’re happy with it, it’s how much pain gets left behind. Typically people when people have had trauma, you like to leave that behind, which is a good thing. So, getting back to finding a platform. From our perspective, here we were. We were with a platform that was not great, and we wanted something that was better than not great. Ideally, we would want it to be great. Basically I made a lot of lists. I just made a massive Excel spreadsheet and I wrote down all the things that we wanted. I spoke to the support team because they were facing the brunt of all the people who were calling up or sending emails saying, “You guys suck. You can’t even take money.”
Adrian O’Hagan:
The payment flow was like a choose your own adventure. I was amazed that they were actually able to take money. Even worse, if you were a renewing person who’d been with us for four or five years, it was harder to give money on a subsequent basis than it was on the original basis. So, as I said, make lists. Check with your support team, make sure that that’s okay. Check with your finance team, because they may want to have some kind of integration with Xero to make their reports a lot easier. At the end of the day, time is money. It makes total sense to have that. Check with your marketing team. I can’t emphasise this enough because they’re the ones that come up with the campaigns that are going to be to run to promote your particular service. So, whether your service is selling shoes or whether it’s selling food or whether it’s selling online publication subscriptions, it’s all important.
Adrian O’Hagan:
Anyone who’s going to be impacted by the choice that you make, you really need to talk to them. One thing that you should also keep in mind, of course, is depending on the kind of deal you make, you’re going to be offered all kinds of amazing deals. It’s like, “Stay with us. If you stay with us for 20 years, we’ll give you a five percent discount,” or something stupid like that. Just be practical. So, finding a platform, we’ve got payment processing and finance, we’ve got membership and plan handling. So, by plan handling, I’m talking about obviously what kind of plans you’re offering, whether it’s an annual, monthly, the ability to swap out, ability to upgrade, access to data and reporting. Cannot emphasize this enough.
Adrian O’Hagan:
A lot of people kind of see it as a nice to have, but it’s important to be able to forecast your revenues, it’s important to be able to understand what it is that your audience is doing and to be able to act accordingly, and for it to be developer friendly. That’s not a nice to have, that is essential. There is no single platform out there that is going to be perfect for you. But if they’ve got the tools for you to get in there and get dirty, then you can make it right for you.
Adrian O’Hagan:
So, as far as payment processing and finance is concerned, we had a bunch of options that kind of tie into this category. First of all, we wanted it to be white label. We don’t want something that says, “Brought to you by PayPal,” or something like that written all over it. It had to look seamless. It’s all about trust. If they don’t trust you as a seller of goods or a seller of a subscription service who they’re entrusting you to provide them that service over a period of time, then you’re wasting your time. Coupon management. You don’t want to be creating another product every single time you are offering a coupon. That’s ridiculous. So, that is really important.
Adrian O’Hagan:
One thing which is a nice to have is dynamic coupons. For example, Tom comes along, and he gets to the point of a transaction and he decides, “No, no, I’m not going to go ahead.” But you’ve got his email address, so you send him an email and you offer him an extra 10%. Custom to him, as long as he uses it in the next two days. A lot of people won’t offer this out of the box, but with developer APIs, you can write that kind of thing. Invoice generation. Does it include tax? Australia is a bit of a funny place globally as far as tax is concerned, because if we say a product is $20, we expect it to be $20. It’s not like in the U.S where it’s 20 bucks and it’s like, “Oh, by the way, no, it’s however much because it’s got tax on the top of that.” So, you need that to be included.
Adrian O’Hagan:
Promotion options, referring to a good or service being offered. Yeah, so I think that kind of came underneath the coupon management, but flexible payments. There’s been a lot of talk about micropayments, the ability to maybe pay per article or something like that. Some people are interested in that, some not so much. As far as I’m concerned for our particular model, weekly, monthly, annually, super important. The ability to switch between, I can’t emphasize enough how important that is, because generally speaking, people will start on a monthly basis, and once they’re comfortable with you, it’s much easier to up-sell them to an annual. Once you’ve got them on an annual, they are much less likely to churn.
Adrian O’Hagan:
So, membership and plan handling. You got membership level plans, so of course I’ve kind of spoken about those already, access rules. Generally speaking, if you’re going to have a membership plan, particularly with WordPress, then you’re talking about access. If you’re talking about access, then you’re talking about, “Well, how much am I preventing the customer from seeing, unless they’re a member?” Are you showing them the first two paragraphs, are you showing them no content whatsoever? Is it just a standard sign in form or something like that? Does this platform handle it for you? So, there’s questions around that.
Adrian O’Hagan:
Trial periods, there’s multiple ways of going around this. Probably one of the industry standards ways now is to take their credit card details, give them like a month free or something like that, but because you’ve got your credit card details, if they don’t opt out, then it just auto renews. I’m sure anyone who’s worked with Stan or Netflix are very familiar with that kind of approach. Unique registration pages. That’s also quite important because you’ve got different audiences. You’ve got your concessions, who are on a very different rate to what the retail market is. It might be a difference of about 40%. It kind of looks weird if you’re saying, “I’m more than happy to give you this for $200, but I’m going to give it to you for 150. You’re nicer.”
Adrian O’Hagan:
The ability to pause and resume your subscription, that can be handy. Some people like to travel internationally. It’s not necessarily such a big thing with digital nowadays, but some people like going off grid, and they will actually contact us and say, “I’m going to be living in a cave for the next three months and I don’t want my access.” Switch plans and frequency I’ve spoken about. Transactional emails, well, that’s a given, but the ability to customize those is pretty important. Changing user email address. Ben was actually referring to this with Mumbrella, and I can tell you now, that was a nightmare for us before. Yeah.
Adrian O’Hagan:
I mean, everybody here who’s aware of course that in WordPress you cannot change your username once you’ve created it. You can, it’s just really bad practice. But if somebody changed their user email address, that would just get kicked up to development straight away. Should not be the case. And finally, reminders. Well, reminders kind of tie into transactional emails. But, again, all of these things are things that you need to be mindful of. Access to data and reporting. How many people you take out of trial are actually converting? Because that tells you what your marketing campaigns are like and what needs to be tweaked. How many new subscribers are you getting? How many subscribers are moving up and down? What kind of revenue retention are you managing? What kind of revenue breakdown? There’s a difference between the two.
Adrian O’Hagan:
Subscriber churn, can’t emphasize this enough, that should be around 10% also. But in some instances, 24%. Revenue forecasting, changes to email address. I’m not sure why that’s there, but that’s okay, and accessing raw data via the API, because that way you can actually create your own custom reports, which can be very handy, particularly when you might want to work with a data scientist. Finally, developer friendly, and that enables us to do some very cool things, which I will probably speak to later. But things like offering users an extra month for the sign up. Other considerations, costs and contracts. Make sure that you don’t take out too long a contract, and support, make absolutely certain that they’ve got 24 hour support, either by chat or by phone, and that you’ve got an account manager who can look after you.
Adrian O’Hagan:
Then just very briefly because I know we’re out of time now, this is the sort of way we’ve been working with this in WordPress in building. We’ve both been using Chargify a lot as a SAS product. We both really have enjoyed working with it. I know Crikey and Private Media have had huge savings and huge ability to get stuff done and it’s just made their life so much easier. We’ve done a couple of big projects on it this year as well. The flexibility in migrating to it has just been so good to work with, and our team loves it. It’s been really handy. It allows us to build a WordPress subscription product. It lets WordPress be a CMS, manages content, manages users. We can do those white label sign up pages, we can talk to a Chargify API, we can let it deal with things like credit card processing and accounting software and things like Xero, and the user doesn’t leave the experience, things like renewals, we can let Chargify run that. It can do every charger needs to do.
Adrian O’Hagan:
If it’s good, it can just tell us through a web hook, “That person’s good, extend them.” If not, it will bring it back and say, “Turn that user off. We need to figure out why they haven’t done it,” and Chargify, again, has got great internal tools for managing dunning or failed payments and all that sort of stuff. We’re doing very little at WordPress, and it gives us a lot of autonomy to not have to worry about tying too closely into the integration;. Let WordPress do what it does well, managing and scaling content, something WordPress does really well. It manages users and log ins really well or fairly well, and let a tool like Chargify or whoever you go through to manage high frequency payments, things like PCI compliance complex subscription management, like writing all the queries and that natively. If a plug in doesn’t do that, it’s just so much nicer to offload that to somebody else. Let it deal with all the emails and things and the scale like that. Our summary, and thank you.
Ben May:
The only thing that I will follow up to say that after we did move to our SAS solution, which was Chargify, our costs went down, our ongoing costs went down by 60 to 75%, and the transition time, I mentioned before that we lost two months of payments. Our downtime was zero, which had people in my office basically thinking that we were rock gods, so that was kind of nice.
MC:
Cool, thank you Ben and Adrian. Any questions? Yep, right up. Get your run on.
Audience:
Thanks, guys. That was really interesting. Given the way it sounds like Chargify through the API will talk really nicely with WordPress, has that given you any thought, probably you, Ben, more so, about whether there is a plugin solution that could be build deliberately on that model? Or does that have the same pitfalls as what you were saying earlier with the plugin solution?
Ben May:
Yeah. There is a WordPress plugin for Chargify that I think the guys at 9seeds built, but it doesn’t look like it’s been that updated. I’m trying to pressure Chargify to get us to build a new one, whether that will happen or not. But I guess the thing for us is there’s not a lot of integration. Same way Crikey’s built, there’s a Chargify system, there’s a WordPress system, and Chargify has a really… sort of like working with Stripe, really good web hook system that you can monitor and test and emulate. So, we’ve sort of built half a dozen chase on API end points that are all authenticated and all that sort of stuff. That’s about it. We didn’t have to build very much. The signup stuff has a bit of a custom dev hooking into how that all works and making sure, but there wasn’t a lot of custom code considering the complexity.
Ben May:
One thing I glossed over was that it sort of decoupled in the sense that if Chargify goes down, WordPress is still often running. The system that Crikey was on beforehand, it made a live call every single page request back to the system, and when you looked in your relic, you’re like, “Why is it just this three second web background process?” And it’s like, “Oh, their API must be running slow at the moment,” and you just have all these crazy kinds of things. What makes it also with working with Chargify, again, it’s not a paid endorsement of Chargify, but if you were to move away from Chargify, you would really just be able to plug in another system. It’s sort of decoupled enough that we’re not locked on Chargify. WordPress still has all the data it needs. It has a Chargify user ID so we know who it is, but you could quite easily transition that to another tool if you wanted to. We’re not doing live look ups every single page load to check if a user should be able to access this piece of content and stuff like that. So, we’re currently really using it as a utility, not as the heart and soul as the whole product. Yeah.
Adrian O’Hagan:
I’ll probably expand just a little bit on the plugin angle. I mean, my background is really developing processes that enable the administration, whether it be marketing, publishing, et cetera, to be able to do what they do better. So, I’ve been able to extend the admin through things like events at custom fields or something like that, so they’re able to create their own campaigns. You create your discount or whatever in Chargify, but then you can via the events custom fields, which talks via the API, you can do things like, oh, okay, well if they use this particular coupon code, we’ll give them an extra two months time or something like that. That’s not something that Chargify offers out of the box, so that’s what I’m talking about in terms of off the shelf product. But because of the API, you can extend that and do a lot of other fun things.
Audience:
Thanks for the… it was a great presentation. How quickly, like the turnaround time, from when you decided to use this new SAS system to when it was fully operational and you were comfortable with it, how long did it take?
Ben May:
From a clean build or a migration clean build?
Audience:
Well, from your… say, I don’t know-
Ben May:
So, the MumbrellaPro one, there was a lot of work that was nothing to do with Chargify. It was trying to understand all the old data. It’s like the way it was built in V1 sort of this way and the way the date was stored in V2 was this way, so there was a lot of spreadsheets and a lot of conference calls to figure out just to clean the data. So, if you strip all of that out of the process and the PTSD that came with that, building the Chargify integration was actually pretty easy. And because that migration was migrating users out of an old WordPress site into Chargify backend, and it did web hooks and it all just synced up and married up perfectly. That was I think less than a three month project, including migrating three versions of user data into Chargify, merging three versions of ACF data, which was nothing to do with this talk but probably equally or more painful than the user data, going through three iterations of ACF storing content, migrating that into a new WordPress instance and a whole bunch of other stuff.
Ben May:
The Chargify piece was not a significant piece of work. Like I said, it’s like half a dozen end points, and it works really well with testing and stuff like that. So, it has always felt for me very confident. I’ve never been like, “Why did that just happen? I’m a bit iffy about Chargify.” It’s always been very robust. It’s never given me a reason to doubt its ability, so, yeah, we’ve had pretty good success.
Adrian O’Hagan:
Yeah. I dare say we have a very similar timeframe as well. But of course, we’ve decided to make our lives a little bit more complicated by reskinning the site at the same time. But, yeah, it was pretty painless. Chargify took our existing tokens from the old payment system and transferred it to the new ones. They did that behind the scenes for us. As far as our development work, we’re probably talking for the Chargify specific stuff and the paywall specific stuff, maybe about a month. But that was because we were super anal about making sure that everything was within our infrastructure and looks like it’s within our stuff. If we wanted there’s an option where you can basically port over to your sub domain, .chargify.com, and you skin that a little bit.
Ben May:
Billingportal.com or whatever.
Adrian O’Hagan:
Yeah.
Ben May:
They’ve got a whole white label billing portal, but yeah, Chargify and Crikey’s got a custom one.
Adrian O’Hagan:
Yeah, and you can do that, which will save you a couple of weeks. But we didn’t want to do that, we wanted to make our lives difficult and make it look good.
Ben May:
And in terms of risk, the stuff that really is nice for us is that it’s, I guess, more of an enterprise grade product, stuff that we’ve been burnt on with other projects that I pulled out of the slides, but where you’re running a plugin that runs on another plugin that connects to Stripe, and it runs off a WordPress chron that triggers a web hook. If you pull that to a local dev, you think you’ve got every sandbox, we had one of our front end devs pull a site down. Everything we thought was stripped down to sandbox mode, and he removed a tier, like the silver subscription, and that somehow triggered this, which triggered that, which still had a ping to the production Stripe account, canceled their subscription, pinged the production websites web hook, deleted the users, so Zach and I had to manually recreate… and it’s just like, these tools aren’t designed for that kind of work, whereas something like Chargify, we have two different instances. Everything is explicitly clear.
Ben May:
We’ve just never had something, “Whoops, we billed a client,” or, “We didn’t bill a client,” or, “We just deleted everything.” WordPress and managing things like chrons and schedule tasks and stuff like that can get very daunting very quickly if you’re not really across it, and, “Did all the bills go out? Did all the invoices go out today? We better just double check.” When you write your own, they’re the risks you take on that you have to manage yourself and hope that your queries aren’t missing a one, you just didn’t bill any of these clients for three months and things like that. So, yeah, never had a worry for it.
MC:
No more questions?
Adrian O’Hagan:
I think there’s one over there.
Audience:
I just want to ask about the PCI compliant of the Chargify, and what sort of payment available? Is it like a PayPal, or so you also support Afterpay or something like that?
Ben May:
In terms of the integration from the PCI side of things, they’ve got API similar to Stripes and eWays, where it’s client side JavaScript combo back end thing. So, you’ll do part of the transaction through a token back to the site, then it will validate and send the rest through a web hook, so no credit card details are touching your side. It’s all getting done client side and then validated through a back end IPN kind of thing. So, in terms of PCI, we never touch credit cards. It’s always client side, and through their new API and a lot of credit card APIs, and did you want to talk about the options like payment gateways and stuff. There’s a lot.
Adrian O’Hagan:
Yeah. Well, I mean, we’re using Brain Tree, but we could have used Stripe just as easily. I have spoken with Chargify recently. They’ve got Google Pay and Apple Pay coming up soon, which is going to be quite big for us.
Ben May:
I don’t think Afterpay would work, because Afterpay, you’d always be… that’s a subscription already, so Afterpay, it’s like a subscription for the first payment of the subscription, so you’d probably never really get ahead on Afterpay for a subscription product.
Adrian O’Hagan:
And certainly from our perspective, Afterpay, it doesn’t make any sense for our particular business model, so we wouldn’t even entertain that.
Ben May:
You would just set up a subscription product of weekly. If you wanted to get them the amount that small, you could just have a weekly subscription pricing version, yeah, would be the way to do it.
Audience:
[inaudible 00:43:16] PayPal?
Ben May:
PayPal, yes. Yep.
Adrian O’Hagan:
We haven’t used PayPal in a long time either. Credit card seems to be a bit more fluid.
MC:
Question up the back there?
Adrian O’Hagan:
And also the politics of PayPal.
Ben May:
Well, yeah, they charge a lot.
Adrian O’Hagan:
But, yeah, we’re using eWay, Brain Tree, Stripe. It’s pretty flexible like that, so you can plug and play with different vendors.
Audience:
Hey there. You said you use Brain Tree.
Adrian O’Hagan:
That’s right, yes.
Audience:
What was the kind of decision process behind that versus Stripe?
Adrian O’Hagan:
Legacy.
Audience:
Okay.
Adrian O’Hagan:
It was purely there when I’d arrived, and I didn’t want to… I mean, that process, we changed a payment platform, mail delivery platform probably within maybe a three month period. So, effectively, all of our big providers were being changed at the same time. I really didn’t want to make my life any more complicated than it had to be.
Ben May:
I think before it was Brain Tree it was some weird not mainstream credit card processing brand, so it went from that to Brain Tree, and I’m guessing that was one less fire to… like poke the bear anymore with all the various tools that are getting changed.
Adrian O’Hagan:
Yeah. I mean, I’ve got nothing against Stripe. I personally use Stripe for any personal project that I work on. They’re great. All things being equal, I’d probably prefer to be over with Stripe because I think they’ve already got stuff to do with Google Pay and Apple Pay, et cetera.
