juspay/hyperswitch · error · Error

Invalid authentication type ${response.body.authentication_t

Error message

Invalid authentication type ${response.body.authentication_type}

What it means

Thrown by the confirmCallTest command (cypress-tests/cypress/support/commands.js:3346) on the success path of POST /payments/{id}/confirm when capture_method is 'automatic' but response.body.authentication_type is neither 'three_ds' nor 'no_three_ds'. The command's if/else only models those two auth types; anything else — including undefined or a newly added enum value — is treated as a protocol violation and thrown.

Source

Thrown at cypress-tests/cypress/support/commands.js:3346

                );
              }
              for (const key in resData.body) {
                expect(resData.body[key], [key]).to.deep.equal(
                  response.body[key]
                );
                if (
                  response.body.setup_future_usage === "off_session" &&
                  response.body.status === "succeeded" &&
                  globalState.get("connectorId") !== "tsys_transit"
                ) {
                  expect(
                    response.body.connector_mandate_id,
                    "connector_mandate_id"
                  ).to.not.be.null;
                }
              }
            } else {
              throw new Error(
                `Invalid authentication type ${response.body.authentication_type}`
              );
            }
          } else if (
            response.body.capture_method === "manual" ||
            response.body.capture_method === "manual_multiple"
          ) {
            if (response.body.authentication_type === "three_ds") {
              if (response.body.next_action) {
                if (response.body.next_action.type === "invoke_ddc") {
                  expect(response.body.next_action)
                    .to.have.property("type")
                    .to.equal("invoke_ddc");
                  globalState.set(
                    "nextActionUrl",
                    response.body.next_action.ddc_data.iframe_url
                  );
                } else if (

View on GitHub (pinned to 9b8b89dc37)

Solutions

Log response.body.authentication_type and compare with what the request fixture asked for
Align the fixture's authentication_type with a modeled value ('three_ds' or 'no_three_ds')
If the API legitimately added a new type, extend the command's if/else chain to cover it
Confirm the payment method/connector actually supports the requested authentication flow

Example fix

// before — any unmodeled value throws with no context
} else {
  throw new Error(`Invalid authentication type ${response.body.authentication_type}`);
}
// after — fail with request context so the mismatch is obvious
} else {
  throw new Error(
    `Expected authentication_type 'three_ds'|'no_three_ds' for automatic capture, got '${response.body.authentication_type}' (request asked for '${body.authentication_type}')`
  );
}

Defensive patterns

Strategy: type-guard

Validate before calling

const AUTH_TYPES = ['three_ds', 'no_three_ds'];
if (!AUTH_TYPES.includes(data.Request.authentication_type)) {
  throw new Error(`Fixture uses unsupported authentication_type '${data.Request.authentication_type}'`);
}

Type guard

const isKnownAuthType = (v) =>
  typeof v === 'string' && ['three_ds', 'no_three_ds'].includes(v);
// usage: if (!isKnownAuthType(response.body.authentication_type)) fail with an explicit assertion

Prevention

Pin fixture auth types to the enums the command models
When adopting a new Hyperswitch version, diff enum sets (authentication_type, capture_method) first
Assert the response echoes the requested auth type before deep-diving the flow tree

When it happens

Trigger: The confirmed payment returns an authentication_type the command doesn't model: an API version adding a new enum; the response body shape drifting so authentication_type is missing/undefined; the server overriding the requested auth type for the chosen payment method or connector.

Common situations: A Hyperswitch upgrade introduces a third authentication_type; the fixture requests three_ds but the connector forces a different flow; response schema changes dropping the field.

Understand the failure class

Authentication and authorization failures — expired tokens, bad credentials, and missing scopes.

Related errors

AI-assisted analysis of juspay/hyperswitch@9b8b89dc37 (2026-08-16). Data as JSON: /api/errors/45913b9b747b3d07. Report an issue: GitHub.