Airwallex

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

Capabilities

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

Supported input

Format	Description	Status
`airwallex.error`	Payments Client API error body (code, message, source, trace_id, details, provider_original_response_code), including declines and HTTP 401, 404, 429 and 500 errors	supported
`airwallex.payment_intent`	PaymentIntent snapshots (int_ ids) with the embedded latest_payment_attempt and its failure_code, failure_details, issuer response code and Merchant Advice Code	limited
`airwallex.payment_attempt`	PaymentAttempt snapshots (att_ ids)	limited
`airwallex.refund`	Refund snapshots (rfd_ ids)	supported
`airwallex.payment_dispute`	PaymentDispute snapshots (dst_ ids) with stage, status, mode and reason; the older dispute webhook shape (dispute_id, dispute_amount) is read as an alias	limited
`airwallex.webhook`	Payments webhooks (id, name, data.object, created_at, version) for payment_intent., payment_attempt., refund.* and payment_dispute.* events; other documented payments events are shown without lifecycle semantics	limited
`airwallex.payout_webhook`	payout.transfer.* and payout.batch_transfers.* webhooks; recognized, not analyzed	unsupported
`airwallex.transfer`	Payout Transfer objects; recognized, not analyzed	unsupported
`airwallex.js`	Airwallex.js and mobile SDK client-side error callbacks; not analyzed	unsupported

Notification delivery

Repeated deliveries are recognized by event id; Airwallex documents that notifications can be delivered more than once.
Delivery order: not guaranteed by the provider.
Airwallex retries until it receives HTTP 200 (exponential back-off over about three days) and keeps the event id unchanged across retries. Record processed event ids, and order events by created_at instead of arrival order. Whether a manual re-trigger keeps the same id is not documented.

Known limitations

Only the Payments Client API JSON (PaymentIntent, PaymentAttempt, Refund, PaymentDispute, the error body) and payments webhooks are analyzed. Payout transfers and payout webhooks are recognized but not analyzed in this version, and transfer error codes (for example validation_failed with details.errors[]) are not decoded.
Issuer response codes depend on the card brand: 14 code strings have different meanings per brand. The brand is read from details.card_brand (error body) or payment_method.card.brand (attempt). Without a brand, every brand meaning is shown and the decode is marked possible. Only lowercase brand names such as visa and mastercard appear in Airwallex's examples; other brand spellings are matched by name.
Codes from local payment method providers (provider_declined with a provider's own provider_original_response_code) are not published by Airwallex and are shown without a meaning. The meaning of operation_above_limit is not documented. Airwallex.js browser error codes are not analyzed.
PaymentAttempt failure_code values have no descriptions in the documentation, and Airwallex publishes no example of a FAILED attempt with failure_details; decoding them follows the value names and the documented schema. The link between the five failure events and failure_code is inferred from the names.
The value set of authentication_data.avs_result and cvc_result is not documented (the API reference shows pass, webhook examples show U). Single-letter values are explained from the AVS and CVC tables; other values are shown as supplied.
Webhook envelope examples disagree: account_id or accountId, missing created_at and version, and event ids as evt_ digits, 32 hex characters or a UUID. When created_at is missing, the object's updated_at is used as the event time. Payload fields depend on the API version (x-api-version and the subscription version); no per-version change log for payments was found.
A PaymentIntent snapshot embeds only the latest attempt and carries no status history. Airwallex says the intent status list is not exhaustive and that the intent status is only typically linked to the latest attempt (its own examples show a SUCCEEDED intent with an AUTHORIZED attempt). Unknown statuses are shown as unknown.
Snapshot event times use the object's updated_at, which is the time of the last change, not necessarily of the status shown.
The event id is used as the delivery key; Airwallex documents it as stable across retries. Delivery order is not guaranteed.
Payments are linked by the PaymentIntent id and the PaymentAttempt id (payment_intent_id and payment_attempt_id on attempts, refunds and disputes). merchant_order_id may be reused and is never used for linking. The attempt id suffix pattern seen in examples is not documented and is not used.
Older dispute webhooks (dispute_id, dispute_amount, status EVIDENCE_REQUIRED, stage DISPUTE) are read with their own values; which API version produces that shape is not documented.
Documented payment_consent, payment_method, customer, payment_link, fraud and funds_split events are shown without lifecycle semantics. POS terminal events are not recognized.
The x-signature header cannot be verified from pasted data, so a pasted webhook is never treated as authentic. Only the presence of the header is reported.
Category and retry guidance per code are PandaPayLens suggestions; where Airwallex gives advice (for example retry later, or Merchant Advice Code 02: retry after 72 hours), the guidance follows it. Error messages are marked by Airwallex as subject to change and are never parsed.

Examples

Airwallex: card payment webhooks: From creation through authorization, capture and settlement to a partial refund.
Airwallex: payment declined by the issuer: A PaymentIntent whose latest attempt failed, decoded with the card brand, AVS and CVC results.

Provider documentation

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