Self-hosted forum software that takes payments itself

Most communities that start charging do it for the same reason: the server, the moderators' time or the hosting bill has become real money, and a supporters' tier is the least awkward way to cover it. The question that follows is whether the forum itself should take the payment, or whether it should hand the member off to a shop somewhere else and simply be told the result.

Both work. They are different amounts of work, and the difference does not show up on a feature list.

What "built-in payments" usually means

On a forum platform, a payment feature almost always does one narrow thing: it moves a member into a group when money arrives and moves them out when it stops. Everything a paying member gets — a badge, a private board, no adverts, a larger upload quota — is ordinary group permission. The payment is only the switch.

That matters because it tells you what to compare. Not "does it support payments", but three smaller questions:

• Which processors does it talk to, and does it ship them or depend on an add-on?
• Does it handle recurring billing, including the failed renewal, the cancellation and the refund that should take the group away again?
• Where does the card data go — through your server, or straight to the processor?

The platforms that ship it

XenForo has the most complete version in a commercial forum. User upgrades are part of the core product: you define a paid upgrade, attach it to a user group, and set a price and a duration or recurrence. Since version 2.1 the processors are configured as payment profiles, and PayPal, Stripe and Braintree are among the providers it ships with. A lapsed or refunded subscription removes the group again without anyone touching it, which is the part home-made setups most often get wrong.

Invision Community goes further, because its Commerce application is a small shop rather than an upgrade switch. It sells subscriptions, but also one-off products, downloads and anything else that can carry an invoice, with its own customer records and tax settings. If what you want to sell is more than access, it is the only forum package here that does it without a second system. The trade is weight: there is a good deal more to configure and keep current. The XenForo and Invision comparison covers the licensing side of the same decision.

Simple Machines Forum is the quiet surprise. Paid subscriptions have been in the core since the 2.0 series, built around PayPal. It is basic — group membership for a period, renewed or not — but it is free, it is already installed, and for a small supporters' tier it is often enough.

Discourse does not do it in the core, but the project maintains an official Subscriptions plugin that uses Stripe and grants group membership on payment. On a self-hosted instance it is a plugin you add to the container definition and rebuild, which is a routine operation there rather than a risky one.

The platforms that leave it to extensions

phpBB, MyBB, Flarum and NodeBB ship no payment handling at all. Each has community extensions that add it, and some are good. The question to ask of any of them is not whether it works today but who will update it the next time the processor changes its API, because processors do, and the extension is the part of your forum least likely to have more than one maintainer. Reading the extension's repository before relying on it is worth the ten minutes — when it last changed, how many open issues mention the processor by name.

If the forum is one part of a larger site, the other route is not to make the forum take money at all. A membership system or shop elsewhere handles the payment and tells the forum through single sign-on which groups the member belongs to. That keeps all billing in one place and lets you pick the forum on its merits as a forum, which is how the guide to choosing forum software for a small community suggests weighing it anyway.

Where the card data goes

This is the part that decides how much responsibility you take on, and it is not obvious from the admin panel.

Every platform above can be set up so that the card number never touches your server: the member is sent to the processor's hosted checkout, or the payment form is the processor's own field embedded in your page, and your forum receives only a notification that the payment succeeded. Set up that way, the compliance burden that falls on you under the PCI Data Security Standard is the lightest version there is. Set up any other way — an extension that posts card fields through your own server, for instance — and you are now operating a payment system, with everything that implies for patching, logging and access.

The safe default is simple to state. If a payment add-on asks you to store anything that looks like a card number, find a different add-on.

A side note on Interac

Canadian communities run into a gap here. Many Canadians would rather pay by Interac, the domestic debit network, than by credit card, and Interac e-Transfer in particular is how a lot of small clubs and groups already collect dues. Few of the processors bundled with forum software offer it as an online checkout option, so a forum that wants to accept it usually ends up reconciling transfers by hand and adding members to the paid group manually.

Interac shows up in a very different setting too: anyone who has looked for the best Interac casinos Canada has to offer will have seen it listed as a standard deposit method, because gambling sites adopted it early for exactly the reason forum owners would like it — Canadians trust their bank more than a card form. For readers curious about how it is used there, the National Post's Interac guide walks through how deposits and withdrawals work and what to check before using it. None of that machinery is available to a self-hosted forum, which is why the manual route is still the common one.

How to choose

If you only need a supporters' tier, use what your platform already has: XenForo's user upgrades, SMF's paid subscriptions or the Discourse plugin will all do it with very little to maintain. If you need to sell things rather than access, Invision's Commerce application is the only forum-native answer, and otherwise a separate shop connected by single sign-on is the cleaner design.

Whichever it is, test the unhappy paths before launch rather than after. Pay, then refund, and check that the group is removed. Let a renewal fail, and check the member is not left with access they did not pay for. Those two tests catch most of the problems communities find in their first month of charging. And if the payment lives in an extension, remember the point the Discourse and Flarum comparison makes about both platforms: the extension mechanism decides what happens to a forum three years later, and the add-on you never exercise is the one that will surprise you.