Payload Enterprise or a focused custom implementation: a buyer's guide by requirement

Payload is the platform we recommend first for large, complex websites, and the licence comes later in that conversation. A larger website does not automatically need an enterprise licence. What decides it is what the organisation needs to publish, control, secure and support, and who keeps each of those working after launch.

This guide takes the five requirements that usually raise the question and compares three routes for each: Payload’s open-source core, a focused custom extension built on it, and the Enterprise package Payload sells. It ends with a worksheet for your own requirements, a sheet for comparing what each route costs to own, and a checklist for the first conversation with Payload or a partner. Payload’s pages and documentation were read on 21 October 2026, when the latest stable release was Payload 3.91.0, published on 15 October, and Payload 4 was in beta.

Where we stand

WAYF is a Payload partner agency, and custom Payload implementation is work we sell. Read the custom-route paragraphs with that in mind. We did not use Payload’s Enterprise features for this guide, so what it says about them comes from Payload’s own pages, dated in the sources.

The three routes

The open-source core. Payload’s licence is the MIT licence. The core has access control in three types, for collections, globals and fields, and Payload’s documentation says the functions run “before any changes are made and before any operations are completed”. Versions add history, comparison and restore. Drafts and autosave build on versions, and drafts can be scheduled to publish through the jobs queue. Hooks run on the server around each operation. Authentication ships with cookie, JWT and API-key strategies, and teams can write their own.

A focused custom extension. Code in your own repository that uses the core’s documented extension points: access functions, hooks, custom authentication strategies and the jobs queue, plus any separately licensed library the work needs. It does one job your organisation needs, and somebody owns it through every Payload upgrade. That owner can be your own team or a partner that runs the platform for you, and either way it is named in writing before the build starts.

Payload Enterprise. Payload’s commercial package. Its get-started page describes Enterprise as adding dedicated support, hosting and features such as single sign-on and visual editing, deployed on your own infrastructure or with Payload. The enterprise page lists single sign-on, Publishing Workflows, AI auto-embedding, A/B variant testing and enterprise AI, with a visual editor and multi-player editing marked as coming soon. Several other cards on that page, among them access control, hooks and the one titled “Audit Logs & Version Control”, link to core documentation. Payload publishes no price and no service-level terms; the route starts with a demo request.

Five requirements, three routes

Read each row as a question about your organisation before it is a question about Payload. “Core” means what ships in the MIT package today, “custom scope” what has to be engineered on top of it, and the last column who carries the work once it is live.

Approvals: the rule has to hold wherever content is written

An approval step covers only the paths that enforce it. Editors use the admin panel, but scripts, importers, integrations and AI assistants usually write through the REST or GraphQL API, which run the access functions for the user attached to the request. Code running inside the application uses the Local API, and in Payload 3 the documentation is explicit: “In the Local API, all Access Control is skipped by default.” Code has to set overrideAccess: false and pass a user to opt back in. Payload 4’s beta reverses that default. Custom endpoints are a fourth path, and Payload’s documentation says they “are not authenticated by default”. A rule enforced only in the admin screen, or only in an access function that trusted code skips, leaves those other paths open.

Three things make a custom approval step dependable:

• Enforcement on the server. Payload’s drafts documentation restricts publishing through update access on the _status field, which also hides the publish buttons and blocks scheduled publish jobs for users who may not publish. A hook can add the approval check itself, because hooks run on the server whatever the access setting. In our tests on Payload 3.90.2 the documented rule, which checks the stored status, let an editor publish a document whose latest version was a draft, so the rule has to check the status in the request.
• Separation of reviewers. Decide whether an author may approve their own change, and whether a reviewer who edits a draft may then approve it. Both are policy decisions, and the code has to record who edited each draft to enforce them.
• Regression tests. Each rule gets a test that fails when the rule is removed, and the suite runs on every Payload upgrade.

Our tested approval workflow for AI-written drafts builds one review step this way: an assistant that can only save drafts, a reviewer, a separate publisher, an append-only log and a tested rollback. It was tested on Payload 3.90.2 over the REST and Local APIs, with 76 tests passing on 8 October 2026. It has one reviewer, one approval step and no notifications, and it does not test the admin panel, GraphQL, localisation or any other Payload version. In that example the reviewer may amend a draft and then approve it, so a policy that forbids that needs the extra check described above.

Several stages add scope quickly. Each stage adds a stored decision, an order, a way to send a draft back, notifications and somewhere in the admin for reviewers to see what waits for them. Payload’s Publishing Workflows page describes multi-step approvals mapped to an organisation’s own process, stages that can reach down to field level through access control, and notifications about pending edits with reminders. It does not document the stages, roles, notification channels or an API, so ask for them in the demo, and price the package against building the stages you need before a build plan assumes either.

Corporate login is engineering and security work

Payload’s documentation, official plugins and examples include no single sign-on integration for OAuth, OpenID Connect or SAML. On the core, the route is a custom authentication strategy, which the documentation calls “an advanced feature, so only attempt this if you are an experienced developer”. A strategy is a function that receives the request and returns a Payload user, or nothing. Everything between the identity provider and that user is an integration your team or partner designs, reviews and maintains. The questions that size it:

• Identity provider and protocol. Which directory you use, such as Microsoft Entra ID, Okta or Google Workspace, and whether it is reached over OpenID Connect or SAML 2.0. The library that speaks the protocol is a separately licensed dependency with its own maintenance record. Community plugins exist; check their licence, their maintainer and the Payload versions they support.
• Sessions. How long a Payload session lasts after the identity provider signs someone in, what happens at logout, and whether a session survives a role change in the directory.
• Deprovisioning. When someone leaves, their access to the CMS has to end. Decide whether accounts are created on first sign-in and how they are disabled, and test what happens to a session issued before the change. API keys need their own step: Payload’s documentation notes that resetting a password “does not disable an existing API key”.
• Access mapping. Which directory groups become which Payload roles, who maintains that mapping, and what a user with no matching group can do.
• Security review. Callback URLs, secrets, token validation and failure handling, reviewed by someone other than the person who wrote them.
• Upgrade maintenance. Authentication sits close to Payload’s internals, so the integration is re-tested on every Payload upgrade and every change at the identity provider.

Payload’s Enterprise single sign-on page describes the feature as working with SAML and OAuth 2.0 identity providers, names Microsoft, Okta and Google, and describes user profiles created on first sign-in with permission mapping. How it is delivered and maintained is not public, so put those questions to Payload. A custom integration can meet a specific login requirement; it carries none of the vendor’s support or assurances, which stay with the package.

Version history is not an audit trail

Payload’s versions keep earlier states of a document, so a page can be compared with or restored to an earlier version. That shows what a page said on a given day. An auditor usually asks for more.

Payload’s versions documentation lists keeping “an audit log / history of every change ever made to a document, including monitoring for what user made which change” among their uses, while the example version on the same page carries no user field. In our tests on Payload 3.90.2, a version held the document data and its timestamps with no field for the user who saved it, and approving or declining a change created no version at all. Payload 4’s beta migration guide says collections will record createdBy and updatedBy by default and that there was no authorship tracking before. Payload keeps 100 versions per document by default and removes the oldest whatever their status, so a retention period has to be set deliberately. Content governance in a headless CMS sets out what evidence to keep for each decision: the actor, the content and version, the decision and the timestamp.

An audit requirement is usually wider than document history. It can cover sign-ins, permission changes, configuration changes and exports, kept for a fixed period where nobody can edit them. Payload has a separate Enterprise audit-logs page describing time-stamped tracking of sign-ins, user actions and configuration changes; the main enterprise page does not link to it, and its “Audit Logs & Version Control” card points to the core versions documentation, so ask which one a quote includes. A custom log on the core can record decisions and actions in the same database transaction as the change, as the tested example does. Ask your auditor or compliance team which events they expect, and for how long, before choosing.

What each route costs to own

The licence is one line. Compare the total cost of ownership of each route over the period you will run it, and leave a line blank until someone has quoted it.

No breakeven applies to every organisation. A focused custom extension suits one or two clear needs that your team or partner can own. Broader governance, several packaged capabilities at once, or a policy that requires a vendor support contract can justify Enterprise even where each need could be built separately.

Building on the core without crossing the licence

A custom route uses the MIT core’s documented extension points, and dependencies under their own licences, each checked like any other procurement item. It does not copy, reconstruct or unlock Payload’s commercial packages, and it does not work around their licensing. Where you build your own answer to a requirement such as sign-in or a review step, Payload’s Enterprise single sign-on and Publishing Workflows remain its commercial products, available to buy later if the requirement grows.

Two illustrative examples

These are composites for illustration, not client cases.

One reviewer, one login provider. A marketing team of twelve editors publishes a corporate site. One reviewer approves every change before it goes live, the company signs in through Google Workspace, and the delivery partner already supports the site. A focused extension covers it: a server-side approval rule with tests, a notification to the reviewer, and an OpenID Connect integration with group-to-role mapping, all maintained by the partner through each upgrade. Nothing on the list needs a vendor contract.

Three stages, a central directory, a support contract. A group runs eight brand sites with brand, legal and regional reviewers in turn, signs everyone in through Microsoft Entra ID, removes leavers centrally, and its procurement policy requires a support agreement with the software vendor. Price Enterprise first. The stages, the sign-in and the support requirement each map to something the package lists, and building all three would leave the group maintaining an approval engine and an identity integration of its own. The brand front ends, role design and integrations remain implementation work under either route.

Requirements worksheet

Copy the table into a document or spreadsheet, keep one row per requirement, add a row for any requirement of your own, and fill every column before comparing routes. A requirement with an empty acceptance check is not ready to price.

Before the first conversation

• List which of the five requirements you need at launch and which can wait a year.
• Name every system that writes content, including scripts, importers, integrations and AI assistants.
• Decide whether an author may approve their own change, and whether a reviewer may edit before approving.
• Write down the identity provider, the protocol, how leavers are removed and which groups become which roles.
• Ask the people who answer to auditors which events they need recorded, and for how long.
• State the support response times you need, and who must answer out of hours.
• Name the owner of each custom extension through Payload upgrades, and the tests that prove it still holds.
• Ask what the Enterprise quote covers, for how many projects and environments, and what changes at renewal.

If you want that list checked against your own content model, we can map each row to the core, a custom extension or the Enterprise package with you; our Payload partnership page sets out how we work. For the permissions side in code, see building field-level RBAC in Payload CMS.

FAQ

1. Does a large website need Payload Enterprise?

   Not because of its size. A larger website does not automatically need an enterprise licence. The licence becomes the better buy when several needs arrive together: approvals with several stages and notifications, single sign-on through a corporate directory, an audit record wider than document history, and support terms the organisation needs in writing from the vendor.

2. Can Payload do single sign-on without Enterprise?

   Yes, as engineering work. The open-source core supports custom authentication strategies, so a team or partner can integrate an identity provider over OpenID Connect or SAML with a separately licensed library. They then own sessions, deprovisioning, role mapping, the security review and re-testing on every upgrade. Payload's packaged single sign-on is part of Enterprise.

3. Is Payload's version history an audit trail?

   Not on its own. In our tests on Payload 3.90.2 a version stored the document and its timestamps with no field for who saved it, and approving a change created no version. Audit requirements usually also cover sign-ins, permission and configuration changes and a retention period. Payload 4's beta adds authorship fields by default, so check what your version records.

Sources

• Payload CMS, release 3.91.0
• Payload CMS, release 4.0.0-beta.3
• Payload CMS, licence
• Payload CMS, access control
• Payload CMS, field-level access control
• Payload CMS, Local API
• Payload CMS, Local API access control
• Payload CMS, REST API and custom endpoints
• Payload CMS, versions
• Payload CMS, drafts and scheduled publishing
• Payload CMS, hooks
• Payload CMS, authentication
• Payload CMS, custom authentication strategies
• Payload CMS, API keys
• Payload CMS, version 4 beta migration guide
• Payload CMS, Enterprise
• Payload CMS, Publishing Workflows
• Payload CMS, single sign-on
• Payload CMS, audit logs
• Payload CMS, get started
• WAYF, Payload CMS approval workflow for AI-written drafts

Sources read 21 October 2026, on Payload’s Version 3 documentation unless marked beta. The two examples are illustrative.