Pipeline API (Orchestration)

The Pipeline API provides a unified way to execute multiple MIDSuite services within a single request. Instead of calling Rules, Sentry, PreCheck, or Identity Verification individually, the Pipeline API orchestrates them according to a configured pipeline and returns all results in a single response.

This approach simplifies integrations, reduces network overhead, and ensures consistent evaluation order across multiple fraud-prevention and verification services.

Endpoint:

POST /api/v1/pipeline

What the Pipeline API Does

A pipeline represents a predefined sequence of services executed by MIDSuite. Each pipeline is identified by a pipelineId and determines:

• Which services are executed

• The order in which they run

• How results are combined

• Which billing items apply

A single pipeline request can execute multiple services such as:

• Rules — Fraud decisioning

• Sentry — Device and behavioral risk analysis

• PreCheck — Card validation (AVS/CVV)

• ID Verify — Identity verification

Each stage runs synchronously, and the final response includes the output from every service that executed.

Pipeline Request Structure

A pipeline request includes:

Only the inputs required by the configured pipeline stages need to be provided.

Pipeline Stages

The response indicates which services were executed through the pipelineStages field.

Example stage list:

"pipelineStages": [
  "Rules",
  "Sentry",
  "PreCheck",
  "Gateway"
]

Typical stage purposes:

The exact stages executed depend on the configured pipeline.

Reading the Pipeline Response

The pipelineResponse object contains the results of all executed services.

Example structure:

Example interpretations:

• Rules ACCEPT + PreCheck ACCEPT → transaction likely safe

• Rules REVIEW → transaction may require manual review

• High Sentry score → increased fraud risk

Billing Information

Like all MIDSuite services, pipeline responses include billing details.

Each executed service produces a billing item:

"feeType": "RULES"
"feeType": "SENTRY"
"feeType": "PRECHECK"

The billing object includes:

• Individual service fees

• Remaining account balance

• Authorized and closed billing amounts

This allows clients to track cost per request and per service stage.

Example Pipeline Request

The following example runs a pipeline that evaluates Rules, Sentry, and PreCheck in a single request.

{
  "clientReferenceId": 123,
  "pipelineId": 2,
  "rulesRequest": {
    "customerIp": "134.25.212.56",
    "cardNumber": "4321432143214321"
  },
  "preCheckRequest": {
    "cardNumber": "4321432143214321",
    "cardExpiryDate": "2028-12",
    "cardCvv2Value": "123",
    "cardAddress": {
      "street": "123 First St",
      "postalCode": "90254"
    }
  },
  "sentryRequest": {
    "device": {
      "ipAddress": "134.25.212.56",
      "userAgent": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.89 Safari/537.36",
      "acceptLanguage": "en-US,en;q=0.8",
      "sessionId": "80b4d4c1-3767-44da-a5c6-5c46094c4414",
      "sessionAge": 1800
    }
  }
}

Example Pipeline Response

{
  "isSuccess": true,
  "pipelineResponse": {
    "pipelineStages": [
      "Rules",
      "Sentry",
      "PreCheck",
      "Gateway"
    ],
    "tags": [],
    "rulesResponse": {
      "status": "ACCEPT"
    },
    "preCheckResponse": {
      "avsResult": "POSTCODE_MATCH",
      "cvv2Result": "MATCH",
      "advice": "ACCEPT"
    },
    "sentryResponse": {
      "ipScore": 0.7903,
      "requestScore": 0.7798
    }
  },
  "billing": {
    "items": [
      {
        "feeType": "RULES",
        "fee": {
          "currency": "USD",
          "amount": 0.0300
        },
        "completed": true
      },
      {
        "feeType": "SENTRY",
        "fee": {
          "currency": "USD",
          "amount": 0.0500
        },
        "completed": true
      },
      {
        "feeType": "PRECHECK",
        "fee": {
          "currency": "USD",
          "amount": 0.0400
        },
        "completed": true
      },
      {
        "feeType": "GATEWAY",
        "fee": {
          "currency": "USD",
          "amount": 0.0350
        },
        "completed": true
      }
    ],
    "remainingBalance": {
      "currency": "USD",
      "amount": 98.6900
    },
    "amountAuthorized": {
      "currency": "USD",
      "amount": 0.1550
    },
    "amountClosed": {
      "currency": "USD",
      "amount": 0.1550
    }
  },
  "errors": null
}

Common Pipeline Integration Patterns

Different applications use pipelines in different ways depending on risk tolerance and transaction type. The following patterns represent common integration approaches.

Checkout Fraud Screening

Typical pipeline stages

Rules → Sentry → PreCheck → Gateway

Purpose

This is the most common pipeline configuration for ecommerce checkout flows. It evaluates fraud risk, device signals, and card validity before completing payment authorization.

Typical inputs

• Customer IP address

• Device and session data

• Card details

• Billing address

Typical outcomes

• ACCEPT → proceed with transaction

• REVIEW → trigger manual review or step-up verification

• DECLINE → block transaction

Account Creation Risk Assessment

Typical pipeline stages

Sentry → Rules

Purpose

Used during account creation or signup flows to detect bot activity, suspicious device fingerprints, or high-risk IP addresses.

Typical inputs

• Device information

• IP address

• Session metadata

• Account identifiers

Typical outcomes

• Allow account creation

• Require CAPTCHA or additional verification

• Flag account for monitoring

Identity Verification Before Transaction

Typical pipeline stages

IdVerify → Rules → PreCheck

Purpose

Used in high-risk environments where identity verification must occur before a transaction is approved.

This pattern is common for:

• Financial services

• Subscription services with fraud risk

• High-value purchases

Typical inputs

• Cardholder name

• Email address

• Phone number

• Government ID numbers

• Payment card details

Typical outcomes

• Verified identity → continue with transaction

• Partial verification → require additional identity proof

• Failed verification → block transaction

When to Use the Pipeline API

The Pipeline API is recommended when:

• Multiple MIDSuite services are required for a single transaction

• A consistent evaluation order is important

• Network latency should be minimized

• Integration complexity should be reduced

Calling the Pipeline API is typically more efficient than invoking individual services separately, especially for checkout flows or real-time fraud screening.