DECTA

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

Capabilities

Supported input

Notification delivery

• Repeated deliveries are recognized by none documented (webhooks carry no event id; the body id is the order id, and order id with the X-Webhook-Event header and the latest status_changes entry is only a heuristic).
• Delivery order: not documented by the provider.
• DECTA documents no webhook event id, retry schedule or ordering. Make the handler idempotent on the order id and the order status, and confirm the current status with GET order before acting.

Known limitations

• DECTA publishes no complete Order response or order.* webhook body; field presence is taken from the OpenAPI schema and depends on response_type (minimum, standard or full).
• The webhook event name travels only in the X-Webhook-Event header. A pasted body without its headers is analyzed from the order status, and order.* and oct.* events cannot be told apart from an API response.
• v0.6 webhooks carry no signature (hmac_key is reserved for v1.0, which is in development), so a pasted webhook is never treated as authentic. DECTA's advice is to accept only its static source IPs and to confirm the status via the API.
• Webhooks carry no event id, and the retry schedule, acknowledgement rules and delivery order are not documented. No delivery key is set, so repeated deliveries are not reported as duplicates; they are grouped with the order by its id.
• The timestamp keys inside status_changes, processing_status, errors and three_d_secure_status appear as true in the OpenAPI YAML and their wire name is not documented, so they are not read. Order events carry no event timestamp and follow the input order; the documented order timestamps (issued, viewed, captured, paid, cleared, settled) are shown as attributes when they are ISO 8601 strings with a time zone.
• The unit and format of order amounts (status_changes operation_amount, amount_refunded and similar) are not documented in the reviewed sources, so amounts are shown as supplied and are not converted to minor units. Amount consistency checks therefore do not run for DECTA.
• status_changes is shown as a status history on the order event (oldest first, as documented); it is not split into separate events because its entries carry no readable timestamp.
• The documentation's status table has labels (Refund initiated, Refund failed, Representation, Pre-arbitration, Compliance and others) whose wire values are not documented; such statuses are shown as unknown. withdrawn is a documented value without a documented meaning.
• order.refund_in _progress and order.reversal_in _progress are printed with a space in the documentation and are recognized only in that spelling. The event spelling order.canceled differs from the status cancelled.
• A paid status is shown as a capture only when the status history contains hold first (two-step payment). Payout orders can only be told apart from payments by an oct.* webhook header.
• Raw acquirer codes are decoded from transaction_details.processing_status.code (order) and the top-level processing_status (Host2Host, 3-D Secure and wallet responses). The field that carries the special code -1 is not documented. The vocabularies of transaction_details.errors[].code and fraud_check_status.code are not documented; such codes are shown without interpretation.
• Codes 198, 951 and -1 have several possible meanings and are decoded with possible confidence. Mastercard Merchant Advice Codes are not returned by every acquirer; when present, the stricter of the code's and the advice code's retry guidance is used.
• AVS letters, card name validation results and the ECI comparison are informational; DECTA makes no automatic decision on AVS. ECI values themselves are not copied.
• The response code page mentions a response_code field with Refused or Cancelled, but no such field exists in the OpenAPI schema; it is not read.
• API validation errors list field names with { message, code }; only the code invalid appears in DECTA's examples and the full list is not documented. Plain-text 400 descriptions are matched only when they arrive inside such an object.
• Orders are linked only by the order id. Recurring payments are not linked to the original payment (trace_id, cof_trace_id and transaction_link_id are not used as keys), and the subscription id on an order is not documented; from_subscription orders are marked as recurring, including the first order of a subscription.
• Host2Host and 3-D Secure step responses carry no order id, so they cannot be linked to the order. Their capability URLs (next_step_url, threed_check_url, redirectToACSForm) are never copied.
• card.* webhooks, deprecated v0.5 webhooks, Payform SDK browser events, Charge objects, alternative payment method failure reasons and the DECTA Hub APIs are not analyzed.
• Category and retry guidance per code are PandaPayLens suggestions that follow DECTA's status groups: for 1xx and 2xx refusals the cardholder contacts the issuer; for 9xx codes the merchant contacts DECTA technical support.

Examples

• DECTA: hold, capture and refund: One order moving from a hold to a capture and a refund.
• DECTA: payment failure webhook: An order.payment_failure webhook with a raw acquirer code decoded as insufficient funds.

Provider documentation

• Raw acquirer response codes
• Webhooks
• General payment flow and order statuses
• After the payment (Merchant Advice Codes, AVS, ECI, name validation)
• 3-D Secure authentication
• Integration options
• Simple payment scenarios (one-step, two-step, refunds, reversal)
• Recurring payment scenarios
• Payout scenarios
• Testing and going live
• Security
• Decta Gate API (OpenAPI 3.0.3, v0.6)

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