Observe
Check the HTTP response and expected final page, then record scripts and selected security-impacting headers. Configure a visible readiness marker for the intended page.
GitHub-native · release-scoped · client-owned
Know what changed at checkout before your next release.
Record browser-observed checkout scripts and selected security-impacting headers, compare them with an approved baseline, and preserve the result inside the caller’s own GitHub workflow.
Release evidence—not PCI certification, a payment-success guarantee or continuous attack protection.
Acceptance sequence
v0.4.1Unchanged checkoutPASS
Controlled script changeREVIEW_REQUIRED
RollbackPASS
Illustrative sequence. Capture errors stop the check; they cannot produce PASS. Evidence remains in the caller’s workflow artifacts.
Public proof is maintained by the product creator. It is not customer validation, an independent audit or vendor endorsement. See each linked run for its exact revision and result.
The release record a source diff cannot provide
Observe the checkout the browser actually receives.
Source and QA records remain useful, but they do not necessarily preserve the exact browser-served script and selected-header state delivered during a release. This adds that narrow evidence layer without pretending to be continuous security monitoring.
Compare
Compare the browser observation with a previously reviewed baseline and approval records.
Decide
Return PASS or REVIEW_REQUIRED without labelling every difference malicious or insecure.
Preserve
Keep the passport, comparison, snapshot and readable report inside the caller’s GitHub workflow.
Tight data boundary
Useful evidence without collecting checkout secrets.
Passive GET navigation only. No form submission. Script contents are fingerprinted; complete script bodies are not retained.
- No cardholder or customer data
- No credentials, cookies, or form values
- No URL query values or response bodies
- No complete script source stored
Founding agency offer
Start with a small acceptance-based evidence pack.
The Action remains free to self-install. Paid work covers scoped configuration, controlled acceptance, evidence verification, and handover.
Agency Evidence PackFirst step
$250 USD · fixed scope
One agency-owned staging or demo workflow. Three business days begin after written scope, authorised access and required inputs are complete.
- One agency-owned GitHub repository
- One authorised staging or demo checkout
- Unchanged checkout → PASS
- Controlled repository-owned change → REVIEW_REQUIRED
- Rollback → PASS
- JSON passport, comparison, snapshot and readable HTML report
- Caller repository, commit, workflow, run and Action provenance
Payable only after the agreed sequence works.The full $250 is credited toward the first $750 installation.
Founding InstallationImplementation
$750 USD · total fixed scope
Move the accepted evidence workflow into the agreed client implementation.
- Final GitHub Actions workflow configuration
- Reviewed baseline and approval records
- Controlled acceptance-sequence verification
- Evidence and digest verification
- Technical handover documentation
- Access-removal guidance
- 14 days of setup support
Acceptance agreed before work begins.Scope and access boundaries are agreed in writing before work begins.
Best fit
Merchant-controlled checkout releases using GitHub Actions.
For agencies and merchant teams with an authorised staging checkout and a GitHub repository. Platform suitability is checked against your actual page and access constraints before a scope is agreed.
Not a fit
Unauthorised testing or a request for a compliance guarantee.
Not for third-party checkout scanning, PCI certification, penetration testing, vulnerability assessment, or replacement of continuous monitoring.
Clear boundaries
Questions technical and delivery teams ask.
Does PASS prove that checkout or payment works?
No. PASS applies to the configured page-readiness and script/header evidence checks. It does not prove cart totals, payment processing or order creation. Those outcomes require a separately scoped functional test.
What does the functional demo prove?
The repository contains an owned synthetic cart example. It demonstrates a functional test, not a real payment, a customer deployment or independent validation. A customer-specific functional test requires its own written scope.
How do I upgrade from an older version?
Test the new revision on an authorised staging target. Configure the expected final URL and a suitable readiness marker, review evidence and approvals, and deliberately approve any baseline replacement. Never regenerate a baseline just to obtain PASS. Follow the v0.4.1 release notes.
Does this certify PCI DSS compliance?
No. It provides release-scoped evidence that may support change-management and evidence processes. It does not by itself satisfy PCI DSS Requirements 6.4.3 or 11.6.1, and it is not a QSA assessment.
Does it replace runtime monitoring or blocking?
No. Scheduled evidence checks and optional GitHub review issues support a release workflow. They do not provide continuous runtime protection or block attacks.
Why is this different from a Git diff?
A Git diff describes source changes. The passport records what a controlled browser observed, the baseline comparison, approval status, and GitHub workflow provenance.
Will TransferVerity receive payment or customer data?
No checkout submission is required. Evidence excludes cardholder data, credentials, cookies, form values, query values, response bodies, and complete script bodies.
Request the one-page agency scope
Test the acceptance sequence before committing to an installation.
Send only non-sensitive architecture and staging details. Never email credentials, private URLs, customer data, or card data. You will receive a written fit assessment and scope before access or paid work begins.