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
- 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.
- Double-check the credential order after switching — the swap of api_key/client_secret naming is a frequent silent misconfiguration.
- Ensure the create/update payload includes auth_type explicitly; the enum defaults to NoKey which always fails this match.
- 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
- Document Moneris's inverted mapping (api_key holds client_secret, api_secret holds merchant_id) next to the onboarding form.
- Require SignatureKey for Moneris accounts at create time; also verify all three secrets are non-empty.
- Dry-run build_connector_config_header after every connector account update and alert on Err before live payments depend on it.
- Because this error is deterministic, mark the connector disabled-for-misconfiguration rather than retrying when it fires.
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
- Ilixium requires SignatureKey auth type
- Iatapay requires SignatureKey auth type
- Invalid Calida metadata format
- Worldpayxml requires SignatureKey auth type
AI-assisted analysis of juspay/hyperswitch@3093f22cc4 (2026-08-23).
Data as JSON: /api/errors/440b89b0540c2f6f.
Report an issue: GitHub.