connection type braintree

Veliro + Braintree

Forward Braintree charges using Veliro tok_* instead of Braintree payment method nonces for stored credentials. PayPal-owned stack, merchant-owned tokens.

Braintree (a PayPal service) is common in US e-commerce and marketplaces. Its vault stores payment methods tied to Braintree merchant accounts, excellent for PayPal wallet flows, but another silo if Braintree is your only stored-credential system.

Veliro connection type braintree takes merchant ID and API keys, then accepts forward requests with tok_* and cryptograms. Subscriptions and marketplace payouts keep a stable Veliro reference while Braintree remains the authorization rail you configure.

Teams on Braintree + PayPal often keep PayPal wallet buttons on Braintree’s stack while moving card-on-file to Veliro tok_* for portability. That split is intentional: wallets follow PSP wallet rules; cards follow your TRID.

Braintree’s status as a PayPal property means roadmap and pricing change with PayPal corporate strategy, another reason to keep tokens outside the vault you do not control.

Setup

  1. Configure Braintree credentials

    POST /v1/connections with type braintree, merchant_id, public key, and private key from the Braintree control panel.

  2. Provision via Secure Fields

    Avoid sending PAN to your server; JWE from Secure Fields keeps SAQ-A posture while creating tok_* under your TRID.

  3. Forward with idempotency

    Use Idempotency-Key on forward for Braintree charges; subscription renewals retry aggressively on timeouts.

Forward & portability notes

  • Marketplace models may need one Braintree connection per sub-merchant; tok_* still lives under the platform Veliro merchant_id if that matches your compliance model.
  • When migrating off Braintree, leave connections active until forward traffic drains; do not delete tokens prematurely.
  • Braintree test vault behavior differs from production; validate forward in sandbox before cutover.

Route Braintree in sandbox.

Register a connection, provision tok_* via Secure Fields, and forward your first charge, same credential reference when you add a backup acquirer.