PayPal Braintree plugin
The retained predecessor material identifies a PayPal Braintree child under Plugin settings. That is historical runtime-fixture evidence; it is not proof that the plugin is installed, enabled, configured, or served by a current deployment.
Historical field inventory
The predecessor fixture recorded labels for Braintree environment selection; production and sandbox merchant, public-key, private-key, PayPal client, and Google Pay identifiers; Forter controls; free-delivery promotion data; SFTP connection fields; and PGP enablement or public-key material.
Those labels are preserved as a historical inventory only. The fixed Dashboard and API source trees do not contain an authoritative Braintree plugin configuration schema that establishes the current labels, required state, defaults, validation, save semantics, or provider effects. Core PayPal helpers and downstream Braintree references in order or payment consumers do not supply that missing plugin authority.
The generic Plugin settings editor stages ordinary fields and updates them sequentially, while an image field can write immediately. This is a shared source-defined write class only; it does not prove that a current Braintree form exists or that any historical field uses a particular control or save path.
Provider and data boundary
Payment, fraud, promotion, file-transfer, encryption, webhook, and credential behavior is external or deployment-dependent. No provider connection, credential check, charge, refund, promotion, transfer, webhook, encryption operation, or production configuration was exercised for this guide.
Merchant identifiers, public or private keys, client tokens or secrets, webhook secrets, fraud-provider secrets, SFTP credentials, PGP material, endpoints, transaction IDs, customer or payment data, and provider responses must not be captured or published.
Evidence boundary
The existing screenshot is retained as historical navigation media and does not show or validate a configuration form. A future approved synthetic fixture would need immutable deployment identity and exact field, validation, persistence, error, rollback, and provider-effect receipts under deny-all external access.
Until that evidence exists, no claim is made about current installation, checkout availability, authorization, capture, refunds, webhooks, provider connectivity, successful persistence, or production behavior.
Related guides: Online payments · Developers · Plugin settings