Braintree

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

Capabilities

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

Supported input

Format	Description	Status
`braintree.graphql.response`	GraphQL API response bodies (data, errors[].extensions with errorClass and legacyCode, transactions with statusHistory)	supported
`braintree.transaction`	Transaction snapshots: SDK objects in snake_case or camelCase, SDK result objects with a transaction, and GraphQL Transaction or Refund objects	supported
`braintree.sdk.validation_errors`	SDK result objects with validation errors (attribute, code, message)	limited
`braintree.webhook.notification`	Webhook notifications already parsed by a Braintree SDK (kind, timestamp, subject)	limited
`braintree.webhook.signed`	Raw form-encoded webhook deliveries (bt_signature, bt_payload); recognized, not decoded	unsupported

Notification delivery

Repeated deliveries are recognized by no documented notification id; Braintree documents that notifications can be delivered more than once.
Delivery order: not guaranteed by the provider.
Braintree retries a notification until your endpoint answers with a 2xx status within 30 seconds, and notifications can arrive out of order. Make the handler idempotent and order state changes by the notification timestamp.

Known limitations

Raw webhook deliveries (bt_signature and bt_payload) are recognized but not decoded or verified: verification needs the merchant's private API key. Parse the notification with a Braintree SDK and paste the parsed notification instead.
Decoded webhook XML is not accepted; PandaPayLens reads JSON and form data only.
Card, PayPal, Venmo and wallet transactions produce no transaction webhooks; only ACH and SEPA Direct Debit settlements do. Timelines come from the supplied snapshots and statusHistory entries, and missing states are not inferred.
A statusHistory without timestamps (as in some GraphQL responses) is shown as one snapshot event that lists the statuses.
Braintree documents no notification id, so repeated deliveries of the same notification are not identified (no delivery key).
Correlation uses explicit ids only: transaction id, refunded transaction id, refund ids and the dispute's transaction id. Legacy ids and GraphQL ids differ; they are linked only when one record carries both (legacyId or graphql_id). GraphQL ids are never decoded.
Order ids, retried transactions, duplicateOf links and disbursement transaction lists are not used for correlation.
The JSON serialization of SDK objects is not documented. snake_case and camelCase field names are accepted; other spellings (for example .NET PascalCase) are not recognized.
Category and retry mappings are PandaPayLens proposals derived from the documented descriptions and Hard/Soft decline types.
Only 12 of the documented Transaction validation codes are mapped individually; other codes are decoded by GraphQL errorClass or as a generic validation error.
GraphQL errorClass values have no published descriptions; their mapping is a PandaPayLens proposal.
Five GraphQL gateway rejection reasons are documented by name only.
Codes 2109 to 2999 share one generic Processor Declined meaning.
ACH return codes are shown but not decoded; network response codes and merchant advice codes are not decoded.
Braintree-specific diagnostic rules are not implemented; only the generic rules run.

Examples

Braintree: processor declined: A GraphQL response where the decline is a transaction in data, not an error.
Braintree: sale, refund and dispute: Transaction snapshots linked by transaction and refund ids, built from status history.
Braintree: signed webhook (not decodable): A raw bt_signature/bt_payload webhook. PandaPayLens explains what to paste instead.

Provider documentation

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