> ## Documentation Index
> Fetch the complete documentation index at: https://developer.hellgate.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Specter Updates

> New releases and improvements of Specter.

<Update label="July 31, 2026" tags={["New Release"]}>
  ## PayPal Payment Method Type

  Decision requests now accept a `paypal` credential alongside `pan`,
  `masked_pan`, and `sepa`. The credential carries `email`, `payer_id`,
  `address_status`, `protection_eligibility`, and `payer_status` — all
  optional, all caller-injected from your PayPal flow, and all addressable in
  rules as `$.credential.paypal.*`. Send whichever your flow has captured at
  the point you call Specter. The email is never persisted raw; the decision
  log keeps the credential fingerprint (computed from `payer_id`) and a masked
  form. See
  [Credential types](/products/specter/integration/via-api#credential-types).
</Update>

<Update label="July 28, 2026" tags={["Improvement"]}>
  ## Report Fraud on Any Decision

  `fraud_report` events are no longer tied to the payment lifecycle: they are
  accepted in any payment state — including for decisions that never received a
  lifecycle event — so you can feed fraud signals back to Specter even if you
  only use it for screening. An accepted report sets a permanent fraud marker on
  the decision (`fraud_marked_at`, `fraud_source`, `fraud_reason`), independent
  of `payment_state`, and continues to fan out to backends and auto-populate the
  [blacklist](/products/specter/concepts/blacklist). See
  [lifecycle events](/products/specter/concepts/lifecycle-events#fraud-reports).
</Update>

<Update label="July 21, 2026" tags={["Improvement"]}>
  ## Smarter Condition Fields in the Rule Editor

  The rule editor's condition field suggestions are now served by the backend,
  so the type-ahead always matches the exact request shape your rules evaluate
  against — including nested credential fields and your `$.metadata.*` paths.
  Fields that are unavailable on your instance, such as raw PAN paths below
  SAQ-D, are omitted automatically.
</Update>

<Update label="July 17, 2026" tags={["New Release", "Improvement"]}>
  ## Run Specter Within SAQ A and SAQ A-EP Scope

  Specter now runs on instances assessed at SAQ A or SAQ A-EP — you no longer
  need a SAQ-D environment to use it. Below SAQ-D, Specter actively enforces
  the boundary that keeps your assessment scope small: request bodies carrying
  a raw card number (PAN) outside the designated credential field are rejected
  with a `422` validation error, and Interceptor payloads are scanned so raw
  card data never reaches your instance.

  The platform test-card policy applies on every instance: on the Test tier,
  decision requests accept only known test cards; on the Production tier, test
  cards are rejected. Violations return a `403` with a clear classifier.
</Update>

<Update label="July 6, 2026" tags={["New Release"]}>
  ## Specter Is Live

  Specter — the risk and fraud decisioning component of the
  [Composable Payment Architecture](/platform/cpa) — is now generally available
  on the Test and Production tiers. Evaluate payments against your own
  [rulesets](/products/specter/concepts/rulesets) and get an allow, block, or
  review [decision](/products/specter/concepts/decisions) in real time.
  Integrate through the [Decision API](/products/specter/integration/via-api),
  or drop the [Interceptor](/products/specter/integration/via-interceptor)
  into your existing PSP traffic without changing your payment flow. External
  risk engines plug in through [Link](/products/link/overview) backends.

  Start with the [overview](/products/specter/overview) and
  [plans and access](/products/specter/plans-and-access).
</Update>