Setting Up a ServiceNow Mock Instance for FSO Disputes Integration Testing

Nick Daigneau · 4 hours ago

Objective

This article introduces an approach FSO Disputes customers can use to stand up a dedicated ServiceNow instance that acts as a mock card network, letting teams exercise the full chargeback lifecycle without depending on live network transactions. It is written for stakeholders who need a reliable way to test dispute integrations during development and regression cycles. The embedded video walks through how the simulator works and what needs to be configured to set it up, and a linked knowledge base article provides an update set with the components you can import to build the simulator on your own mock instance.

Why Use a Mock Instance

Testing card network integrations against live networks is slow, costly, and hard to control. A mock instance lets you simulate responses from Mastercard and its Mastercom dispute network so you can run the end to end chargeback flow on demand. The video demonstrates Mastercard and Mastercom specifically, but the same framework can be extended to other card networks. This gives development and QA teams a repeatable way to validate dispute behavior, reproduce edge cases, and run regression tests in isolation.

What the Video Covers

The video is organized in two parts. The first part demonstrates the simulator in action. The second part goes behind the scenes to show what must be configured to set it up.

Part 1: Walking Through the Simulator

The first half follows a fraud-categorized Mastercard dispute through its lifecycle. Starting from a dispute that has completed the initiate and investigate lanes (fraud reported, provisional credit issued, pre-dispute resolution done), the walkthrough shows:

Initiating a chargeback to recover funds, which fires the integration, moves the dispute to awaiting external info, and generates a claim ID.
Switching to the mock instance, where the generated claim ID is matched in the Mastercom Mocks table and a response is simulated using forms for the chargeback, second presentment, and case filing stages.
Simulating a merchant or acquirer rejection of the chargeback using first party trust evidence, which routes the record to the appropriate queue.
Returning to the issuer instance and manually running the Mastercom queues flows adapter subflow to pull the simulated response back. In production this subflow runs on a set interval; here it is triggered on demand.
Following the dispute through later stages, including denying the merchant response, raising a second presentment, handling a failed document upload edge case, retrieving documents (including zipped documents that can be auto unzipped), and initiating a pre-arbitration.

Part 2: Behind the Scenes Configuration

The second half explains the setup that makes the simulation work:

Connection redirection: Instead of pointing the Mastercard spoke connection at Mastercom, the connection URL is updated to reference the mock instance, with credentials set to the mock instance admin account.
Two subflow types: Subflows that carry no PCI data, such as Create Chargeback, call the spoke action directly against the mock base URL. Subflows that carry PCI data, such as Lookup Authorization Transaction Details, use a request builder and response parser with a tokenization step in between.
Token routing: Because the PCI-bearing spoke actions do not call the REST API directly, a decision table named Mastercard Token Provider Configuration holds the Mastercard API endpoints that carry sensitive data and routes them to a Mastercard Token Service Mock subflow. For testing, the REST calls are formed directly rather than going through a live tokenization service.
The Mastercom Simulator application: A custom application on the mock instance holds the simulated disputes table, the UI actions that appear dynamically across the lifecycle, the scripted REST service (Mastercard Sim) that exposes the Mastercom API endpoints, and a script include that orchestrates the lifecycle by invoking resources and showing or hiding UI actions. Claim payloads and case filing payloads are stored separately and persisted to activity history for audit purposes, and claim IDs are auto generated and returned to the source instance.

Note: The simulator does not cover every scenario in the dispute lifecycle. It handles the most common responses and is designed to be modified to fit your specific network and issuer requirements.

Importing the Components

A companion knowledge base article provides an update set containing many of the components highlighted in the video, so you can import the simulator framework directly onto your own mock instance rather than building it from scratch. Use the KB article alongside the video: the video explains what each element does and how the pieces fit together, and the update set gives you the starting components to adapt to your own issuer requirements.

You can access the update set in the companion KB article here: KB3098092 Deploying the Mastercom Simulator

What's Next

To go deeper on FSO Disputes setup and process design, see this related Community article:

Getting Started with FSO Disputes

Have you built your own mock instance for dispute testing, or extended this framework to another card network? Share your approach in the comments so other FSO teams can learn from it.