Testing
Integration Test Flow
Follow these steps to test your Shield implementation:
- Understand what Integration pattern you will be using.
- Be clear who will be executing the JS API call and who will be executing the Block API call.
- Create a service in the Shield dashboard.
- Set the Block API IP whitelist
- Note the service ID.
- Generate a staging key
- Program your service's landing page server to retrieve the JS snippet and embed it into the HTML page.
- Program your server to call the Block API after the user clicks a CTA.
- Be sure you call the Block API from a whitelisted IP address
- Once you have built the back end processes above, open the landing page on your device.
- Note Shield's uniqid. This can be found in the JS API response and inside the page HTML
- Pay special attention to the common pitfalls below
- Click the CTA and examine the response the server gets from the Block API in step 5.
- Visit
https://shield.monitoringservice.co/transaction/view/{UNIQUEID}to see Shield's detailed analysis.
Common Testing Pitfalls
Be aware of these patterns that will trigger blocks:
- Chrome flags and developer debugging - Some settings will trigger false positives such as programmatic clicks.
- In your mobile browser, visit chrome://flags.
- Press Reset all and relaunch Chrome.
- Completely Force Stop Chrome from Android Settings.
- Disconnect USB/ADB from any computer.
- Ideally disable USB debugging temporarily.
- Reboot the phone.
- After reboot, manually tap the normal Google Chrome icon.
- Manually enter your Shield staging URL.
- Visit your landing page and test again.
- Localhost testing — Blocked due to IP anomaly detection
- Desktop traffic is blocked by default. Unless you've explicitly enabled it, any subscription attempts from desktop will be blocked—even if you modify your user agent to appear mobile. Shield is designed to detect this type of suspicious spoofing pattern.
- Autoclicking — Automated click patterns are detected and blocked
- AJAX calls for the JS API — Not permitted; use the standard implementation
- Remote desktop tools (TeamViewer, AnyDesk, etc.) — Detected as:
- Failed interaction patterns
- Programmatic clicks
- Premature Block API calls — Only call the Block API on actual user interaction; don't call it immediately after the JS API loads
- Other fraud vendors - There can be conflicts when multiple fraud vendors are implemented on the same landing page, sometimes causing false positives for programmatic clicks.
- Block API IP whitelist - Make sure you are calling this API from an allowed IP.
Desktop Testing
Shield is designed primarily around the intended production user journey. Development from desktop or other non-production environments may therefore produce conditions that differ from a normal production session.
A valid staging key applies controlled testing treatment to selected conditions so that developers can complete integration testing.
Final validation should still be performed using an environment representative of the intended production journey.
Repeated Testing
Development teams may perform many test journeys over a short period of time from the same environment or network.
This behaviour can differ significantly from normal production traffic.
When a valid staging key is used, Shield applies controlled staging treatment to selected conditions associated with legitimate repeated testing.
Other Shield protections remain active.
Remote-Control and Non-Standard Test Environments
Tools such as TeamViewer, AnyDesk and similar remote-control solutions can produce interaction characteristics that differ from a user physically touching the device.
When a valid staging key is used, Shield applies controlled staging treatment to selected conditions that may commonly occur during legitimate integration testing.
This helps prevent expected testing behaviour from unnecessarily interrupting the integration process.
Other Shield security and integrity controls remain active, and a staging key should not be considered a general bypass or allow-list.
For final validation, testing should be performed under conditions that are representative of the intended production user journey.
AJAX Execution of the JS API
Do not execute the Shield JS API through AJAX unless specifically instructed to do so as part of an approved integration pattern.
Use the standard Shield implementation appropriate to your integration.
Premature Block API Calls
Only call the Block API following the genuine user action associated with the transaction.
Do not call it immediately after the JS API loads or before the expected user interaction has occurred.
Multiple Fraud or Security Solutions
Where several fraud-detection or security solutions are integrated into the same page, one solution may alter browser behaviour, interaction events or page execution in a way that affects another.
If unexpected results occur, test the Shield implementation independently to help isolate the cause.
Block API IP Whitelist
The staging key does not replace the Block API IP whitelist requirement.
Ensure that Block API requests originate from an IP address configured for the service.
Staging Keys
Staging keys are temporary testing credentials designed to support Shield integration and development.
When a valid staging key is supplied, Shield applies controlled testing exceptions to a limited set of conditions that can commonly occur in development or staging environments.
Important: A staging key does not disable Shield, create a general allow-list, or bypass Shield's wider security controls.
Key Properties
- Validity: 24 hours
- Renewal: Generate a new staging key after the existing key expires.
- Purpose: Integration, development and controlled staging testing only.
- Usage: Supply the staging key using the designated parameter in the landing page url
https://yourdomain.com/landing-page?mcpstagingkey=YOUR_STAGING_KEY.
Staging Behaviour
A staging key provides controlled treatment for selected conditions associated with:
| Testing Scenario | Staging Behaviour |
|---|---|
| Desktop and development environments | Selected restrictions that would normally affect non-production testing environments are adjusted to allow integration testing to proceed. |
| Repeated test activity | Selected protections associated with repeated development and testing activity are adjusted to reduce unnecessary interruption of legitimate tests. |
| Remote-control and test tooling | Selected conditions commonly produced by remote-control or device-testing tools are treated appropriately for staging. |
| Non-standard test environments | Selected environment-consistency conditions that may occur during development or testing are handled using staging rules. |
The staging key affects only a defined subset of Shield's controls. Shield continues to analyse the journey and apply protections outside the permitted staging exceptions.
What a Staging Key Does Not Bypass
A staging key is not a universal bypass.
Controls outside the defined staging exceptions remain active, including broader security, integrity and fraud-detection protections.
In addition:
- The Block API IP whitelist is still required.
- Normal JS API and Block API integration requirements still apply.
- Incorrect or suspicious implementations may still be restricted.
- Staging behaviour should not be considered representative of production enforcement.
The staging key is intended to make legitimate integration testing practical while maintaining Shield's wider protection and analysis capabilities.
Implementation Checklist
Before going live, ensure that you have confirmed:
- Which partner executes the JS API.
- Which partner executes the Block API.
- The Block API is triggered only following genuine user interaction.
- Block API requests originate from an authorised IP address.
- Both allowed and restricted outcomes are handled correctly.
- Integration testing has been completed using a staging key.
- Final testing has been performed under production-representative conditions.
- Your implementation follows the Shield Best Practices guidance.