Ecommpay

Adapter 0.1.0, documentation reviewed 2026-10-25. Overall status: limited.

Capabilities

Error decoding	supported
API response parsing	supported
Webhook / notification parsing	limited
Timeline	limited
Event correlation	supported
Diagnostic rules	limited

Supported input

Format	Description	Status
`ecommpay.callback`	Gate payment callback (project_id, payment, single operation, signature); per-project field configuration, no event type	limited
`ecommpay.payment_status`	Gate payment status response (/v2/payment/status) with payment, operations[] and errors[]	supported
`ecommpay.request_error`	Gate request-level error body { status: error, code, message }	supported
`ecommpay.request_accepted`	Gate asynchronous acceptance { status: success, request_id, project_id, payment_id }	supported
`ecommpay.chargeback_callback`	Chargeback summary and detailed callbacks (unsigned, daily, never resent)	limited
`ecommpay.token_callback`	Token callbacks (tokenize, token_revoke); recognized but not analyzed	unsupported
`ecommpay.payment_page_events`	Payment Page JavaScript events (different shape)	unsupported
`ecommpay.data_api`	Data API (specification not reviewed)	unsupported

Notification delivery

Repeated deliveries are recognized by none documented (callbacks carry no event id or delivery id; operation.id with operation.status and operation.date is only a heuristic); Ecommpay documents that notifications can be delivered more than once.
Delivery order: not documented by the provider.
Ecommpay resends a callback until it gets HTTP 200 (up to 120 attempts within about 11 days), and a resend can carry newer data if the status changed. Make the handler idempotent on payment.id, operation.id and operation.status, and read the current state with a status request before acting.

Known limitations

Callbacks have no event type field. The event is inferred from operation.type and operation.status (with payment.status shown as an attribute) and is marked with eventTypeInferred.
Callback fields are configurable per project: optional fields can be added, removed or renamed. Only project_id, payment.id, payment.type, payment.status, operation.type and operation.status are required for analysis; renamed fields are not recognized.
Callbacks carry no delivery id. Ecommpay documents resends, and a resend may carry newer data, so no delivery key is set and repeated deliveries are not reported as duplicates; they are grouped with the payment by payment.id and operation.id.
Delivery order is not documented. The timeline uses operation.date (format YYYY-MM-DDThh:mm:ss+0000).
Chargeback callbacks are unsigned, are sent once a day and are never resent. Only the documented fields are read (event, event_date, chargeback_count, chargebacks[].chargeback_id, case_id, operation_id, card_type, chargeback_status, reason_code). Chargeback amount and date field names are not documented, so they are not read; reason codes are shown without interpretation and the full chargeback_status list is not documented.
Summary chargeback callbacks carry only counts and cannot be linked to a payment. Detailed chargebacks are linked to the disputed operation only through chargebacks[].operation_id.
Signatures (signature, general.signature) are sensitive and are never verified, copied or reported. A pasted callback is never treated as authentic.
Events are linked by payment.id (merchant assigned, unique per project, compared case-insensitively) and operation.id. payment.id is unique only within a project; records from different projects that reuse a payment id would be grouped together. Recurring payments are not linked to their COF registration.
Codes come from operation.code (string), errors[].code (integer in the OpenAPI schema, a string in examples) or the top-level code of a request error; all three are decoded. Ecommpay does not say the code list is exhaustive, so unknown codes are reported with insufficient confidence.
Codes 602, 10602 and 20602 (network error and timeouts) are shown as retry_conditionally, not as the technical retry the research suggests, because the outcome at the external service is unknown.
Code 3201 means payment routing error in the code table, but a status request example pairs it with a field validation message; it is decoded with possible confidence.
Provider result codes in operation.provider.result_code are provider specific and are shown without interpretation.
payment.type values are not documented as a list, so the stage comes from operation.type only. account_verification (payment.type) and account verification (operation.type) are spelled differently in the documentation.
Status responses that use a single operation object instead of operations[] are recognized when they also carry last_failed_request or arrive as an HTTP response; last_failed_request is not analyzed because its fields are not documented.
Token callbacks, Payment Page JavaScript events and the Data API are not analyzed.
The documented sectors are only those on readable developer portal pages; the marketing site's industry pages could not be read. Gambling appears only in payout limit code texts (MCC 7995/9406), which is not a statement that gambling merchants are accepted. Eligibility depends on jurisdiction, licensing and underwriting.
Category and retry guidance per code are PandaPayLens suggestions that follow Ecommpay's Action column where it gives one.

Examples

Ecommpay: authorization and capture: Gate callbacks for an auth and a capture of one payment.
Ecommpay: payout declined: A declined payout callback, kept separate from deposits.

Provider documentation

PandaPayLens is not affiliated with Ecommpay. Pasted notifications are never treated as verified: PandaPayLens does not check webhook signatures.