Get Current Merchant Status

Retrieves the current status of a merchant application in the payment processing system. The response includes the status label, the date the status was last updated, an optional comment explaining the status change, and the merchant's MID (Merchant Identification Number) if the account has been approved and assigned one. This is the primary polling endpoint for tracking a merchant's progress through the boarding lifecycle.

Endpoint

GET /api/v1/merchant/status

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 to check where a merchant application stands in the boarding workflow — from initial submission through underwriting, approval, and activation. Poll this endpoint periodically after submitting a merchant to detect status transitions such as "Pending" to "Approved" or "RequestChanges". For a richer status object with a full enum of possible states, see GET /api/v1/merchant/status2.

Query Parameters

Response

200 OK

The data object is of type StatusResponse.

{
  "data": {
    "status": "Approved",
    "statusDate": "2026-05-15T09:30:00Z",
    "comment": "Application approved. MID assigned and terminal staging in progress.",
    "mid": "4280001234567"
  },
  "status": "OK",
  "error": null,
  "warning": null,
  "validationResults": [],
  "requestId": 103847
}

Example — Pending with comment:

{
  "data": {
    "status": "RequestChanges",
    "statusDate": "2026-05-14T16:45:00Z",
    "comment": "Please provide a copy of the voided check and update the bank routing number.",
    "mid": null
  },
  "status": "OK",
  "error": null,
  "warning": null,
  "validationResults": [],
  "requestId": 103201
}

Error Codes

Common Mistakes

• Polling too frequently — status changes are not real-time; implement exponential backoff or reasonable polling intervals.
• Assuming data.mid will always be populated — the MID is only assigned after the merchant is fully approved and boarded by the processor; it will be null in earlier states.
• Not checking data.comment — when status is "RequestChanges", the comment field typically explains what needs to be corrected.
• Confusing this endpoint with GET /api/v1/merchant/status2 — status2 returns a richer response object with a broader enum of status values and explicit success/error fields.

Related Endpoints

• GET /api/v1/merchant/status2 — alternative status endpoint with a richer enum of status values
• POST /api/v1/merchant/submit — submit the merchant application for processing
• POST /api/v1/merchant/updateStatus — update a merchant's status (admin use)

Example

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