Skip to main content
Version: 9.1.021

MCP Shield API

MCP Shield is a real-time fraud detection and traffic quality solution designed for high-volume digital journeys such as subscription flows, payment flows and marketing funnels.

Core capabilities:​

  • Injects a controlled JavaScript kit on landing pages to collect device, browser and behavioural signals.
  • Generates a unique session identifier (uniqid) for each tracked journey.
  • Evaluates each session and associated transaction against fraud rules, device intelligence and behavioural indicators through the Block API.
  • Exposes a verification endpoint for confirming payment or transaction state using the same uniqid key.

Typical integration flow:​

  1. The Client configures a service within the MCP Shield dashboard and obtains a service key.
  2. The Client backend calls the regional JS Integration endpoint to obtain a uniqid and a JavaScript snippet.
  3. The Client injects the returned JavaScript into the landing page so that client-side data collection and device intelligence can take place.
  4. When a transaction is ready to be decided, the Client backend submits the uniqid to the Block API to obtain a Block API decision (Block, Suspect, or Clear) and an associated score representing the evaluated fraud status.
  5. For payment flows, the Client may call the Verification API with the same uniqid to confirm the final status.

Note: See Integration patterns for more integration details.

Two-page implementation:​

  • On page one, the JS API call generates a uniqid for the initial request.
  • The uniqid is persisted or appended to the URL when redirecting to page two: https://example.com/page2?uniqid=page1_uniqid
  • The Block API call is made with the uniqid from page two.

Monitor-only mode:​

  • The technical integration is identical to blocking mode.
  • The Block API is still called for each relevant journey.
  • The Client records the decision but does not enforce it for blocking.
  • This enables live monitoring, rule tuning and A/B testing of policies without directly impacting customer flows.

Traffic policy and implementation notes:​

  • It is recommended to use a campaign or journey-specific identifier such as gclid and standard UTM parameters (utm_source, utm_medium, utm_campaign, utm_term, utm_content) on every flow so that reports can distinguish between different campaigns and partners. These parameters must be configured during service set up in order for them to appear in the Shield dashboard. See Traffic Segmentation for more information.
  • Automated or programmatic clicks (for example, JavaScript-triggered clicks without explicit user action) will be blocked and should be avoided. These can create artificial journeys and distort fraud and quality metrics.
  • Desktop traffic is blocked by default and can be enabled explicitly per campaign if appropriate.