Tag: business

My theory: Patreon doesn’t want to be a money services business

tldr: Patreon is changing their fee structure, in part, because the batching of pledge payments from one patron to multiple creators and the use of Patreon balance to pay pledges without processing an external payment requires “holding funds in a balance that can then be redistributed” and makes them look like a money transmitter money services business, which makes them subject to additional regulation.

Also, if you want to follow my stream of consciousness thoughts on this, see this twitter thread.

Updated 9-Dec-2017 9:35 PST: Fixed a few typos.

Updated 11-Dec-2017 10:00 PST: At least one person has indicated Patreon might be using Stripe Connect and that would obviate any concerns with Patreon being a money services business. Sure, they could be using Stripe Connect. As far as I know that hasn’t been confirmed by anyone (let me know if you know otherwise). For the MSB issue to be of no concern, Patreon would also have to be using the equivalent service for PayPal transactions and they would have to be operating in compliance with both of those services. 

Patreon, a crowd-funding platform focused on serving creators of online content such as web comics, digital artists, writers, musicians, podcasters, etc., announced a new fee structure this week.

Many who use the service, creators (those who make content) and patrons (those who support creators with financial contributions) alike, are very upset about the new fee structure. Search Twitter for “Patreon” and you’ll see the feedback is overwhelmingly negative. It’s particularly so from creators who are supported by many small ($1-5) pledges as well as the patrons who support them with these pledges.

The reason for this stems from the specific changes, which I’ll review briefly.

Patreon’s current fee structure

According to their documentation, Patreon’s current fee structure is as follows:

  1. 5% platform fee: Patreon takes a 5% of each pledge from the creator’s share after the pledge payment is successfully processed. The fee for a $1 pledge is $0.05. For a $5 pledge it’s $0.25.
  2. Payment processing fees (variable): Patreon takes a variable amount from the creator’s share to cover payment processing fees incurred from processing pledge payments. More on this in a moment.
  3. Payout fees: Patreon collects a fee anytime creators move money from their Patreon balance to their bank or PayPal account. For US customers, the fee is $0.25 for every transfer done via Stripe and for PayPal it’s $0.25 or 1% of the amount transferred capped at $20 USD per deposit. Non-US customers have different rates (see the documentation for those).
  4. Value-added tax (VAT): If the patron is subject to VAT, then Patreon collects the appropriate amount from the patron and does all the required paperwork. See this post to read more about how Patreon handles VAT.

Now, back to the way Patreon has been processing pledge payments and assessing the fees associated with that.

There are two fee structures for pledge payments depending on whether the payment processor is Stripe or PayPal:

  • Stripe charges 1.9% + $0.30 per transaction.
  • PayPal charges 5% + $0.05 per transaction.

So, a $1 pledge payment processed via Stripe would have a fee of $0.32 ($.019 rounded up to $0.02 + $0.30) and a $15 pledge payment would have a fee of $0.59 ($.285 rounded up to $0.29 + $0.30).

And for PayPal, a $1 pledge payment would have a fee of $0.10 ($.05 + $0.05) and a $15 pledge payment would have a fee of $0.80 ($.75 + $0.05).

You can see that under both these fee structures the lower the dollar amount of the pledge, the greater effective percentage (of the pledge) the fee is, with PayPal being the better deal for very small pledges like $1.

The payment processing rates imposed by Patreon are rather standard across the industry. Processing very small payments is relatively expensive pretty much no matter who use use. Though, some platform are able to negotiate better rates for micro-payments, depending on their circumstances.

Ah, but, Patreon has been offsetting the true cost of these micro-payments through batching. Currently, until the new pricing policy goes into effect later this month, patrons supporting multiple creators are currently being charged once for all of their pledges, regardless of how many creators those pledges go to. Because they are charged once, a payment processing fee is assessed just once rather than per pledge.

So, a patron supporting 10 creators with a $1 pledge each is charged $10 at once and the associated payment processing fee is $0.49 for Stripe ($0.19 + $0.30) and $0.55 for PayPal ($0.50 + $0.05). That payment processing fee is then split among those 10 creators, with each of them being assessed $0.049 each for Stripe and $0.055 for PayPal (or perhaps $0.05 and $0.06, I don’t know what rounding rules Patreon has been applying). After Patreon takes their 5% platform fee, each creator would realize $0.89 or $0.90 of that $1 pledge in their Patreon balance.

There is one exception to this batching under the current fee structure, and that is for creators who have the charge-up-front (CUF) feature available to them and enabled. With charge-up-front, the patron is charged their pledge amount right when the make the pledge and a payment processing fee is assess on that lone payment. After the initial CUF payment, the patron is charged on the first of the month, with all their pledges to creators batched and processed as one payment.

Patreon’s new fee structure

Patreon’s new fee structure, according to their announcement and documentation, only makes changes to the way fees are assessed on pledge payment processing (#2 from the list above). But the changes are rather significant, particularly for those patrons and creators related through low-dollar pledges.

Here’s what’s changing about the way pledge payment processing fees are assessed:

  1. There is now one fee structure for payments processed via Stripe or PayPal and it’s 2.9% + $0.35.
  2. The patron not the creator will be assessed the payment processing fee.
  3. Pledge payments are no longer batched. They will be processed individually, each incurring a separate processing fee.
  4. You can no longer use your Patreon balance to make pledge payments to avoid the per-pledge processing fee.

(That last item #4 is not made clear in any of Patreon’s announcements, but it’s been confirmed by Patreon staff. Update 8-Dec-17 16:02 PST: I just noticed the Patreon rep said this is “likely” which isn’t the same as definite, but nevertheless I think it will come to pass.)

There are two main reasons so many folks are upset about this new fee structure: a) It gives creators no option to absorb the cost of the payment processing, which many of them would prefer to do, and b) it makes low-dollar pledges much more expensive compared to the old fee structure.

How much more expensive? If you’re a patron supporting supporting 10 creators with a $1 pledge each you will now be charged $0.38 for each of those 10 pledges, bringing  your total monthly spend to $13.80. This is a 31-32% increase from the old fee structure where your monthly spend would have been $10.48 for Stripe and $10.55 for PayPal.

(Patrons subject to VAT will incur an even highly monthly cost.)

Creators, on the other hand, will realize $0.95 of each of those $1 pledges in their Patreon balances because now only the Patreon platform fee of 5% will be taken from their share.

Why did they do it?

The main reasons Patreon gives for the change in their announcement is to provide creators with a predictable, stable monthly income, and to allow creators to take home as much of their earnings as possible.

In order to do this, they explain, they need to move from processing pledges on a fixed, 1st of the month, monthly schedule, to processing payments still monthly, but on the anniversary of when the pledge was first made.

Here are the two diagrams they provided to illustrate this:

Okay, I can follow Patreon’s thinking here. But there is an issue I think they are specifically not speaking to here.

Implied in Patreon’s reasoning and in the diagrams above is a move away from the concept of stored value, of an internal Patreon ledger than can be used to redistribute money amongst patrons and creators.

At this point you’re probably asking, “Christie, what are you talking about, isn’t the whole point of Patreon to “redistribute money” from patrons to creators?” Well, yes, it is. But the phrases stored value and redistribute money have specific meaning and consequences in the financial regulatory world. Business engaging in certain kinds of activities are considered Money Services Businesses (MSBs) and are subject to additional laws and regulations. PayPal and Stripe are money services business. Kickstarter and IndieGoGo are not. In the United States, MSBs are required to register with the Dept of the Treasury and are overseen by the Financial Crimes Enforcement Network (FinCEN). One type of MSB is a money transmitter and I believe this is specifically what Patreon is trying to avoid having to be classified as (and therefore subject to additional cost and regulation).

Here I’m going to stop and express my gratitude and appreciation for the folks at Gratipay. Without their commitment to transparency and communication about how their business work(s/ed) I likely would not know any of what I’m about to explain. Thank you!

As soon as I realized that Patreon’s changes included unbatching payments, I recalled the issue Gratipay encountered when they were shopping for a new payment processor. They had trouble finding a payment processor that would work with them under their existing business model because they looked too much like a money transmitter:

The crux of the problem is the stored value: holding funds in a balance that can then be redistributed, in our opinion, qualifies as money transmission, which we cannot support.

Gratipay wrote extensively about this issue, so if you’re curious to learn more, start with this blog post and follow the links from there.

In the case of Patreon, both batching of pledge payments from one patron to multiple creators and the use of your Patreon balance to pay pledges without processing an external payment requires “holding funds in a balance that can then be redistributed.”

So, that’s what I think is going on here. Now, I’m not an expert in this area and I’m not familiar enough with the regulations regarding financial businesses to assert my theory with 100% confidence, so take what I say with a grain of salt. (If you are knowledgeable in this area and have insight you’re willing to share, please get in touch!) But this explanation makes more sense to me than most others I’ve heard. And, it’s quite common for venture-backed startups to operate in a regulatory grey-area (intentionally or not) in order to build an audience and then get to a point where they either need to change the regulations (what Uber is trying to do) or come in line with them. It’s the latter point I think Patreon has come to.

What Patreon should have done

I think Patreon probably made the right call for their business with regard to the move away from stored value via the unbatching of pledge payments. I can’t say for certain if they made the right decision to put the burden of the additional payment processing on patrons and to deprioritize patron-creator relationships built upon small pledges. That’s their call, unfortunately. (See this post for details indicating it was very much a deliberate choice to prioritize larger pledges and lucrative creators.)

Could they have negotiated with their payment processors to offer a better rate for small transactions? Maybe. Kickstarter offers 5% + $0.05 for pledges $10 or less. But then again, Kickstarter doesn’t offer PayPal and Patreon does. That kind of rate negotiation may not be possible without an exclusive arrangement or other circumstances that don’t apply to Patreon.

You could argue that Patreon’s true mistake was in subsidizing the true cost of micro-payments with a business model they couldn’t (or were unwilling) to sustain in the long-term. People flocked to Patreon because no one else was offering this model and it turns out there’s a reason for that.

That’s why I think, given how banks and credit card associations work, it will be hard for folks to find an alternative to Patreon that offers the exact same features to brought them to the platform. Drip, a competing platform from Kickstarter currently in private beta, might be able to offer a better rate on micro-payments, especially since Kickstarter does. But if you were relying on the availability of PayPal, Drip isn’t going to work for you without compromise.

Further reading

My friend and colleague Audrey wrote her own take on Patreon, more from the point of view of creator. Check it out and let me know if you’ve come across other points of view you appreciated and I’ll update the post with them.

A product development epiphany

At the beginning of the year, I announced Authentic Engine, my new consultancy.

I’m going to share a rather honest update about how things are going, and I plan to do so with some regularity. This gives me some trepidation. Visibility nearly always makes me feel vulnerable, even if the attention is subjectively positive. And general business wisdom favors secrecy and possessiveness above transparency and sharing. Instead, I’m making a deliberate choice to muster courage to favor intimacy (which requires vulnerability) and community.

Perhaps some of you reading are potential clients or customers and in reading about my uncertainties and missteps you’ll decide not to work with me. I’m okay with that, for if my writing here turns you off then we were never going to be a good match. What’s gained, I believe, will be far greater than whatever’s lost. Some will be enriched reading about my experience. Others will appreciate my candor and that I’m willing to do the scary work of making mistakes, sharing those mistakes, and trying again. Some of you will be motivated to work with me explicitly because of this writing.

So here goes it!

A raison d’etre

While I have a great deal of open source tech experience (my first tech job was in 1997 at UC Davis’ network operations center), I have almost no experience consulting in the way I’ve set out to do now. I’ve worked at start-ups and well-established companies. I’ve started and ran non-profits. I ran my own programming shop under CK Web Development. All those experiences have been immensely valuable, but my experience with them has limited applicability to what I want to build now.

I’ve gravitated towards consulting because I want to apply my experience as a programmer, a technical project manager, a developer advocate / technical evangelist, a non-profit manager, a small business person, and an open source community organizer to help folks working in those fields have better work experiences.

By better work experiences, I mean a few things:

  • authenticity, presence, mindfulness, and empathy in day-to-day work;
  • empowered, adaptive leadership;
  • effective navigation of organizational life; and,
  • the building of meaningful and fulfilling careers without burning out.

This isn’t just about making people feel better at work. Whatever your current role in tech, these are practices which will make you better at your job. The production of software, the governing of open source projects, the evangelizing of technology all requires building and maintaining relationships with people. The better your people skills, the better you can effectively apply your technical skills.

By focusing my work on individuals, I intend to contribute to a cumulative effect of improving our technical and open source communities. The more the folks that make up our communities practice and cultivate the above “people” skills, the more inclusive, sustainable, resilient, and commons-serving they will be.

So that’s my raison d’etre for starting Authentic Engine, but how am I actually going to make a living?

What appeals to me about “consulting”

Before I announced Authentic Engine, I did a lot of reading on what it mean to be a consultant and how to run a consulting practice. Some things I read resonated with me deeply: consulting as a calling, humble inquiry, being a trusted adviser, process consultation and the helping relationship. Other things I couldn’t connect with at all, especially the nature of the marketing and sales processes many consulting business books (such as this one) espouse. I don’t want to have a ton of annoying pop-ups soliciting your email for watered-down content, or resell someone’s proprietary organizational trait assessment. Moreover, many books are scant on details about how to actually develop customers if you don’t already have a base established.

Finally it occurred to me to start thinking in terms of answering the question, “what is my product?” The consulting books say you are your product. Okay, I get that to an extent. But it doesn’t feel very sustainable or scalable to me. Nor does it have the depth of experience I want Authentic Engine to bring to others. I want many teachers, and coaches, and trusted advisers, with all their varied histories, experiences and backgrounds to inform and create what we bring to others.

If I am not my product, what is?

So now that I’ve rejected that I am my product, I have to find out what is. That has me researching and learning all about product development. Working in technology as a programmer, project manager, and developer advocate means that I’ve been on the periphery of product management and development most of my career. Now I’m embracing the role officially, which means learning and practicing a new way of thinking.

I’m in the middle of Steve Blank’s The Four Steps to the Epiphany, which focuses on a kind of lean product development for startups that Blank calls Customer Development. So far the framework is making a lot of sense to me. It centers upon developing a deep understanding of your customer and their needs and using that to inform your product development.

Learning deeply from my customers

So that’s what I’ll be doing next. I’ll be thinking about my customers — starting with folks who hold the jobs I’ve had before: technical evangelists (aka developer advocates) and their managers, software developer and their managers, technical product marketing managers (which I’ve worked for, producing events), and open source project stewards.

Actually I’ll be doing more than just thinking about them. I’ll be reaching out to as many of them–as many of you–as possible to listen and learn what their pain points are, what those pain points are costing them, and how they’d like to solve them. I’ll use this information to validate and improve my hypotheses about the Authentic Engine products that will help them.

Exciting and scary

I’m finding this approach very exciting. I love connecting with people, learning about them, building connections, and figuring out ways . But it’s also terrifying because I know this will take time and our financial reserves are dwindling. While I’m developing my customers and products, I’m also going to have to find income, either through consulting or contracting.

How you can help

So, if you or someone you know is needing help with planning a community-focused technical event (like Open Source Bridge, which I co-chaired for 5 years), or managing a technical project (like creating a localization platform for Firefox OS App developers, which I did at Mozilla), or revitalizing a community contributor platform (like I did with MozillaWiki), or improving open source governance (Stumptown Syndicate), or anything else about which I have subject area expertise, please get in touch or book a meeting.

A promise to continue sharing and connecting

Meanwhile, I’ll keep sharing here what I’m working on and what I’m learning.

Soon I’ll post about:

  • realizing I need to be talking to lots more people and how I’m following through on that despite how weird and shameful it can feel;
  • what I’ve learned about content-based marketing and how I’m putting it into practice;
  • how Sherri and I are figuring how how to support one another and keep our household functional while we both build new businesses;
  • what I’m doing to manage my workload, replenish my “spoons,” and avoid burn-out; and,
  • learning to be okay with uncertainty, imperfection, and iterative improvement.

Keeping in touch

As I intimated above, I promise to make more, better connections with all of you. And I invite you to do the same. Leave a comment below, send me an email, or a tweet, or give me a call (go to authenticengine.com for phone number).