Skip to main content

Integration Patterns

In order to integrate MCP Certify, you must first be registered as a customer and you must have provisioned at least one service.

info

While MCP Certify is designed for straightforward integration, effective compliance verification requires careful implementation. MCP Certify's accuracy depends on receiving complete, consistent data throughout the user journey. Small details matter: the timing of when Certify loads. A well-executed integration maximizes monitoring accuracy.

Getting started​

MCP Certify supports the following integration methods. Each integration scenario below includes a logical flow and a sequence diagram to clarify how MCP Certify is invoked.

Regional endpoints​

MCP Certify technology is deployed in several regions to provide the best latency between your servers and our regional endpoints.

In each region, the architecture is set up to provide high availability through autoscaling technology. As MCP Certify relies on real time monitoring and verification, our server availability needs to match our clients' capacity needs and variations.

RegionAPI Endpoint
Southern Africahttps://sa.apiserver.shield.monitoringservice.co
Singaporehttps://sg.apiserver.shield.monitoringservice.co
United Kingdomhttps://uk.apiserver.shield.monitoringservice.co
United Arab Emirateshttps://dc-ae-01.apiserver.mena.mcpshield.com

Latency test​

We provide a script to test latency between your webservers and each Certify region. This bash script will run a few curl commands and print performance results.

wget https://docs.shield.monitoringservice.co/shield-latency 
sh shield-latency

Aggregator-Hosted Payment Page with MCP Certify Embedded​

Scenario: In this scenario, the Aggregator embeds MCP Certify on the payment page. MCP Certify initializes on page load, collects journey and device signals, and performs the validation flow itself when the user reaches the confirmation step.

Flow​

  • End user loads the CSP landing page.
  • The CSP landing page renders and the user clicks Subscribe.
  • The CSP redirects the user to the Aggregator payment page with a 302 redirect.
  • The Aggregator payment page sends a Certify JS kit init request to MCP Certify.
  • MCP Certify returns the Certify snippet and UNIQID.
  • The Aggregator renders the payment page with MCP Certify activated.
  • MCP Certify collects the page DOM.
  • MCP Certify receives device fingerprinting data from the user's device.
  • MCP Certify receives behaviour events during the payment-page session.
  • The user clicks Confirm / CTA on the Aggregator payment page.
  • MCP Certify performs the Block API call itself using the UNIQID.

Aggregator-Hosted Payment Page with MCP Certify Embedded

Pros and Cons​

Pros:

  • Server to server JS API call is more secure than client side call
  • By being embedded into the HEAD of the HTML page, the MCP Certify snippet is active from the moment the page is loaded
  • Aggregator enforces the use of MCP Certify since they host the payment page
  • The aggregator only needs to embed MCP Certify on the payment page
  • MCP Certify handles the validation call itself inside this model

Cons:

  • User is redirected between two different web servers
  • MCP Certify only has visibility of the second page
  • Payment page content is controlled by the aggregator, limiting the CSPs' choices

Frontend integration​

warning

This integration pattern is not recommended

Frontend

Pros & Cons​

Pros:

  • Simple integration
  • Compatible with content delivery network static page deployments

Cons:

  • Exposes sensitive information in front end code
  • More prone to tampering by bad actors
  • Fraud detection does not begin at the moment the page is loaded