Lists every supported processor.
GET
/api/processors
deprecated
Requires: Transactions.ProcessorConfiguration.ViewSchema, merchant scope.
Each entry carries its identifier, display name, and supported payment types.
Example request
Every block below sends the same request. Replace {{BASE_URL}} with the address of the API you are calling and {{API_KEY}} with your own key.
The request body is a . See the Request body section below for its fields.
Parameters
| Name | In | Type | Description |
|---|---|---|---|
suppressNulls
required |
query | boolean | If true, omit properties with null values. |
Request body
application/json
, required
| Field | Type | Description |
|---|
This request body has no documented fields.
Responses
200 OK
Body: array of ProcessorSummaryDto
Each item has these fields.
| Field | Type | Description |
|---|---|---|
processorId
required |
string | Stable identifier of the processor (e.g. "tsys"). Pass this to the config-schema endpoint and submit it as the processor configuration's `ProcessorId` on a merchant create/update. nullable |
processorName
required |
string | Display name of the processor. nullable |
supportedPaymentTypes
required |
array of string | Names of the payment types this processor supports (e.g. "Visa", "Mastercard", "EbtSnap"). These can be passed as the payment-types filter when requesting the config schema. nullable |
paymentTypes
required |
array of ProcessorPaymentTypeRefDto | The payment types this processor supports, as explicit `{id, name}` pairs. Use this to populate a profile's payment types deterministically without scraping the GUIDs off a live merchant document. The ids are global constants (identical across environments); a client may also submit a payment type by `name` alone and let the server resolve the id. nullable |
schemaVersion
required |
string | Opaque, deterministic content hash of this processor's full projected field schema: the same value returned (and emitted as an ETag) by the config-schema endpoint. Lets a client detect that a processor's schema changed from a single listing call, without re-fetching every schema. nullable |
This response has no documented body fields.
403 Forbidden
Body: RemoteServiceErrorResponse
Each item has these fields.
| Field | Type | Description |
|---|---|---|
error
required |
RemoteServiceErrorInfo |
This response has no documented body fields.
401 Unauthorized
Body: RemoteServiceErrorResponse
Each item has these fields.
| Field | Type | Description |
|---|---|---|
error
required |
RemoteServiceErrorInfo |
This response has no documented body fields.
400 Bad Request
Body: RemoteServiceErrorResponse
Each item has these fields.
| Field | Type | Description |
|---|---|---|
error
required |
RemoteServiceErrorInfo |
This response has no documented body fields.
404 Not Found
Body: RemoteServiceErrorResponse
Each item has these fields.
| Field | Type | Description |
|---|---|---|
error
required |
RemoteServiceErrorInfo |
This response has no documented body fields.
501 Not Implemented
Body: RemoteServiceErrorResponse
Each item has these fields.
| Field | Type | Description |
|---|---|---|
error
required |
RemoteServiceErrorInfo |
This response has no documented body fields.
500 Internal Server Error
Body: RemoteServiceErrorResponse
Each item has these fields.
| Field | Type | Description |
|---|---|---|
error
required |
RemoteServiceErrorInfo |
This response has no documented body fields.
default The request failed. The body carries the standard error envelope: a machine-readable `error.code`, a human-readable `error.message`, and `error.validationErrors` when the failure was a validation rejection. See the error-code reference in this document's description for the values `error.code` can take.
Body: RemoteServiceErrorResponse
Each item has these fields.
| Field | Type | Description |
|---|---|---|
error
required |
RemoteServiceErrorInfo |
This response has no documented body fields.
429 The request was refused because a rate limit was exceeded. Wait at least the interval `Retry-After` names before retrying, then back off. Limits are tuned per deployment, so read the allowance from the response headers rather than assuming a fixed ceiling.
Body: RateLimitProblemDetails
Each item has these fields.
| Field | Type | Description |
|---|---|---|
type
required |
string | The problem type identifier. Always the same value: the failure is the status code itself, so there is no sub-type for a caller to branch on. nullable |
title
required |
string | A short, human-readable summary of the problem type. nullable |
status
required |
integer (int32) | The HTTP status code, repeated in the body as the problem-details format defines. |
detail
required |
string | A human-readable explanation of this occurrence of the problem. nullable |
retryAfterSeconds
required |
integer (int32) | How long to wait before retrying, in whole seconds, carrying the same figure as the `Retry-After` header. Always at least one: a value of zero would invite an immediate retry that is certain to be rejected again. |
This response has no documented body fields.
Errors
A failed request returns the platform error envelope. The
error reference lists every value
error.code can carry and shows the four response shapes.