Revenue critical journey integrity review

Revenue-Critical Journey Integrity Review

Purpose

Review the seams of revenue-critical journeys — the points where a request crosses from client to server, from your system to a payment processor, or from a webhook back into your system — so a journey that looks correct in any one tier does not break where the tiers meet. The dominant seam failures are non-idempotent money-moving requests, client-enforced rules the server never re-validates, webhook consumers that assume exactly-once/in-order delivery, unbounded retries that become retry storms, and PCI DSS SAQ-scope misjudgment.

When to use

Use this skill when the user asks to:

• review whether a checkout, payment, subscription, coupon, or account-creation request is safe to retry (idempotency at money-moving seams),
• confirm the server re-validates rules the client enforces (price, discount, quantity, eligibility, step-completion),
• review a webhook consumer for duplicate-delivery and out-of-order handling,
• review retry/backoff/circuit-breaker safety at a revenue-critical seam across web, mobile, or backend consumers,
• get an advisory PCI DSS SAQ-scope opinion for the payment integration model actually in the code.

When not to use

Do not use this skill for:

• tier-internal review that an owning specialist owns — DOM XSS/CSP and client injection (use the frontend security review), backend authorization-model design, mobile-platform specifics, or infrastructure hardening. This skill reviews the seam, not the interior; hand tier-internal findings to the owning agent.
• issuing a PCI compliance attestation, signing an SAQ, or acting as an assessment of record. SAQ-scope output here is advisory only.
• any live exercise of a payment system — executing flows, replaying webhooks, or sending requests to live/sandbox/staging processors. This skill is static review only.

Preconditions

• The money-moving and account-creating request paths in scope, across whichever tiers exist.
• The webhook consumer code and the event types it acts on.
• The retry configuration (max attempts, backoff, jitter, timeout, circuit breaker) for the seams in scope.
• The payment integration model (redirect, iframe/hosted fields, direct post/custom form) if a SAQ-scope opinion is requested.
• The processor/SDK and version in scope, so idempotency and webhook guidance matches the real API surface.

Lean operating rules

• Confirm retry/replay reachability before flagging an idempotency gap; a genuinely non-retryable internal call is not a finding.
• Treat the server as the only enforcement boundary; a client-only check is UX, not enforcement.
• Require webhook consumers to be both idempotent (dedupe by event id or business key) and order-tolerant.
• Require bounded, backoff-with-jitter retries with a timeout at every revenue seam; add a circuit breaker or dead-letter path for backend/queue consumers.
• Give a PCI SAQ-scope opinion only against the integration model present in the code, name the candidate SAQ, and label it advisory.
• Never request, echo, store, or reproduce cardholder data, API keys, session tokens, or webhook signing secrets; redact-and-flag any that appear.
• Label every claim repo evidence, context7-grounded, documentation-based, or inference.

Context7 documentation protocol

Processor idempotency semantics, webhook retry windows, event ordering, and signature verification are version-sensitive. The bundled official sources are the versioned ground truth for this skill: every processor-specific claim must trace to them and is labeled documentation-based, and the ledger records the version and last-verified date so a claim can be re-checked. This static-review skill's own tool grant is read-only (Read Grep Glob); when the invoking harness additionally provides Context7 or official-documentation tools, use them to confirm the current behavior against the bundled snapshot (resolve-library-id then query-docs, labeled context7-grounded) and to cover a processor the bundle does not. For a processor with no bundled or fetched coverage, say so and treat the claim as inference — never rely on memorized API details.

Workflow

Follow the step-by-step review and output contract in workflow and output. At a high level: (1) map the seams in scope; (2) for each money-moving/account-creating request, check idempotency against reachable retry/replay; (3) check server re-validation of every client-enforced rule; (4) check webhook consumers for idempotency + order-tolerance; (5) check retry safety; (6) if requested, form the advisory SAQ-scope opinion; (7) emit findings with evidence tiers and tier-internal handoffs.

Decision gates

• Block only on a seam failure with a demonstrated reachable retry/replay/bypass path.
• Every processor-specific claim is Context7-grounded or documentation-based, never memory.
• Every SAQ-scope statement is advisory and tied to the integration model in the code.
• Every tier-internal finding is handed off, not adjudicated.

Evidence classification

Label each finding repo evidence (seen in the code), context7-grounded (current provider docs via Context7), documentation-based (official docs), or inference. Documentation never proves a specific deployment's live behavior — say so.

Security and privacy constraints

Static review only. Never transmit, request, store, or reproduce cardholder data (PAN/CVV), API keys, session tokens, or webhook signing secrets; treat any such string as a redact-and-flag finding. Never execute payment flows or contact any live/sandbox/staging payment system. PCI SAQ-scope output is an advisory opinion, never an attestation.

Escalation conditions

Escalate to incident response on any evidence of a live failure (duplicate charges in logs, replayed webhooks, retry amplification). Escalate SAQ-scope opinions to the merchant's compliance owner or a QSA as advisory input.

References

Load these only when needed:

• Workflow and output — the end-to-end review steps and the finding/output contract.
• Idempotency and safe retries — idempotency keys at money-moving seams and bounded backoff-with-jitter retry design.
• Webhook delivery: dedup and ordering — duplicate-delivery and out-of-order handling for webhook consumers.
• Server-side re-validation and the client trust boundary — why the server is the only enforcement boundary and what to re-check.
• PCI DSS SAQ scope boundaries — SAQ A vs A-EP vs D by integration model and the 6.4.3/11.6.1 payment-page expectations.
• Official sources — the primary-source ledger for every claim in this skill.

Response minimum

Return, at minimum:

• the seam(s) in scope and, per finding, the failure class and evidence tier;
• the cross-tier failure narrative (how a retry, replay, or bypass reaches a wrong outcome);
• concrete remediation and an exact verification step;
• the advisory SAQ-scope opinion when requested, labeled advisory;
• tier-internal handoffs and any incident-response escalation.

Anti-goals

• Do not expand into tier-internal review; own the seam, hand off the interior.
• Do not present a SAQ-scope opinion as a compliance determination.
• Do not exercise any live payment system or reproduce any secret or PAN.
• Do not assert processor behavior from memory.