juspay/hyperswitch · error · Error

Invalid authentication type: ${response.body.authentication_

Error message

Invalid authentication type: ${response.body.authentication_type}

What it means

Guard-clause throw in the Cypress command createConfirmPaymentTest (cypress-tests/cypress/support/commands.js:4087), inside the branch for capture_method === 'automatic'. After a 200 create-and-confirm, the command only knows how to diff the response against resData when response.body.authentication_type is 'three_ds' or 'no_three_ds'; anything else throws. It indicates the created payment's authentication_type does not match the two combinations this fast-path validator implements.

Source

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

                  globalState.set(
                    "nextActionUrl",
                    response.body.next_action.redirect_to_url
                  );
                }
              }
              for (const key in resData.body) {
                expect(resData.body[key], [key]).to.deep.equal(
                  response.body[key]
                );
              }
            } else if (response.body.authentication_type === "no_three_ds") {
              for (const key in resData.body) {
                expect(resData.body[key], [key]).to.deep.equal(
                  response.body[key]
                );
              }
            } 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 (response.body.next_action.three_ds_data) {

View on GitHub (pinned to 9b8b89dc37)

Solutions

Log response.body.authentication_type and the x-request-id header and diff it against the fixture's requested authentication_type.
Fix the fixture to request 'three_ds' or 'no_three_ds' explicitly.
If the router now emits a third legitimate authentication_type, add an else-if branch with the expected response diff for it.

Example fix

// before
} else if (response.body.authentication_type === "no_three_ds") {
  for (const key in resData.body) { /* diff */ }
} else {
  throw new Error(`Invalid authentication type: ${response.body.authentication_type}`);
}

// after
} else if (response.body.authentication_type === "no_three_ds") {
  for (const key in resData.body) { /* diff */ }
} else {
  throw new Error(`Invalid authentication type: ${response.body.authentication_type} (request_id=${response.headers["x-request-id"]}, fixture_expected=${authentication_type})`);
}

Defensive patterns

Strategy: validation

Validate before calling

const supportedAuth = ["three_ds", "no_three_ds"];
if (!supportedAuth.includes(authentication_type)) {
  throw new Error(`createConfirmPaymentTest automatic branch supports only three_ds|no_three_ds, got '${authentication_type}'`);
}

Type guard

function isValidAuthenticationType(v) {
  return v === "three_ds" || v === "no_three_ds";
}

Try / catch

if (!isValidAuthenticationType(response.body.authentication_type)) {
  throw new Error(`Invalid authentication type: ${response.body.authentication_type} (request_id=${response.headers["x-request-id"]}, requested=${authentication_type})`);
}

Prevention

Validate the spec's authentication_type argument before invoking createConfirmPaymentTest.
Add schema assertions for enum fields early in the command so failures point at the field, not a fall-through throw.
Regenerate fixtures from a validated template instead of hand-editing enum strings.

When it happens

Trigger: POST /payments (create + confirm) returns 200 with capture_method 'automatic' and authentication_type not in {three_ds, no_three_ds}: e.g. the fixture's authentication_type is misspelled, the field is null in the response, or a new enum value was introduced by the router.

Common situations: Typo in a fixture (e.g. 'no3ds', 'no_three_ds ' with whitespace); running against a router build where authentication_type is absent for some connectors; adding a new auth flow without extending createConfirmPaymentTest.

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/f29538cf272c842c. Report an issue: GitHub.