PXP Financial

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

Capabilities

Supported input

Notification delivery

• Repeated deliveries are recognized by eventCode and systemTransactionId (only when eventCode is present); PXP Financial documents that notifications can be delivered more than once.
• Delivery order: not documented by the provider.
• PXP says duplicate webhooks share eventCode and systemTransactionId while eventDate can differ, and that the details of the latest delivery should be used. Events without an eventCode (most card, PayPal family, payout and 3DS events) have no documented duplicate key, so make the handler idempotent on systemTransactionId and state.

Known limitations

• PXP documents no chargeback, dispute or settlement events, and no chargeback or dispute API objects. Chargebacks cannot be shown on the timeline.
• Webhooks have no event id. Repeated deliveries are recognized only by eventCode and systemTransactionId, as PXP documents. Card, PayPal family, payout and 3DS events usually carry no eventCode, so their repeated deliveries are not recognized as duplicates.
• Many card and PayPal events carry no eventCode. Their event name (for example transaction-captured) is inferred from eventCategory, state, intent and funding type and marked with eventTypeInferred. Card refused and error events without eventCode are shown by state only.
• Captures, voids and refunds return a new systemTransactionId and PXP documents no parent field for cards or PayPal. Such modifications are shown as separate transactions and are never merged with the original by guesswork. originalSystemTransactionId links them only where it is present (Aeropay). merchantOrderId is never used as a link.
• Delivery order is not documented and PXP retries up to 10 times within 10 seconds. The timeline orders webhooks by eventDate, which can differ between copies of one event.
• Transaction responses carry no provider timestamp; merchantTransactionDate (merchant supplied) is used when it has a time zone. Timestamps without a time zone are not placed on the timeline.
• Field shapes drift between PXP examples (amounts.transaction, amounts.transactionValue and a singular amount object; flat or nested fundingData.card; eventCategory casing). All documented variants are read and the variant used is reported in attributes.
• The states Confirmed, Updated and Approved appear in the transaction enum without an explanation and stay unknown. A card refund response with state Authorised is shown as a successful refund authorisation; PXP gives no card refund webhook example.
• Pay-by-bank APM state codes (APM001 to APM013) and API errorCode values have no published definition table; their meanings come from PXP examples and are decoded with at most possible confidence. Unknown codes stay unknown.
• Raw acquirer codes in providerResponse.code depend on the acquirer and are not documented by PXP; they are shown but not interpreted. Mastercard merchantAdvice codes are shown but not interpreted.
• 3DS decoding uses authenticationState, transStatus and the documented reason codes only. The field that carries 3DS error codes (101 to 403) and challengeCancel meanings are not documented per value, so they are not decoded. 3DS events have no documented link to the card transaction.
• Token, reporting, user and test-connection webhooks are recognized but not analyzed. Token events cannot be told apart from the body. CVU and Bre-B transaction-context responses and client SDK codes (SDKxxxx) are not analyzed.
• Purchase and payout share pay-by-bank event codes; without transactionMethod.intent the operation of such an event is not known and it is shown as a payment.
• Card payout and verification responses are not exemplified by PXP. FlashFlow refunds and Aeropay payouts are not documented.
• Webhook signatures (X-Signature, X-Signature-Timestamp, X-Request-Id headers) are sensitive and are never verified; a pasted webhook is not treated as authentic. The hash function for the header signature is not named by PXP.
• Adult content is not a documented PXP sector. The high-risk vertical list describes PXP's partner programme, not per-merchant acceptance; eligibility depends on jurisdiction, licensing and underwriting.
• The transactions release notes are empty, so payload changes cannot be tracked by date.
• Category and retry guidance per code are PandaPayLens suggestions; PXP gives no per-code retry advice except for 3DS states and its idempotency on merchantTransactionId.

Examples

• PXP: card refused: A Transactions API response decoded from PXP's normalized CRD code.
• PXP: SPEI payout rejected: A bank payout reported as rejected; payouts are kept separate from deposits.

Provider documentation

• Transactions: how it works (states, card and APM codes)
• Transactions service OpenAPI
• API overview (HTTP statuses, idempotency, webhook retries)
• Modify transactions
• Get transaction details
• About webhooks
• Manage webhooks (duplicate handling)
• Merchant webhooks service OpenAPI
• 3DS authentication states
• SPEI transactions
• FlashFlow transactions

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