Security
Cartelta JSIR monitoring methodology
A technical view of how payment-page scripts and client-side state are observed, compared with an approved baseline, turned into reviewable events, and connected to customer-owned response and evidence processes.
For security architecture, AppSec, SOC, privacy, engineering, compliance, and assessor teams evaluating JSIR before a pilot or production rollout.
Method at a glance
Observe browser-side page structure, scripts, resource sources, and selected security-relevant headers.
Compare the observed state with a versioned, customer-approved baseline for the payment journey.
Attach page, time, source, baseline, and release context to material deviations.
Route the event into customer-owned triage and retain the resulting evidence trail.
Updated: July 26, 2026
Review basis
This page separates public JSIR capability statements from customer-owned configuration and validation. Confirm collection mode, coverage, frequency, integrations, retention, and data handling in the technical design for the actual deployment.
Defined observation boundary
The monitored journey, states, structural signals, exclusions, and sensitive-data handling are agreed before rollout.
Versioned comparison
Events reference an approved baseline rather than an undocumented assumption about the page.
Explainable evidence
A reviewer can see what changed, where it was observed, which state was expected, and how the owner responded.
Separate the methodology from the deployment design
The methodology describes the control model: observe a defined client-side state, compare it with an approved expectation, add context, route a material deviation, and preserve the decision. It should not be read as a claim that every domain, browser state, attack path, or integration is covered automatically.
The production design must name the observation points, supported journeys and states, collection or navigation mode, expected execution frequency, failure handling, data path, storage location, access roles, notification destinations, and evidence format. These are acceptance criteria for the pilot, not details to postpone until after rollout.
Observation model and scope
JSIR is described publicly as observing the client-side payment-page state from the end-user browser, including DOM scripts and third-party sources, HTML and JavaScript changes, and selected HTTP-header signals. The implementation scope is defined per payment journey rather than inferred from the domain alone.
Before rollout, the customer identifies relevant URLs and states, browser and locale variants, tag-manager behavior, payment-provider dependencies, expected resource origins, and the teams responsible for approving and investigating changes.
Data boundary and sensitive-value handling
The monitoring purpose is structural and integrity analysis, not payment processing. Deployment design must explicitly prevent sensitive payment values and unnecessary customer-specific fields from entering comparison evidence, notifications, or exports.
Exact selectors, masking or exclusion rules, event fields, access controls, transfer paths, and retention are customer-specific implementation decisions. They must be validated in the pilot and reflected in security, privacy, and compliance review before production use.
Baseline approval and comparison
A baseline records the expected page state for a defined journey and variant. It includes the relevant script and resource set, structural signals, selected headers, version, owner, approval, and release context. Baseline updates should follow a controlled decision and preserve prior versions for review.
The comparison focuses on meaningful differences. Known volatile values can be normalized through documented rules, but new script origins, changed executable resources, form behavior, destinations, or security-header changes should remain visible for review.
Coverage is measured by state, not by domain count
A single hostname can contain several materially different payment states. Coverage should report which journey and state was observed, when it was last observed successfully, which signals were evaluated, and which expected variants remain untested.
For multi-step checkout, consent branches, localization, provider errors, authenticated sessions, mobile layouts, and tag-manager conditions, agree a coverage matrix. A green domain-level status must not conceal a page state that the mechanism has never evaluated.
Dynamic content, tuning, and limitations
Consent state, personalization, A/B testing, multi-step checkout, tag-manager timing, CDN behavior, and provider responses can create legitimate variants. Coverage must be tested across the states that matter to the assessed payment journey.
No single monitoring layer observes every attack path. JSIR should complement secure development, third-party governance, CSP/SRI where appropriate, server and repository controls, vulnerability management, and incident response. A missed state, overly broad normalization rule, or unavailable observation path can reduce detection coverage.
Pilot tests and production acceptance
The pilot should include an approved script release, an unknown script origin, changed executable content, a meaningful security-header change, an expected volatile value, an observation failure, and an evidence export. Each test needs an expected result and an owner.
Production acceptance should also confirm that sensitive fields are absent from observations and notifications, routing reaches the agreed roles, previous baseline versions remain reviewable, missed executions are visible, and the exported record can be traced to the source event.
On this page
Approve a monitoring profile before starting the pilot
A monitoring profile makes assumptions explicit. It defines the journeys and states, observed signals, sensitive-data exclusions, normalization rules, baseline owner, routing, and retention reference that the test plan must validate.
Definition of done
A jointly approved profile and test matrix showing what is observed, what is deliberately excluded, which states are covered, how failures surface, who decides, and what evidence is retained.
01
List journeys and page states
Name every state that can change scripts, resource origins, form behavior, or relevant headers; record unsupported or not-yet-tested states explicitly.
02
Select signals and exclusions
Define structural and resource signals while excluding payment values, tokens, cookies, customer identifiers, and unnecessary form content.
03
Approve baseline and tuning rules
Assign an owner to every baseline and normalization rule, with a reason, change reference, review date, and a test proving it does not hide a material change.
04
Define routing and failure behavior
Set recipients, escalation, release-context source, missed-observation handling, and the evidence created for delivery or integration failures.
05
Run acceptance tests
Exercise expected, unexpected, dynamic, failure, privacy, and export scenarios and preserve actual results before production approval.
Example monitoring profile
The profile is intentionally explicit about exclusions and customer-owned decisions. Exact production fields and transport are agreed during technical review.
{
"profile_version": "1.0",
"journey": "checkout-card-entry",
"page_states": [
"default-consent",
"analytics-consent",
"payment-provider-error"
],
"observation_scope": {
"scripts": true,
"resource_origins": true,
"selected_dom_structure": true,
"selected_security_headers": true
},
"sensitive_data_exclusions": [
"payment field values",
"cookies",
"authorization tokens",
"customer identifiers"
],
"baseline": {
"version": "baseline-2026-07-20.2",
"owner": "checkout-platform",
"approval_reference": "CHG-1838"
},
"routing": {
"primary_role": "appsec-on-call",
"escalation_role": "incident-response"
}
}Illustrative JSIR monitoring profile
JSON structure for journeys, states, observation scope, sensitive-data exclusions, tuning ownership, baseline, routing, and retention.
JSON · UTF-8 · implementation aid, not a Cartelta API contract
The example describes a review structure, not guaranteed product defaults. Validate the implemented observation path, frequency, availability, data flow, and integrations in the customer's environment.
Event and evidence lifecycle
The customer remains the decision owner throughout the lifecycle.
01
Observe
Capture configured structural and resource signals in the scoped journey.
02
Compare
Evaluate the observation against the applicable approved baseline.
03
Contextualize
Attach journey, time, source, baseline version, and known release context.
04
Route and decide
Notify the agreed role for approval, investigation, containment, or escalation.
05
Retain
Preserve the event, decision, action, and closure according to the agreed policy.
Product support and customer-owned decisions
The division prevents monitoring output from being confused with a complete compliance program.
| # | Area | JSIR support described publicly | Customer-owned decision | Review artifact |
|---|---|---|---|---|
| 01 | Script inventory | Observed DOM scripts and third-party sources | Scope, owner, justification, authorization | Inventory export and approval records |
| 02 | Integrity | Dynamic SRI/signature support and change observation | Selected method, exceptions, rollout | Configuration and check history |
| 03 | Page comparison | HTML, JavaScript, and selected header comparison | Baseline states, normalization, thresholds | Baseline versions and event diff |
| 04 | Notification | Operational notifications and configurable webhook/SIEM options | Recipients, severity, SLA, escalation | Routing configuration and response record |
| 05 | Evidence | Inventory, comparison, event, and history exports | Retention, access, sampling, assessor format | Dated export and source record |
| 06 | Sensitive data | Structural monitoring purpose | Exclusions, masking, validation, privacy review | Approved data-flow and pilot test |
| 07 | Coverage gaps | State-level last observation and evaluated signals | Accepted journeys, unsupported states, compensating work | Coverage matrix and gap owner |
| 08 | Availability | Visibility of missed or failed observations | Retry, alternate path, escalation, recovery objective | Execution history and failure test |
Integration options and retention vary by agreed scope and plan. Confirm the production design and implemented configuration during technical review.
Methodology is not a guarantee of complete attack detection
Coverage depends on the scoped journeys, observed states, implementation, baseline quality, tuning, availability, and customer response process. Validate assumptions through controlled tests and review them when the payment architecture changes.
Methodology questions
No. It provides browser-side inventory, comparison, event, and evidence capabilities. Preventive controls, secure delivery, third-party governance, and incident response remain complementary parts of the security program.
Expected variants and volatile values are documented and tuned against controlled scenarios. Tuning changes need ownership and review so they do not silently hide meaningful scripts, destinations, or structural changes.
The exact observation or navigation mode is deployment-specific and must be confirmed during technical design. Regardless of mode, each required state needs a reliable observation path, visible execution history, and handling for states that were not observed.
The stated purpose is structural and integrity monitoring, not payment processing. The deployment must exclude sensitive payment values and unnecessary customer data, then prove those exclusions through pilot inspection of events, notifications, exports, and data flows.
Primary PCI SSC sources
Validate the method against your real checkout
A technical pilot should test page states, expected and unexpected changes, sensitive-data exclusions, routing, and evidence quality.
Request a technical review