juspay/hyperswitch · error · Error

Expecting valid response but got an error response

Error message

Expecting valid response but got an error response

What it means

Thrown by defaultErrorHandler in cypress-tests/cypress/e2e/configs/Payment/Utils.js when the API answered with an error body but the test's expected response_data.status is 200 — i.e. the spec asserted success and the connector errored. (For 'Payment method type not supported' 400s it first rewrites the expected status via updateDefaultStatusCode().)

Source

Thrown at cypress-tests/cypress/e2e/configs/Payment/Utils.js:341

    typeof resData.body.error_message !== "undefined"
  ) {
    return false;
  } else {
    return true;
  }
};

export function defaultErrorHandler(response, response_data) {
  if (
    response.status === 400 &&
    response.body.error.message === "Payment method type not supported"
  ) {
    // Update the default status from 501 to 400 as `unsupported payment method` error is the next common error after `not implemented` error
    response_data = updateDefaultStatusCode();
  }

  if (response_data.status === 200) {
    throw new Error("Expecting valid response but got an error response");
  }

  expect(response.body).to.have.property("error");

  if (typeof response.body.error === "object") {
    for (const key in response_data.body.error) {
      // Check if the error message is a Json deserialize error
      const apiResponseContent = response.body.error[key];
      const expectedContent = response_data.body.error[key];
      if (
        typeof apiResponseContent === "string" &&
        apiResponseContent.includes("Json deserialize error")
      ) {
        expect(apiResponseContent).to.include(expectedContent);
      } else {
        expect(apiResponseContent).to.equal(expectedContent);
      }
    }

View on GitHub (pinned to 9b8b89dc37)

Solutions

1. Read the actual API error (response.body.error) in the Cypress command log / network tab to identify the real cause
2. If the connector legitimately cannot succeed for this case, update the spec's response_data.status to the actual expected code instead of 200
3. Verify merchant/connector config: API keys valid, payment method enabled, correct capture_method/amount
4. Exclude the connector from this spec via its connector exclusion list when the flow is unsupported by design

Example fix

// before (spec expects success but connector declines)
const defaultResponse = { status: 200, body: { ... } };

// after (expect the realistic decline for this connector)
const defaultResponse = {
  status: 400,
  body: { error: { message: 'Payment method type not supported' } },
};

// Align expected status with the connector's real capability before the call
const NOT_IMPLEMENTED_CONNECTORS = new Set(['connector_x' /* ... */]);
if (NOT_IMPLEMENTED_CONNECTORS.has(connectorId) || !supportsPaymentMethod(connectorId, paymentMethodType)) {
  response_data = { ...response_data, status: 501, body: { error: { message: 'Not Implemented' } } };
}

// In the spec: distinguish 'expected-success-but-errored' from real regressions
cy.get('@postCall').then((response) => {
  try {
    defaultErrorHandler(response, response_data);
  } catch (e) {
    if (String(e.message).includes('Expecting valid response but got an error response')) {
      // connector declined/unsupported: inspect response.body.error and update config or skip
      cy.log(`Connector error: ${JSON.stringify(response.body.error)}`);
      this.skip();
    } else {
      throw e;
    }
  }
});

When it happens

Trigger: A payment/conf spec configured with response_data.status = 200 hits a real error: connector credentials invalid, payment method disabled for the merchant, amount/currency rejected, or a 501 'not implemented' — expect(response.body).to.have.property('error') context shows the actual error, but this throw fires first because 200 was expected.

Common situations: Test matrix runs a connector that does not support the spec's payment method; sandbox connector keys rotated/expired; a regression that broke a previously-green flow; expected-status fixture not updated after connector behaviour changed.

Related errors

• Unsupported connector: ${connectorId}
• Unsupported payment method type: ${payment_method_type}
• Invalid authentication type ${response.body.authentication_t
• Expected no deny action for non-blocklisted card
• Failed to fetch QR code image: ${response.statusText}

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