by Dragon Core 1 (0 reviews)

Dragon Checkout Guard - PCI DSS Compliance & Card Skimming Detection for WooCommerce

Name: Dragon Checkout Guard - PCI DSS Compliance & Card Skimming Detection for WooCommerce
Author: Dragon Core

Payment-page script inventory, authorisation record, weekly tamper check and header baseline: PCI DSS 6.4.3 / 11.6.1 and SAQ A evidence. No account.

Dragon Checkout Guard ranks #63,006 among WordPress.org plugins with 1+ active installations, is #6,923 of 12,676 in the E-commerce category, a 1/5 rating from 0 reviews, and was last updated Sep 25, 2026. Data from WordPress.org, refreshed twice daily — see methodology.

Compatible with WP 7.1

v1.0.8 Current Version v1.0.8

Updated 23 hours ago Last Update on 25 Sep, 2026

Refreshed 11 hours ago Last Refreshed on

#6,923 of 12,676 in E-commerce Actively maintained

View on WordPress.org

Rank

#63,006

— No change

Active Installs

— No change

KW Avg Position

— No change

Downloads

+60 today

Support Resolved

— No change

Rating

20%

Review 1 out of 5

1 (0 reviews)

Next Milestone 10

Total Progress 20%

0+ 10+

50,069

Ranks to Climb

Growth Needed

8,000,000

Active Installs

Pro

Unlock Exact Install Count

See the precise estimated active installs for this plugin, calculated from real-time ranking data.

Exact install estimates within tiers
Track install growth over time
Milestone progress predictions

Upgrade to Pro

Need 8 more installs to reach 10+

Rank Changes

Current #63,006

Change

Best #

Upgrade to Pro

Unlock 30-day and 90-day rank history charts with a Pro subscription.

Upgrade Now

Active Installs Growth

Upgrade to Pro

Active Installs 0,000,000+

Growth +0.0%

Peak 0,000,000

Downloads Growth

Downloads

Growth

Peak

Upgrade to Pro

Unlock 30-day, 90-day, and yearly download history charts with a Pro subscription.

Upgrade Now

Reviews & Ratings

1.0

0 reviews

Overall 20%

0 (0%)

Track This Plugin

Get detailed analytics, keyword tracking, and position alerts delivered to your inbox.

Start Tracking Free

Plugin Details

Version: 1.0.8
Last Updated: Sep 25, 2026
Requires WP: 6.5+
Tested Up To: 7.1
PHP Version: 8.0 or higher
Author: Dragon Core

Support & Rating

Rating: ★ ☆ ☆ ☆ ☆ 1
Reviews: 0
Support Threads: 0
Resolved: 0%

Keywords

card skimming checkout security payment page pci-dss woocommerce

Upgrade to Pro

Unlock keyword rankings, search positions, and detailed analytics with a Pro subscription.

Upgrade Now

Similar Plugins

Adminify – White Label, Admin Menu Editor, Login Customizer

6K+ installs

#2,757

Master Addons for Elementor – Elementor Addons, Widgets, Mega Menu Builder, Popup Builder, Widget Builder & Template Kits

MonsterInsights - Google Analytics Dashboard for WordPress (Website Stats Made Easy)

Google for WooCommerce

800K+ installs

#75

WooPayments: Integrated WooCommerce Payments

800K+ installs

#76

WooCommerce PayPal Payments

800K+ installs

#81

WooCommerce Stripe Payment Gateway

700K+ installs

#85

WooCommerce Tax (formerly WooCommerce Shipping & Tax)

500K+ installs

#116

View all Ecommerce plugins

Frequently Asked Questions

Common questions about Dragon Checkout Guard - PCI DSS Compliance & Card Skimming Detection for WooCommerce

No. Dragon Checkout Guard produces evidence supporting your own PCI DSS 4.0.1 requirement 6.4.3 / 11.6.1 assessment. It is not a certification and does not, on its own, make a site compliant: your assessor still makes that determination.

It covers the page the iframe sits in, which is the page that matters to you. The iframe document belongs to your provider and is covered by the provider's own PCI DSS validation. Your own page is what an injected script gets access to, and since 31 March 2025 an iframe merchant keeps SAQ A eligibility by confirming that page is not susceptible to attacks from scripts. PCI SSC FAQ 1588 accepts two confirmations: techniques such as those in 6.4.3 and 11.6.1 applied by you to your own page, or written confirmation from your PCI DSS validated provider that its embedded form includes script attack protections

confirmation, so most merchants take the first route, and this plugin's inventory, authorisation record and weekly check is that route's evidence. If your payment page's own scripts can touch card data, you are on SAQ A-EP or SAQ D and 6.4.3 and 11.6.1 apply in full: the same records are what those requirements ask for. If your customer is redirected to the provider's own page to pay, the criterion does not apply to you, though assessors still commonly expect the page that starts the payment to be monitored. Confirm your SAQ eligibility with your acquirer or QSA: this plugin does not determine it for you. The Assessment guide tab walks the same three questions and shows

Two documents and their history. The inventory CSV has one row per script with: script, type, party, pages, source, provider, owner, business purpose, justification, status, changed since authorised, authorised by, authorised at, integrity method, current hash, last checked, review due, first seen, last seen and, where a hash could not be taken, why not. The 11.6.1 check record CSV has one row per check that ran: checked at, trigger, pages checked, scripts checked, new scripts, changes detected, outstanding changes, headers outstanding, the outcome (no change; changes recorded for scripts, for security headers, or for both; or incomplete when a page could not be read), pages read, the pages not read and why, and script hashes verified. A response header this check found added, removed or changed makes the outcome a change, not "no change". "Print evidence report" renders both, with your assessment guide answers and the header baselines, as a printable "Payment page script integrity record". The same data is available from WP-CLI: wp dragon-checkout-guard export --type=inventory|evidence --format=csv|json.

Other WordPress plugins inventory the scripts your site's own code enqueues, from the server. Dragon Checkout Guard does that too, and then goes further: it can observe what actually ran in a real shopper's browser (which is where a tag manager's injected script first appears), it baselines and diffs the payment pages' response headers, it records an authorisation taxonomy per script (owner, purpose, justification, integrity method) rather than a bare list, it exports assessor-ready records, and it is fully driveable from WP-CLI.

Nothing in this plugin is locked, limited or greyed out, and there is no limit on how many scripts or pageviews it records. An optional paid add-on, Dragon Checkout Guard Pro, adds an evidence ledger, alerts and a review queue; this plugin is complete without it. The plugin does apply operational limits so it stays cheap on a live store: see the next answer.

Passive capture interval. A real shopper's pageview is sampled at most once per page per interval (a setting, in minutes, default 10), and that sampling reads the script registry rather than buffering the page. A pageview that shows the admin bar is not sampled. Scans and Open & capture always run, and those do buffer the response; an Open & capture leaves the admin bar's own scripts out, since no shopper

Response capture cap. A buffered response (a scan or an Open & capture, never a passive pageview) is copied up to 5 MB (Server_Capture::MAX_BUFFER_BYTES); a larger page is passed through untouched and that capture is recorded as failed rather than partial. Remote hashing. Only https script URLs are fetched. At most 200 remote fetches per UTC day. After 3 failures a host is backed off for 1 hour. A response over 2 MB is not hashed. Every script that could not be hashed says

private address, host temporarily backed off, daily budget exhausted, fetch failed, response too large, local file not found, unsupported file type). Stale scripts. A script not seen on any page for 30 days stops being refetched and shows "Not seen recently". Browser collector. 30 reports per minute per address (IPv6 grouped by /64), 300 rows and 64 KB per report. 500 new observations in an hour, or 5000 unconfirmed in total, pause the collector for an hour and raise an admin notice; you can bulk dismiss observations from the Inventory tab or with wp dragon-checkout-guard dismiss. If the table reaches 4000 rows in total, the daily maintenance deletes the most recent unconfirmed observations - up to the number needed to bring the table down to 2500 - and records how many it took, so a flood cannot keep the collector shut off for 30 days. Confirmed observations are never deleted, so a table held up by confirmed rows is left as it is; a real script is reported again by the next shopper's browser. Retention. Unconfirmed browser observations are pruned after 30 days. Event retention is a setting between 30 and 3650 days (default 365) and prunes only the low-value kinds: discovered, scan run, scan failed, collector tripped and settings changed. Everything else, including the evidence, authorised, revoked, changed, confirmed, headers changed, baseline accepted and browser observations cleared events, is kept regardless of the setting, because that is the record. Exports. Exports carry at most 5000 rows and say so when they stop short. One scan at a time. A lock stops the weekly cron, Scan now and WP-CLI overlapping. If the plugin's tables could not be created on activation, an admin notice says so and the install is retried automatically.

Stripe, Stripe Radar, PayPal, Braintree, Adyen, Klarna, Mollie, Square, Google Pay, Apple Pay and WooPayments are recognised as payment or fraud scripts, and WooCommerce's own front-end scripts are recognised as WordPress store code, each with a suggested justification you can apply with one click. Google Tag Manager, Google Analytics, Meta Pixel, Hotjar, Intercom, Zendesk, LiveChat and ThreatMetrix are recognised too, and carry a reviewer note: a tag manager can pull further scripts onto a payment page, a chat widget is third-party code on a page you are attesting for, and session recording on a payment page records keystrokes unless it is masked or excluded. Anything unrecognised is listed plainly for you to justify or remove. A script is recognised by the host it is served from, by the plugin folder directly under your site's plugins directory that it is served from, or by the handle WordPress itself registered it under, as recorded by the plugin's server-side capture. A handle that only appears in the page's markup (an element id such as stripe-js-extra, or an importmap name) or in a shopper's browser is never used, since anything injected into the page could claim one.