payabl.

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

Capabilities

Supported input

Notification delivery

• Repeated deliveries are recognized by transactionid, type, errorcode, payment_state and amount (payabl. documents no event id); payabl. documents that notifications can be delivered more than once.
• Delivery order: not documented by the provider.
• Make your notification handler idempotent per transactionid and type, and answer HTTP 200 with body OK so Auto-Retry stops resending.

Known limitations

• Gateway API responses do not say which operation (authorize, pre-authorize, capture, reversal, refund or CFT) produced them, so they are shown with the generic stage payment.
• Notifications have no event or delivery id. The delivery key is the field combination transactionid + type + errorcode + payment_state + amount; two genuinely different notifications with equal values (for example two equal partial refunds) are treated as repeated deliveries. Whether timestamp stays the same across retries is not documented, so it is not part of the key.
• Only the notification types order, capture and refund are documented. Reversal, CFT and chargeback notification types are not documented and are shown without lifecycle semantics; chargebacks are reported by email, the dashboard and the diagnose interface.
• A successful capture or refund means payabl. processed the operation, not that funds were settled. payment_state=credited means funds were received for an APM capture; settlement to the merchant is not documented as a payload state.
• One transactionid spans authorization, capture and refund, so events are grouped by it. Payouts (CFT) get a new transactionid that the response does not link to the original deposit. orderid is never used for correlation.
• Gateway, risk, issuer, raw Visa/Mastercard, Mastercard advice, APM, OCT and Web SDK codes share the status/errorcode field. Where a code has different meanings in different documented tables, confidence is reduced to possible and the alternatives are listed.
• EPS codes (021, 009, 005, 010) are decoded with possible confidence: the EPS payment_method id is not documented in the PandaPayLens research.
• payabl. code lists are not exhaustive; codes outside them are reported with insufficient confidence.
• The notification signature (security) and the request signature are never verified, copied or reported; only the signature length class is shown.
• XML responses (tx_diagnose, send_notification), Mobile SDK JSON and notifications converted to JSON are not analyzed. The Web SDK browser callback is recognized but not analyzed, because payabl. says it must not be used to update merchant systems.
• Notification field sets are configurable per merchant; content type, charset and delivery order are not documented.
• Notification timestamps are used as event time only when they are 10-digit Unix seconds.
• Copies of documentation examples with the rendering defects ¤cy= and ×tamp= are repaired and flagged.

Examples

• payabl.: authorized order notification: A form-encoded order notification for a successful authorization.
• payabl.: declined, insufficient funds: A form-encoded Gateway API response for an issuer decline.
• payabl.: timeout with unknown outcome: A Gateway API response where the result of the request is not known.

Provider documentation

• Response codes
• Error codes for credit cards
• CFT response codes
• Mastercard merchant advice codes
• APM error codes
• 3DS transaction status reason codes
• Retry notification / callback
• Signature calculation
• Authorization
• Pre-authorization

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