Requires the free Dragon Checkout Guard. Pro turns its detection into the operational record an assessor asks for under PCI DSS 4.0.1 requirements 6.4.3 and 11.6.1: a named owner, acknowledged alerts, a documented check cadence and a tamper-evident history. It does not certify anything and does not decide your SAQ eligibility; it produces evidence supporting your own assessment.
Licence
Enter your licence key on the plugin's Licence tab (keys are in your dragoncore.ltd dashboard). The licence is sold annually by site count (1, 5 or unlimited sites); keys are stored encrypted, and you can deactivate a site from the same screen to move an activation within your tier. Updates are delivered automatically to licensed sites. If the licence lapses, the plugin keeps working with every Pro feature on each activated site; what stops is new versions, downloads and support, and renewing restores all three on the same key. Renewal reminders arrive by email about two weeks before the period ends. Every Pro tab is visible even when unlicensed; an unlicensed tab shows a notice linking back to Licence rather than being hidden or greyed out.
Monitoring cadence and risk analysis
The Monitoring tab shows the current check schedule (weekly, daily, twice
daily or every six hours), the last completed check, the next scheduled run,
and any misses in the last 90 days. Weekly is the free plugin's own default
and needs no further justification. A gap since the last completed check
that exceeds 1.5 times the chosen interval writes a missed_check ledger
entry (once per gap) and can raise the missed_check alert.
A 52-week coverage calendar shows one cell per ISO week: filled when at least one check completed in that week, empty otherwise, and blank before the plugin was installed. It is printed in both the Monitoring tab and the evidence pack.
PCI DSS 11.6.1 allows a cadence other than weekly only when a targeted risk
analysis under 12.3.1 supports it, and an assessor rejects a risk analysis
that just restates "weekly". The Monitoring tab includes a guided form: the
in-scope pages (prefilled from your Pages settings), the threat being
assessed (prefilled, editable), the factors you weighed (number of
third-party scripts, change frequency observed, payment integration type,
traffic volume, previous incidents, staff who can add tags), the chosen
frequency (it must match the schedule you actually run), a written
rationale (at least 20 characters), a reviewer name, and a review-due date
(defaults to 12 months out). Saving writes a tra_saved ledger entry and
the analysis is printed in the evidence pack under "Assessment context". A
schedule other than weekly with no saved analysis shows a standing notice
on the Monitoring tab until one is saved.
Review queue
The Review tab lists, in one place:
- scripts newly discovered at the server or admin tier,
- scripts whose content hash or inline fingerprint has changed,
- header baselines flagged as changed.
Each item shows what changed (old and new hash or fingerprint, the pages involved, first and last seen), a recognised-provider suggestion where one matches, and the available actions: Approve a changed script (carries forward its existing justification, requires a reviewer note, re-authorises it and clears the changed flag), Authorise a new script (opens the free authorisation form, prefilled), Acknowledge any item without changing its status (records who saw it and why), or Revoke. Header diffs link through to the free plugin's "Accept baseline" action.
When a plugin, theme or core component updates, Pro records it. If a
queue item's script is attributed to that same plugin, theme or core and
the update happened within the 24 hours before the drift was recorded, the
item shows "Likely explained: <name> updated to <version> at
<time>" and offers "Approve as vendor update", which pre-fills the
reviewer note. Authorised scripts past their review-due date appear at the
bottom of the queue with a "Re-review" action.
Alerts
Three channels: email (one or more recipients), a signed webhook (HTTPS
only, the destination host must resolve to a public address), and Slack
(the URL's host must be hooks.slack.com). Every alert carries a required
owner: a name and role you set once, printed on every alert and in the
evidence pack, so the record shows who is accountable for responding.
Triggers, each switched on or off independently: new_script,
script_changed, headers_changed, check_failed, collector_tripped,
missed_check, and review_overdue (an authorised script past its review
date; evaluated daily, at most one alert per script per 7 days).
Two delivery modes: immediate, sent as soon as the trigger fires, or daily digest, one message a day listing everything since the previous digest. Immediate mode throttles each trigger-channel pair to at most one message per 15 minutes; anything suppressed by the throttle rolls into the next message rather than being dropped.
Every send, delivered or not, writes an alert_sent ledger row recording
the channel, the trigger, how many items it covered and the outcome
(sent or failed:<reason>); the Alerts tab lists the last 50. "Send test
alert" posts to every configured channel and writes an alert_test ledger
row, so the pack can show a channel actually worked on a given date.
Webhook signature
Before any webhook or Slack request is sent, the destination host is
resolved and every address it answers with is checked: a host that resolves
to a private, loopback, link-local, carrier-grade NAT or reserved address is
refused. IPv6-only webhook destinations need the PHP dns_get_record
function; on hosts where it is disabled, only IPv4 destinations can be
reached.
A webhook request carries two headers:
X-DragonCheckoutGuard-Signature:sha256=<hex hmac>X-DragonCheckoutGuard-Timestamp: the Unix timestamp the request was sent
The signed string is <timestamp>.<raw request body>, HMAC-SHA256 with your
webhook secret (shown once when generated, regenerable from the Alerts
tab). A receiver should reject a request whose timestamp is more than 300
seconds from its own clock, then recompute the signature and compare it
with a constant-time comparison. This is the same scheme used by Dragon
Webhook Manager, so a receiver already built for it needs no new code.
function dcgp_verify_alert_signature( string $body, string $signature, string $timestamp, string $secret, int $tolerance = 300 ): bool {
if ( abs( time() - (int) $timestamp ) > $tolerance ) {
return false;
}
$expected = 'sha256=' . hash_hmac( 'sha256', (int) $timestamp . '.' . $body, $secret );
return hash_equals( $expected, $signature );
}Evidence ledger
Every listened-to event writes exactly one row to the dcgp_ledger table:
discoveries, changes, header drift, authorisations, revocations, checks and
check failures, updates, acknowledgements, approvals, alert sends and
tests, missed checks, saved risk analyses, provider updates, settings
changes and pack generation.
Each row is chained to the one before it:
hash = sha256( prev_hash . id . kind . payload . created_at ), with the
first row's prev_hash as an empty string. Sealing happens inline as each
row is inserted, inside a short MySQL advisory lock so concurrent writers
cannot race the chain; a row that could not be sealed immediately is picked
up and sealed by the next writer or by the daily maintenance task. The
Evidence tab shows the chain's verification result, checked in batches of
1,000 rows, and never reports a chain as valid when zero rows were checked.
Ledger rows are never pruned. Payloads carry only redacted values the free
plugin already exposes (a display source, hashes, counts, labels); never a
raw script src, an inline preview, an IP address, a secret or a webhook
URL.
Export the ledger to CSV from the Evidence tab or with WP-CLI. The CSV
columns are: id, created_at, kind, ref, user, summary,
payload, prev_hash, hash. payload is the stored JSON exactly as it
sits on the row, so those columns are everything the hash covers and a
reader can recompute the whole chain outside WordPress. The WP-CLI table
and json formats stay summary-only; --format=csv carries the payload.
wp dragon-checkout-guard-pro verify
wp dragon-checkout-guard-pro ledger --kind=alert_sent --limit=20
wp dragon-checkout-guard-pro ledger --since="2026-01-01" --format=csv > ledger.csvProvider confirmations
PCI SSC FAQ 1588 route 2 is written confirmation from a payment provider
that its embedded form includes script attack protections; not every
provider issues one. The Evidence tab tracks, per provider (prefilled from
providers already matched in your inventory, plus free-text additions): a
status (not_requested, requested, received, not_available), the
date requested and received, a reference (a document title or ticket
number), an optional link, a contact, notes, and a review-due date
(defaults to 12 months from the received date). Every change writes a
provider_updated ledger row, and the current confirmations are printed in
the evidence pack under "Assessment context" next to your SAQ route.
Evidence pack
A printable HTML record, opened from the Evidence tab for a period of 30,
90 or 365 days (use your browser's Print to PDF to save a copy). It
covers, in order: a cover page (your brand name and logo, site, period,
generated-at and generated-by, alert owner); the scope statement (in-scope
pages, SAQ route, risk-analysis summary, provider confirmations); the
monitoring cadence and coverage calendar for the period; the script
inventory; the check record; review activity (approvals, acknowledgements,
authorisations, revocations, each with reviewer and note); alert
deliveries and tests; header baselines; the ledger's integrity result (row
count, first and last hash); and the same non-certification footer the
free plugin's own report uses. Generating a pack writes a pack_generated
ledger row, so the pack itself is part of the chain.
Set Pack reminder to monthly or quarterly to have the alert owner
emailed a short summary (checks run, drift recorded, open review items,
chain status) with a link to the Evidence tab. An optional SAQ due
date adds a reminder 30 days before and on the day itself.
Site Health and WP-CLI
Site Health includes a dcgp_schedule test: recommended when the gap since
the last completed check exceeds 1.5 times your chosen interval, good
otherwise.
wp dragon-checkout-guard-pro verify
wp dragon-checkout-guard-pro ledger [--kind=<kind>] [--since=<date>] [--limit=<n>] [--format=table|json|csv]
wp dragon-checkout-guard-pro checkverify and ledger only read and work without a licence. check runs a
check now (trigger cli) and needs a valid licence, the same as any other
Pro write.
Uninstall
Deleting the plugin keeps all its data by default, so a reinstall picks up where you left off. To remove everything (the evidence ledger table, all options and scheduled tasks) on uninstall, opt in first:
wp option update dcgp_delete_data_on_uninstall 1