juspay/hyperswitch · error · ApiErrorResponse

Moneris requires SignatureKey auth type

Error message

Moneris requires SignatureKey auth type

What it means

Thrown in ConnectorSpecificConfig::foreign_try_from while building the X_CONNECTOR_CONFIG header for the Moneris connector (via build_connector_config_header, connector_config.rs:1876). Moneris only accepts the SignatureKey variant (api_key, key1, api_secret), and note the non-obvious mapping: api_key becomes client_secret, key1 becomes client_id, and api_secret becomes merchant_id. Any other ConnectorAuthType variant reaches the wildcard arm and returns this error before the UCS call is made.

Source

Thrown at crates/router/src/core/unified_connector_service/connector_config.rs:1395

                    api_secret,
                } => Ok(Self::Iatapay {
                    client_id: api_key.clone(),
                    merchant_id: key1.clone(),
                    client_secret: api_secret.clone(),
                }),
                _ => Err(err("Iatapay requires SignatureKey auth type")),
            },
            Connector::Moneris => match auth {
                ConnectorAuthType::SignatureKey {
                    api_key,
                    key1,
                    api_secret,
                } => Ok(Self::Moneris {
                    client_secret: api_key.clone(),
                    client_id: key1.clone(),
                    merchant_id: api_secret.clone(),
                }),
                _ => Err(err("Moneris requires SignatureKey auth type")),
            },
            Connector::Noon => match auth {
                ConnectorAuthType::SignatureKey {
                    api_key,
                    key1,
                    api_secret,
                } => Ok(Self::Noon {
                    api_key: api_key.clone(),
                    business_identifier: key1.clone(),
                    application_identifier: api_secret.clone(),
                }),
                _ => Err(err("Noon requires SignatureKey auth type")),
            },
            Connector::Novalnet => match auth {
                ConnectorAuthType::SignatureKey {
                    api_key,
                    key1,
                    api_secret,

View on GitHub (pinned to 3093f22cc4)

Solutions

  1. Update the Moneris connector account to auth_type = SignatureKey with Moneris's inverted mapping: api_key = client_secret, key1 = client_id, api_secret = merchant_id.
  2. Double-check the credential order after switching — the swap of api_key/client_secret naming is a frequent silent misconfiguration.
  3. Ensure the create/update payload includes auth_type explicitly; the enum defaults to NoKey which always fails this match.
  4. Validate the variant before payment-time by test-building the header (see defense) so misconfiguration is caught at account setup.

Example fix

// before — connector account auth for Moneris
"auth_type": { "auth_type": "HeaderKey", "api_key": "moneris_api_token" }

// after — note inverted mapping: api_key=client_secret, key1=client_id, api_secret=merchant_id
"auth_type": {
  "auth_type": "SignatureKey",
  "api_key": "<client_secret>",
  "key1": "<client_id>",
  "api_secret": "<merchant_id>"
}
Defensive patterns

Strategy: type-guard

Validate before calling

// Before creating/updating a Moneris connector account
let auth_ok = matches!(&payload.auth_type, ConnectorAuthType::SignatureKey { .. });
assert!(
    auth_ok,
    "Moneris requires SignatureKey (api_key=client_secret, key1=client_id, api_secret=merchant_id)"
);

Type guard

fn is_moneris_compatible(auth: &ConnectorAuthType) -> bool {
    matches!(auth, ConnectorAuthType::SignatureKey { .. })
}

Try / catch

// Rust: catch at header build, classify as configuration failure (do not retry — it is deterministic)
let header = build_connector_config_header(Connector::Moneris, &auth, metadata).map_err(|e| {
    if e.current_context().message.contains("Moneris requires") {
        classify_as(Errored::ConnectorMisconfigured { connector: "moneris", hint: "set auth_type=SignatureKey" })
    } else {
        classify_as(Errored::Unexpected(e))
    }
})?;

Prevention

When it happens

Trigger: A merchant connector account for connector_name = "moneris" has auth_type != SignatureKey (e.g. HeaderKey with just an api_key, or NoKey because auth was omitted and defaulted), and any UCS-path operation calls build_connector_config_header for Moneris. Because the field mapping is inverted (api_key→client_secret), accounts configured by pasting credentials in the intuitive order often also pass the variant check but fail auth at Moneris — the variant error itself only fires on the wrong auth_type shape.

Common situations: Creating a Moneris account with a single store API token (HeaderKey) instead of the full three-part SignatureKey set; dashboards that map Moneris store id/api token/checkout id to a different auth variant; migrating from legacy per-connector auth headers to the unified connector service, where the SignatureKey requirement became a hard error; omitting auth_type in the create payload so it defaults to NoKey.

Related errors


AI-assisted analysis of juspay/hyperswitch@3093f22cc4 (2026-08-23). Data as JSON: /api/errors/440b89b0540c2f6f. Report an issue: GitHub.