# Gateway agnostic MITs

Route MIT (Merchant-Initiated Transaction) payments across multiple processors for better success rates and resilience. Enable this feature and Orchestration handles the technical details - your saved cards work across PeachPayments, ACI, and Cybersource.

## Use cases

- High-volume subscription businesses
- Multi-region payment optimisation
- Processor redundancy/failover
- Cost optimisation across gateways
- Reducing involuntary churn from declines

## Steps

### 1. Enable gateway-agnostic MITs — `POST /account/{merchant_id}/business_profile/{profile_id}/toggle_connector_agnostic_mit`

Enable the connector-agnostic MIT feature on your business profile.

API call:
POST /account/{merchant_id}/business_profile/{profile_id}/toggle_connector_agnostic_mit
Body: { "enabled": true }

When this feature is enabled, Orchestration automatically captures the data needed to route MIT payments across processors.

Request body:

```json
{
  "enabled": true
}
```

### 2. Save card for MIT — `POST /payments`

Create a payment with setup_future_usage: "off_session" to save the card for merchant-initiated charges.

Key parameters:
• customer.id (required) - Your unique customer identifier
• setup_future_usage: "off_session" - Enables MIT payments

Orchestration automatically captures the authorisation data needed for cross-processor routing.

Request body:

```json
{
  "amount": 6500,
  "currency": "ZAR",
  "confirm": false,
  "capture_method": "automatic",
  "authentication_type": "three_ds",
  "setup_future_usage": "off_session",
  "description": "Initial payment - saving card for gateway-agnostic MIT",
  "return_url": "https://example.com/flows/gateway-agnostic-mit?status=complete",
  "is_iframe_redirection_enabled": true,
  "billing": {
    "address": {
      "line1": "123 Main Street",
      "line2": "Apartment 4B",
      "city": "Cape Town",
      "state": "Western Cape",
      "zip": "8001",
      "country": "ZA",
      "first_name": "John",
      "last_name": "Doe"
    },
    "phone": {
      "number": "821234567",
      "country_code": "+27"
    },
    "email": "john.doe@example.com"
  },
  "shipping": {
    "address": {
      "line1": "456 Delivery Road",
      "line2": "Unit 7",
      "city": "Cape Town",
      "state": "Western Cape",
      "zip": "8001",
      "country": "ZA",
      "first_name": "John",
      "last_name": "Doe"
    },
    "phone": {
      "number": "821234567",
      "country_code": "+27"
    },
    "email": "john.doe@example.com"
  },
  "customer": {
    "id": "cus_agnostic_mit_user",
    "email": "subscriber@example.com",
    "name": "Gateway Agnostic User"
  }
}
```

### 3. Customer authenticates

Customer completes 3DS authentication. This establishes the authorisation for future MIT charges.

After success, you'll receive:
• payment_method_id: Use this for all future MIT charges
• The card is now saved and can be charged via any supported processor

### 4. Process MIT payment — `POST /payments`

Charge the customer using the saved payment_method_id. Orchestration routes to the best available processor.

Key parameters:
• off_session: true - Customer not present
• confirm: true - Process immediately
• recurring_details: { type: "payment_method_id", data: "pm_xxx" }

Orchestration handles processor selection and includes the authorisation chain data automatically.

Request body:

```json
{
  "amount": 6500,
  "currency": "ZAR",
  "confirm": true,
  "off_session": true,
  "description": "MIT payment - routed to best processor"
}
```

### 5. Automatic retry (on decline)

If the first processor declines, Orchestration can automatically retry through another processor.

Configure retry rules in your routing configuration:
• Primary: Route to preferred processor
• Fallback: On soft decline, try alternate processor
• Final: Use highest-success-rate processor

All retry attempts maintain the authorisation chain, maximising approval rates.

## Response

Payment endpoints return the payment object. Key fields to read:

- `payment_id` — the payment identifier.
- `status` — current payment status (see the state transitions below).
- `client_secret` — pass to the SDK to complete the payment client-side.
- `next_action` — present when a redirect or 3-D Secure challenge is required.

## Key parameters

- MIT payments route to any supported processor
- No lock-in to original tokenising gateway
- Automatic retry across multiple processors
- Orchestration handles technical details

## Why gateway agnostic?

Traditional recurring payments lock you to a single processor. Gateway-agnostic MITs let you route charges to any supported processor for better success rates and redundancy.

### Benefits

- **Processor flexibility** — Route MIT payments to any supported processor (PeachPayments, ACI, Cybersource) instead of being locked to the original gateway.
- **Higher approval rates** — Orchestration maintains authorisation chain data that issuers recognise as legitimate recurring charges, improving approval rates.
- **Automatic retry** — If one processor declines, automatically retry through another without re-authenticating the customer. Critical for subscription businesses.
- **No connector lock-in** — Optimise routing based on cost, success rates, or geography. Switch processors without asking customers to re-enter cards.
- **Built-in redundancy** — If your primary processor has downtime, MIT payments automatically route to backup processors. No single point of failure.

### How it works

- **Supported Processors** — Currently supported on PeachPayments, ACI, and Cybersource. Orchestration handles the technical details of cross-processor routing.
- **Automatic Token Management** — Orchestration captures and stores network transaction identifiers during the initial payment. You just use payment_method_id - the rest is automatic.
- **Enabling the Feature** — Enable via API: POST /account/:merchant_id/business_profile/:profile_id/toggle_connector_agnostic_mit with {"enabled": true}
- **Routing Configuration** — Use metadata fields to configure different routing rules for CIT vs MIT payments, enabling smart processor selection.

### Without mandates

Without gateway-agnostic MITs, you're locked to a single processor. If that processor has downtime or high decline rates, you have no fallback.

### Best practices

- Enable connector_agnostic_mit on your business profile before saving payment methods
- Configure routing rules to try multiple processors for MIT payments
- Use metadata to differentiate CIT vs MIT for smart routing
- Monitor decline rates per processor and adjust routing accordingly
- Set up fallback processors for automatic retry on soft declines

## Flow diagram

```mermaid
flowchart LR
    subgraph Setup["Initial Payment (Customer Present)"]
    A[Enable Feature] --> B[Create Payment]
    B --> C[Mount SDK]
    C --> D[Customer 3DS]
    D --> E[Card Saved]
    end
    subgraph MIT["MIT Payments (Multi-Processor)"]
    E --> F[MIT Request]
    F --> G{Processor A}
    G -->|Success| H[Complete]
    G -->|Decline| I{Processor B}
    I -->|Success| H
    I -->|Decline| J{Processor C}
    J --> H
    end
```

## Payment state transitions

```mermaid
stateDiagram-v2
    state "Initial Setup" as cit {
        [*] --> requires_payment_method
        requires_payment_method --> processing: Customer Pays
        processing --> succeeded: Card Saved
    }
    state "MIT Processing" as mit {
        [*] --> processor_a: payment_method_id
        processor_a --> succeeded: Approved
        processor_a --> processor_b: Soft Decline
        processor_b --> succeeded: Approved
        processor_b --> processor_c: Retry
        processor_c --> succeeded: Approved
        processor_c --> failed: All Failed
    }
    cit --> mit: Use saved card

    note right of mit: Routes to any - supported processor
```

---

Interactive version: https://playground.peachpayments.com/flows/gateway-agnostic-mit