EBANX

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

Capabilities

Supported input

Notification delivery

• Repeated deliveries are recognized by operation and payment hash for update notifications, or operation and payout uid for payout notifications (EBANX sends no event or delivery id); EBANX documents that notifications can be delivered more than once.
• Delivery order: not documented by the provider.
• An EBANX notification only says that a payment changed; it carries no status. Reply HTTP 200 at once, then call /ws/query with the hash and act on the returned state. Querying is idempotent, so a repeated delivery is harmless when the handler always reads the current state. Do not drop refund or chargeback notifications as duplicates: a second refund produces an identical body.

Known limitations

• A payment notification carries only operation, notification_type and hash_codes: no status, amount, timestamp or event id. It is shown as a signal to check the payment (outcome unknown), never as a success or failure. The payment state comes from a matching /ws/query response.
• Notifications have no delivery id. A repeated update notification for the same hash is treated as a redelivery, because a payment reaches CO or CA only once. Refund, chargeback and chargeback_credit notifications get no delivery key, because two different refunds or chargebacks produce identical bodies. Retry schedule, ordering and source IPs are not documented.
• Several codes have two documented meanings depending on the page or endpoint (BP-R-3 to BP-R-6, BP-DR-9, BP-DR-62, BP-DR-63, BP-DR-132, BP-REF-41, and BP-DR-17, BP-DR-18 and BP-DR-20 in the NuPay examples). Both meanings are shown with possible confidence; status_message is used only as a hint. The token endpoint reuses BP-DR codes with token-specific wording that is not covered.
• Card and APM description_code tables share some values with different meanings (for example INVALID_DUE_DATE). The table is chosen from payment_type_code (creditcard and visa for cards; boleto, pix, pix-automatico, oxxopay and spei for APMs) and from card-only fields; when neither applies, both meanings are shown with possible confidence.
• EBANX says transaction_status.code must not be used to confirm a payment; payment.status is authoritative. A successful API envelope (status SUCCESS) can describe a cancelled or declined payment.
• Without capture_available or pre_approved, a CO response from /ws/capture cannot be told apart from an auto-captured /ws/direct payment, and a partial capture reports only the captured amount. CO is shown as a confirmed payment, not as settlement; transfer_date is shown as the documented settlement date.
• Dates are YYYY-MM-DD HH:mm:ss without a zone; they are read as UTC, as the OpenAPI descriptions state. Placeholders such as {{YYYY-MM-DD HH:mm:ss}} and {{unique_payment_hash}} from documentation examples are recognized and not used as values.
• Error envelopes carry no payment hash, so a capture, cancel or refund error cannot be linked to its payment. merchant_payment_code is never used for correlation. HTTP 401, 429, 500, 503 and 504 responses without an EBANX body cannot be attributed to EBANX.
• Refunds listed in several pasted /ws/query responses appear once per response, because API responses have no delivery key.
• ISO 8583 and MAC codes appear only for merchants that enabled them, in seven countries; EBANX warns that issuers interpret ISO codes differently, so an ISO code alone is decoded with possible confidence. A Mastercard MAC code makes the retry guidance stricter, never looser.
• Payout statuses CM, AD, AW and RE are documented only on the payout notification page. Canceled-payout reason codes (code, message, gateway_details) are not analyzed because where they appear is not documented. Verify-account, balance transfer and payee responses are not analyzed.
• Enrollment notifications, token and card verification responses, enrollment queries, chargeback evidence responses, settlement and chargeback report files are not analyzed. Enrollment reason codes are not decoded.
• Notification signatures (X-Signature-Content, X-JWS-Signature) are never verified or copied; a pasted notification is not treated as authentic.
• When EBANX processes for Braintree, Worldpay or other partners, the merchant receives the partner's format; those payloads are not EBANX payloads and are not detected here.
• Category and retry guidance per code are PandaPayLens suggestions; where EBANX gives advice (retry at any time, do not retry) it is reflected, but a retry is shown as safe only when the payment status already shows that the attempt failed (CA); otherwise /ws/query must confirm the state first.

Examples

• EBANX: authorization, capture and refund: A card payment authorized, captured and partially refunded in one timeline.
• EBANX: card declined, insufficient funds: A decline inside a successful envelope, with ISO and Mastercard advice codes.

Provider documentation

• Pay-in API error codes
• Card error codes
• APM error codes
• ISO 8583 and Mastercard MAC codes
• Pay-in OpenAPI
• Payment notifications
• Retrieve a payment (/ws/query)
• Refund a payment
• Cancel a payment
• Chargebacks and disputes
• Credit cards (authorization and capture)
• Sandbox system failure simulation
• Payout error codes
• Payout notifications
• Channels and partners

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