Payload Consent

Payload Consent is a consent management platform that lives inside your Payload admin instead of inside someone else's SaaS. Editors maintain one list of the cookies and scripts the site uses, and the plugin derives from it the three things that normally drift apart:

• the categories and copy in the consent banner,
• which scripts actually load after which decision,
• the "cookies we use" table inside the cookie policy.

A second register does the same for everyone who receives personal data at all — your host, your database, your email sender — and drives the recipients and transfers tables in the privacy policy, your public sub-processor list and your DPA annex.

Every decision is stored as a minimal, immutable consent record, which is the audit trail hosted consent tools sell as a paid tier. Nothing is fetched from a third-party CDN at runtime, so there is no extra vendor in your privacy policy and no consent banner that blocks rendering while it phones home.

Why it is one plugin and not three

A cookie banner is easy. Keeping it honest is not. In most projects the banner lists four categories, the analytics snippet sits hard-coded in the layout, and the cookie policy is a Word document somebody pasted into a CMS two years ago. Adding a chat widget touches none of them, so the banner promises something the site does not do — which is the part regulators actually fine.

Payload Consent removes the drift by making the tracker list the source of truth. Add Intercom in Cookies & scripts, pick its category, list its cookies, and the banner, the loader and the policy table all update from that one document. The version hash of that list is stored in the visitor's consent cookie, so when the list changes in a way you said should matter, the visitor is asked again, automatically.

How it fits together

The provider is given the config and the cookie value read on the server, so the first client render matches the server render exactly: no banner flash, no hydration mismatch, no layout shift.

Packages

Only the plugin is required. If your frontend is not React, install consent-core, fetch the config endpoint and drive the store yourself.

Quick start

pnpm add @payload-solutions/plugin-consent @payload-solutions/consent-react

import { consentPlugin } from '@payload-solutions/plugin-consent'

export default buildConfig({
  plugins: [
    consentPlugin({
      seed: {
        company: {
          name: 'Acme',
          legalName: 'Acme Ltd',
          address: '1 Main Street, Dublin, Ireland',
          email: 'privacy@acme.com',
          url: 'https://acme.com',
          governingLaw: 'Ireland',
        },
        trackers: [{ key: 'ga4', vars: { measurementId: 'G-XXXXXXX' } }, 'stripe'],
        processors: ['vercel', 'neon', 'resend', 'stripe', 'sentry', 'ga4'],
      },
    }),
  ],
})

On first boot the plugin seeds four categories, the trackers and processors you listed, and five legal pages — privacy policy, cookie policy with a live cookie table, terms of service, a public sub-processor list and a DPA. From then on everything is edited in the admin under Privacy.

What you get out of the box

• Four categories (necessary, functional, analytics, marketing) with sensible Google Consent Mode mappings.
• Seventeen tracker presets, with their real cookie names and durations already filled in.
• Jurisdiction detection from CDN country headers, with opt-in for the EEA, UK, Switzerland, Brazil and Canada and opt-out for the US, all overridable.
• Global Privacy Control honoured under opt-out law.
• Google Consent Mode v2 defaults emitted before any Google tag, and updates on every change.
• Re-consent when your categories, trackers or legal documents change, driven by content hashes rather than a version number you have to remember to bump.
• Anonymous consent records with a retention job, and per-user consent history when you want it.
• Twenty-eight processor presets with role, country and transfer basis, feeding the recipients and transfers tables, a public sub-processor page and a DPA annex.
• Five seeded legal documents in Lexical, with tables, that editors can actually edit.
• A legal audit: a deterministic payload-consent scan that checks your documents against your own configuration, and an MCP server your own AI agent drives for the parts only a reader of prose can judge.

Requirements

Any Payload database adapter works; the plugin uses only the local API. Localization is picked up automatically — if your config has localization, the visitor-facing fields become localized.

Status

0.1.0, first public release. On the roadmap: an embed script for non-React sites, a banner preview in the admin, and a scanner CLI that diffs the cookies a page actually sets against the ones you declared.

MIT licensed, part of Payload Solutions.