Get Merchant Status (Extended)

Returns the current status of a merchant application using an extended response schema. Unlike GET /api/v1/merchant/status, this endpoint returns a StatusResult object directly (not wrapped in ApiResponse1) and includes a full enumeration of all possible status values spanning the entire merchant lifecycle — from draft through underwriting, MPA processing, and processor boarding. It also includes explicit success and validationErrors fields.

Endpoint

GET /api/v1/merchant/status2

Authentication

Basic HTTP Authentication required.
Encode username:password in Base64 and pass in the Authorization header:

Authorization: Basic {base64(username:password)}

When to use

Use this endpoint when you need the complete status taxonomy of a merchant application, including states such as "MPABoarded", "Underwriting", "PendingPreUw", and processor-specific states like "ElavonSigned". This endpoint is preferred when building integrations that need to react to a wider range of status transitions than what status returns.

Query Parameters

Response

200 OK

The response is a StatusResult object directly (not wrapped in the standard ApiResponse1 envelope).

Full status enum values:

{
  "mid": "4280001234567",
  "status": "MPABoarded",
  "statusDate": "2026-05-20T11:00:00Z",
  "success": true,
  "error": null,
  "validationErrors": [],
  "requestId": 110294
}

Example — Application pending changes:

{
  "mid": null,
  "status": "RequestChanges",
  "statusDate": "2026-05-18T14:22:00Z",
  "success": false,
  "error": "Missing voided check for bank verification",
  "validationErrors": [
    {
      "field": "businessCheckingRoutingNumber",
      "error": "Routing number does not match bank records"
    }
  ],
  "requestId": 110101
}

Error Codes

Common Mistakes

• Note that this endpoint returns a StatusResult directly, not the standard ApiResponse1 wrapper used by most other endpoints — the response schema is different from GET /api/v1/merchant/status.
• Not handling the full range of status enum values — build your integration to handle unknown values gracefully, as new statuses may be added.
• Confusing validationErrors (an array of {field, error} objects) with validationResults from other endpoints (which use {memberNames, errorMessage} instead).
• Assuming success: true means the merchant is approved — success reflects whether the last status-setting operation succeeded, not the merchant's approval state.

Related Endpoints

• GET /api/v1/merchant/status — simpler status endpoint that returns the standard ApiResponse1 wrapper with StatusResponse data
• POST /api/v1/merchant/submit — submit the merchant application for review
• POST /api/v1/merchant/updateStatus — update a merchant's status (admin use)

Example

curl -X GET "https://hq.staging.netevia.dev/api/v1/merchant/status2?id=10045" \
  -H "Authorization: Basic $(echo -n 'username:password' | base64)" \
  -H "Accept: application/json"