Magento Open Source Braintree integration

Magento Open Source Braintree integration: what it covers and how it connects

For a self-hosted Magento Open Source store, the bundled Braintree extension is the supported path for taking cards and digital wallets through Braintree. It is the part of the store that talks to Braintree: it controls which payment methods appear at checkout, holds the merchant credentials for each environment, and passes payment requests between the storefront, the Magento admin and Braintree's gateway. Before you configure anything, confirm the exact extension name, the admin location of its settings and which methods are available in the Adobe documentation for the release you run. Also confirm method availability by country and currency against Braintree's own account terms, because both can change.

Four components are involved, and each has a different owner. The Magento admin holds the configuration, including enabling the extension, choosing payment methods, setting order statuses and deciding where each method appears. The extension runs on your web tier and handles requests between Magento and Braintree. The Braintree merchant account is where you obtain API credentials, manage users and review transactions. Braintree separates its sandbox and production environments, and each has its own credentials, so a working sandbox setup does not carry over to live processing. Ask your team to confirm which person holds the Braintree agreement and who is allowed to rotate keys.

Plan the connection by mapping each payment method to a decision. Cards with vaulting and 3D Secure, PayPal, Apple Pay, Google Pay, Venmo, ACH and local payment methods each have their own enablement steps, storefront conditions and account prerequisites, so enabling one method does not switch on the others. Decide early which methods your markets need, which ones may need approval on the Braintree side, and whether your currencies and countries are covered. Also confirm where the extension stores Braintree credentials and make sure those values stay out of version control and shared configuration exports.

The design question that matters most to your compliance team is where card data goes. The extension uses Braintree's hosted fields for card entry, which places Braintree-controlled input elements in checkout so that card numbers are entered into Braintree's frame and your servers receive a token instead. This is the basis for keeping card data off your servers, but confirm the exact behavior for your release and check that no custom checkout code reads card values. Whether this reduces your PCI DSS scope also depends on your validation type. PCI DSS applies to entities that store, process or transmit cardholder data or could affect that environment, and the payment brands decide who must validate. Confirm the hosted field setup with your Qualified Security Assessor or the Self-Assessment Questionnaire you plan to complete before go-live.

What you need in place before enabling Braintree

Braintree runs on top of a complete Magento Open Source stack, so the release line, supporting services, web tier, payment account, certificates and cache design all need to be settled first. Adobe supports only the combinations it lists for each release, and the current listed releases are 2.4.9 and 2.4.8-p5.

Magento Open Source release line

Choose one 2.4.x release and build the store against its listed requirements. The current listed releases are 2.4.9 and 2.4.8-p5, both released on May 12, 2026. The 2.4.9 requirements list PHP 8.5, while the 2.4.8-p5 requirements list PHP 8.4 or 8.3. Before installation, confirm that the Braintree extension and every other extension in your build support the release you select.

Database, search, cache and queue services

For 2.4.9, Adobe lists MySQL 8.4 or MariaDB 12.3 (recommended) or 11.8, OpenSearch 3, Redis or Valkey 9 and RabbitMQ 4.3. Confirm each version against the Adobe system requirements page before provisioning. Plan which host runs each service and who patches it, because checkout depends on all of them working together.

nginx and Composer on Linux

The 2.4.9 requirements list nginx 1.30 and Composer 2.10 on Linux x86-64. Install Magento through Composer so that the Braintree extension and its dependencies resolve to the same release line as the core. Confirm your Linux distribution and CPU architecture before the build, because the listed requirements apply to x86-64 only.

Braintree merchant account and sandbox

Open a Braintree merchant account and confirm that your team can sign in to the sandbox environment before you change any storefront setting. Sandbox access lets your developers and testers run card, vaulting and wallet flows without live transactions. Ask your Braintree account contact which merchant ID and API keys belong to each store view, and record who in your organization holds those keys.

HTTPS and certificates on both sides

Serve the storefront and the admin over HTTPS with valid certificates issued for each hostname, and redirect plain HTTP before any payment page loads. Magento supports Content Security Policy headers from 2.3.5, and from 2.4.7 CSP runs in restrict mode by default on storefront and admin payment pages. Test every payment form after you change headers or add domains, and record who owns certificate renewal.

Varnish as full-page cache

Decide whether Varnish runs as the full-page cache on this self-managed installation. Adobe documents Varnish for self-managed installations, while cloud-hosted Adobe Commerce uses Fastly instead. Varnish 8 is the version listed with 2.4.8-p5, so confirm the Varnish version for 2.4.9 with Adobe before you decide. After any cache change, test that cart, checkout and account pages are not cached and that payment forms still load.

Braintree integration steps in Magento Open Source

This sequence takes a self-hosted Magento Open Source store from the bundled Braintree extension to live payments in a controlled order. Each step ends with a check that confirms the setting works before the next method is added.

Confirm the bundled extension is enabled and current
The engineer responsible for the store checks that the Braintree payment module is present, enabled and at a version supported by the Magento Open Source release line in use. Confirm the release line against Adobe's lifecycle and release pages before changing anything, and apply any pending patches to the test environment first. Run the module status check from the command line and confirm the module reports as enabled. The step is complete when the Braintree payment methods appear in the admin payment configuration of the staging store, with the admin labels recorded from the installed version.
Create or confirm sandbox credentials in Braintree
The merchant account owner, or a delegated Braintree administrator, creates or confirms a sandbox account and generates the API credentials the Magento module needs. Store the public key, private key and merchant ID in your secrets manager, not in a shared document or a source repository. Record which user generated the keys and who can rotate them. The step is complete when someone who did not generate the keys can see the sandbox account in the Braintree dashboard and confirm that the merchant ID matches the one you plan to enter in Magento.
Enter sandbox credentials in Magento
The Magento administrator enters the sandbox credentials in the Braintree section of the payment configuration, scoped to the website or store view where the test will run. Select the sandbox environment, save the configuration and clear the configuration cache so the new values are read. Place a test order with a test card on a staging storefront. The step is complete when the order is created in Magento, the authorization or sale appears in the Braintree sandbox dashboard under the matching merchant ID, and no error is logged for the payment request.
Enable cards with vaulting
The administrator turns on card payments and the option to save cards for future use, which Braintree calls vaulting. Confirm which customer groups and store views see the option. Place a test order as a registered customer with a sandbox test card and choose to save it, then place a second order with the stored card. Confirm that card entry happens in the Braintree hosted fields and that the Magento database holds only a token and card type, not the card number. The step is complete when the second order completes using the saved card and the vaulted customer record appears in the Braintree sandbox.
Enable 3D Secure
The administrator enables 3D Secure for card payments and sets the rules that decide when a challenge is requested, such as the threshold or the issuing-bank behavior the Braintree configuration offers. Confirm the exact option names in the installed version. Test with sandbox cards that trigger a challenge and with cards that do not, and record the outcome of each. The step is complete when a challenged test order shows a 3D Secure result in the Braintree sandbox, a frictionless test order shows a different result, and the Magento order status matches what Braintree reports.
Add PayPal, then test it alone
The administrator enables PayPal in the Braintree configuration, following the connection steps shown in the admin, which may require linking a PayPal sandbox business account. Enable PayPal on its own and leave wallets off until it passes. Run a checkout from the storefront through the PayPal flow, including a cancelled attempt, and confirm the order behavior. The step is complete when a successful PayPal sandbox order appears in both Magento and the Braintree dashboard, the cancelled attempt does not create a paid order, and the refund flow works in the sandbox.
Add wallets one at a time
The administrator enables each remaining wallet, such as Apple Pay, Google Pay or Venmo, one at a time, and tests each before enabling the next. Wallet availability depends on the browser or device, the domain verification each provider requires, and the regions supported for your merchant account, so confirm those requirements with Braintree and the provider before testing. Run a sandbox transaction through each wallet on a device you control. The step is complete when each wallet produces a transaction visible in the Braintree dashboard and a matching order in Magento, and the wallet is recorded as tested for the devices it supports.
Move to production credentials
The Braintree account owner generates live production credentials, and the administrator replaces the sandbox values in the Magento configuration for the production store scope, with the environment set to production. Apply the same credential storage rules used in the sandbox, and confirm that test-only settings are not carried into production. Run one live transaction using a card you own, then refund it through the Braintree dashboard. The step is complete when the live transaction and refund appear in the production dashboard, the Magento order and payment records match, and the sandbox credentials have been removed from the production scope.

Choosing cards, PayPal, wallets, ACH and local methods

Each payment method you enable in the bundled Braintree extension is a promise to the business, and availability is set by your Braintree account and the region where the merchant operates, not by the Magento configuration screen alone. Before the build starts, list every method the business wants, then confirm each one with Braintree for your merchant country, account type and currencies. Treat that written confirmation as the input to the scope, and do not promise a method to stakeholders until it appears as enabled in Braintree's sandbox and production accounts.

Card acceptance is the baseline, and the decisions around it are where the risk sits. Decide whether returning customers may save cards in the vault for repeat purchases, who can delete a saved card, and what happens to stored tokens when a customer account closes. Then decide your 3D Secure rules: which transactions trigger a customer authentication challenge, which skip it, and who carries liability for disputed payments when authentication is or is not completed. Confirm with Braintree which 3D Secure options your account supports and how they apply in your region, because the rule set changes both conversion and fraud exposure.

PayPal and Venmo look like simple toggles, but each depends on the account and the country. Confirm that your Braintree account is enabled for PayPal in the merchant's country and currencies, and confirm whether Venmo is available there at all. Decide which PayPal entry points the store offers, such as the cart page, the product page or checkout only, and make sure the sandbox test plan covers each one. Ask Braintree whether any PayPal option has account-level requirements that the business must meet before go-live, since those requirements can delay launch even when the code is ready.

Apple Pay and Google Pay have technical prerequisites that the store team must own. Apple Pay requires domain verification for each storefront domain, and it works only on supported Apple devices and browsers. Google Pay depends on Braintree enabling it for your account and on the browsers and devices your customers use. Plan testing on real devices as well as the sandbox, and decide what shoppers see when a wallet is unavailable, so they can still complete the purchase with a card. Add domain verification and wallet enablement to the launch checklist, with a named owner for each.

ACH and local payment methods depend most heavily on Braintree approval and the merchant's country. Each method may require separate underwriting, customer authorization steps, settlement timing and reporting, and some may not be offered to every merchant type. Ask Braintree for the current list of approved methods for your country, what documents or onboarding steps apply, and how refunds and disputes work for each one. Then decide which methods launch in the first release and which wait until Braintree confirms them, and record that decision in the written scope so the business knows what is and is not available on day one.

How Braintree data maps to Magento orders, customers and vault records

This table compares each Magento data element with its counterpart in Braintree and notes what to confirm in your installed extension version. Use it as a checklist before the build, because field names and status transitions can differ between releases. The main takeaway is that with hosted fields, card numbers stay with Braintree, while Magento keeps references such as transaction IDs and vault tokens.

Data element	Magento and Braintree side	What to confirm or map
Order and transaction ID	The Magento order and its payment transaction ID link to the Braintree transaction for each authorization, capture, void or refund.	Confirm which Magento field stores the Braintree transaction ID in your version and whether refunds reference the original transaction.
Customer and vault token	The Magento customer maps to a Braintree customer and vault token used for saved cards.	Confirm whether guest checkout creates vault records and where the token is stored on the Magento side.
Billing address	Billing fields are sent to Braintree with the transaction to support address verification checks.	Confirm which billing fields are transmitted, including country and region code formats, and whether they match your tax and fraud rules.
Shipping address	Shipping fields are stored on the Magento order and sent to Braintree only if the extension passes them.	Confirm whether shipping data is sent at all, and map any ERP or carrier fields that need their own mapping.
Authorization	The order status set after authorization depends on whether the payment action authorizes only or authorizes and captures.	Confirm the order status and invoice behavior for each payment action in your configuration and extension version.
Capture, void and refund	Capture creates an invoice, void cancels an uncaptured authorization, and refund issues a credit memo and a Braintree refund.	Confirm partial capture and partial refund support, and how the order status changes when a settled transaction is refunded.
Tokens versus card numbers	With hosted fields, Braintree holds the card number. Magento stores tokens, nonces, card type and last four digits.	Confirm exactly which payment and vault fields the installed version writes, and check that no full card number reaches your database or logs.
Custom attributes and ERP fields	The bundled mapping covers standard Magento fields. Custom order or customer attributes and ERP fields are outside it.	Plan a separate mapping for each custom attribute or ERP field, and test it in the Braintree sandbox before go-live.

Security settings that protect the Braintree integration

The Braintree extension keeps card data off your servers, but the store around it still decides who can change payment settings, where credentials live and which scripts run on checkout pages. The cards below cover the controls to verify in your own environment before and after go-live.

Admin access and two-factor authentication

Payment configuration in the Magento admin should be limited to a small set of roles that can open Stores, Configuration, Sales Payment Methods. Confirm that each named administrator uses a unique account, that shared logins are gone, and that two-factor authentication is enforced for every role that can change Braintree settings. Review the role assignments after each staff change and check that the admin URL and login are not reachable from open networks.

Braintree API credentials outside source control

Braintree merchant IDs, public and private keys and environment settings should be entered through the platform's secured configuration and not committed to Git repositories, deployment scripts or theme files. Search your repositories and build artifacts for key patterns before each release. Confirm that sandbox and production credentials are kept separate, and that the environment file or secret store on each server is restricted to the people who operate it.

Refund permissions

Refunds and voids move money out of the business, so the ability to issue them should be narrower than the ability to view orders. Check which admin roles hold the order refund and cancel permissions, and whether the Braintree refund action is limited to a finance or senior support group. Ask your team to test a refund with a non-admin account that lacks the permission, and confirm the refund appears in the admin order history with the acting user.

Content Security Policy on payment pages

From Magento Open Source 2.4.7, Content Security Policy runs in restrict mode by default on storefront and admin payment pages, so scripts the policy does not list can be blocked. Test checkout, the cart and the admin payment configuration page in a staging environment after every upgrade or theme change. Review the browser console and CSP violation reports for blocked Braintree or wallet resources, and add only the specific sources that the vendor documents for your configuration.

Approved sources for wallet and third-party scripts

Apple Pay, Google Pay, PayPal and Venmo buttons load scripts from payment provider domains, and marketing or analytics tags can add further external scripts to checkout. List every external origin that loads on checkout and payment pages, and compare it with the set your team has approved. Confirm that any script loaded from a third-party domain is covered by an allowed source in the policy, and that unexpected tags added through the admin or a theme are reviewed before they reach production.

How hosted fields keep card data off your servers and limit PCI DSS scope

Hosted fields are the design choice that most affects how much of your store falls inside the cardholder data environment. With the Braintree integration for Magento Open Source, the card number, expiration date and security code are entered into fields that Braintree's JavaScript renders and controls in the customer's browser. That data travels directly from the browser to Braintree, and your Magento server receives a payment token in return. The store stores, processes and forwards tokens rather than primary account numbers, which is the main reason this configuration can reduce the systems that PCI DSS requirements reach. The reduction is a property of the design, not something the extension decides for you, so your team should confirm that the card fields in your theme and checkout are the Braintree-hosted fields and not custom inputs that post card data to your own endpoints.

Before you plan the scope, get the basics of PCI DSS right. The current standard is version 4.0.1, which is the only active version after v4.0 was retired on 31 December 2024. The PCI Security Standards Council owns and maintains the standard, but it does not enforce compliance or set penalties. The individual payment brands decide which entities must validate and run any enforcement programs, so the first question to put to your acquirer or payment brand contacts is what they require from your organization. Validation is documented either through a Report on Compliance completed by a Qualified Security Assessor or through a Self-Assessment Questionnaire, and in both cases an Attestation of Compliance is the document that counts. A certificate is not accepted as proof of validation, so do not let a vendor badge or certificate stand in for an AOC in your procurement file.

The correct Self-Assessment Questionnaire type depends on your exact design: whether cardholder data touches your servers at all, whether scripts on your checkout pages can affect payment data, how your hosting is arranged, and which parties handle any part of the flow. Hosted fields usually point toward a lighter questionnaire than a design that posts card data to your own server, but the choice must be confirmed with your acquirer or a QSA using your actual checkout, theme and hosting layout. Ask them to review the list of payment pages, the scripts loaded on those pages, the admin access paths to payment settings, and any third-party services in the flow. Record their answer in writing with the date and the version of the configuration reviewed, because a later theme change or extension upgrade can change the answer.

Plan the evidence before the assessment starts. For the Braintree design, useful artifacts include a data flow diagram showing the browser-to-Braintree path, configuration exports for the payment method settings with the card-capture mode recorded, screenshots or records of the checkout pages, inventories of JavaScript loaded on payment pages, and access reviews for the roles that can change payment configuration in the Magento admin. Content Security Policy settings that restrict where scripts can load on payment pages are also relevant evidence, and they should be tested after every theme or extension change. DeployOpen can prepare these systems, controls and evidence and document the configuration so an assessor can review it. DeployOpen does not issue reports, attestations or certifications. Those come from your acquirer, a QSA or the applicable validation process.

Testing 3D Secure, wallets and refunds in sandbox before launch

Card tests confirm that hosted fields, vaulting and 3D Secure behave as your fraud and checkout rules expect before a customer sees them. Run these cases in the Braintree sandbox against a Magento Open Source test store that uses the same extension version and settings you plan to promote.

Vaulting: save a card at checkout, place a second order with the stored card, and confirm the customer record and token appear in the Braintree sandbox vault.
3D Secure challenge: use a sandbox card that triggers a challenge, complete the authentication step, and confirm the order advances once authorization succeeds.
3D Secure frictionless: use a sandbox card that authenticates without a challenge, and confirm no extra step appears in the storefront.
Failed authentication: abandon or fail the challenge, and confirm the shopper sees a clear message and no paid order or invoice is created.

Expected results: the Magento order sits in pending payment or processing, depending on your payment action, and the Braintree transaction shows as authorized or submitted for settlement with liability shift details recorded. Keep order numbers paired with Braintree transaction IDs, challenge screen captures, and the extension configuration export for the change record.

Before writing scripts, check the current sandbox card numbers and 3D Secure behavior in Braintree's documentation, because test values can change.

Common Braintree failures on Magento Open Source and their fixes

This table lists the failures teams most often hit with the bundled Braintree extension, the likely cause of each and where to look first. Read each row as a diagnostic path: start with the first place to check, then confirm the cause before changing configuration. Items marked for vendor confirmation depend on Braintree account settings that only Braintree can verify.

Failure	Likely cause	Where to look first	Fix and what to confirm
Payments fail with authentication errors after go-live	Sandbox credentials (public key, private key, merchant ID) entered in production, or production credentials left in a test store	Magento admin Stores > Configuration > Sales > Payment Methods > Braintree, then the Braintree dashboard environment selector	Re-enter credentials for the matching environment and set the environment field to match. Confirm the merchant ID and environment with Braintree support if the dashboard shows two accounts.
A payment method is missing at checkout	Method not enabled on the Braintree account, not active for the merchant's country or currency, or disabled in Magento	Braintree dashboard account settings for the payment method, then the Magento payment method list for the store scope	Enable the method in Braintree, then enable it in Magento for the same website scope. Confirm country and currency eligibility for ACH, Venmo and local methods with Braintree, since availability changes by account.
Apple Pay or Google Pay buttons do not appear	Domain not verified with the wallet provider, or HTTPS incomplete on the storefront or checkout page	Browser console for wallet script errors, and the storefront URL in the browser address bar	Serve the full storefront and checkout over HTTPS with a valid certificate, then complete domain verification for the wallet in the Braintree dashboard. Confirm Apple Pay domain steps and any Google Pay merchant registration requirements with Braintree.
3D Secure challenge fails or loops after a checkout change	Custom checkout template, JavaScript or payment form change that alters the payment nonce flow, or 3DS toggled inconsistently between environments	Browser console for Braintree SDK errors, then Braintree dashboard transaction details for the 3D Secure result	Restore the standard payment component or re-apply the change so the nonce and billing fields are passed unchanged. Confirm the 3DS rule settings and liability shift behavior for your account with Braintree.
Payment scripts blocked after an upgrade or policy change	Content Security Policy rules added or tightened during an upgrade (restrict mode is the default from 2.4.7), so Braintree script or frame sources are not allowed	Browser console CSP violation messages, then the store's Content Security Policy configuration	Add the Braintree script and frame sources the console names to the policy, then retest every payment method. Confirm the current list of required domains with Braintree documentation before editing.
Orders stay in pending after payment succeeds	Message queue consumers or cron jobs not running, so the post-payment order update is not processed	Magento var/log files, the cron_schedule table, and the Braintree dashboard showing the transaction as authorized or settled	Confirm cron runs on schedule and the required consumers are active. Reprocess stalled items after the consumer is restored. Check the transaction status in Braintree before changing the order manually.
Refund fails in the Magento admin	Transaction not yet settled, so a void is required instead of a refund, or the refund amount exceeds the captured amount	Braintree dashboard transaction status, and the credit memo error message in Magento admin	Void unsettled transactions in Braintree or wait for settlement, then refund. Confirm settlement timing and partial refund rules for your payment method with Braintree.
Vaulted cards or saved payment methods stop working	Customer vault tokens tied to the other environment, or the vault setting changed between sandbox and production	Magento logs for vault token errors, and the Braintree customer records in the matching environment	Clear and re-save the customer's card in the correct environment. Confirm vault migration options with Braintree, since tokens do not transfer between environments.

Braintree integration questions buyers ask before hiring help

How much does a Braintree integration for Magento Open Source cost?

The cost follows from a written scope, and DeployOpen does not publish a price list, so a quote depends on the payment methods, checkout changes and testing you need. The main one-time cost is labor for configuration, any custom checkout or 3D Secure work, sandbox and production testing, and documentation. Recurring costs include patching the platform and extensions, a support retainer if you want one, and Braintree transaction fees, which you pay to Braintree under your merchant agreement. Ask each quote to separate one-time work from recurring items, list the tests included, and state which decisions the partner expects you to make.

How long does a Braintree integration project usually take?

No duration is stated here because timing depends on the scope agreed in writing before work starts. The biggest time drivers are the number of payment methods, since cards, PayPal, Apple Pay, Google Pay, Venmo, ACH and local methods each need their own configuration and test cases. Custom 3D Secure rules, changes to an existing checkout and the depth of testing also set the pace. Your Braintree account approvals and any PCI DSS scope review can add waiting time. Ask for a schedule tied to milestones and a list of dependencies on your side.

Which factors drive the effort of a Braintree build on Magento?

Five factors drive most of the effort: the number of payment methods enabled, whether 3D Secure rules are custom, how far your checkout already differs from the standard flow, the PCI DSS validation scope you must support, and how deep the testing goes. Each payment method adds configuration, storefront display rules and test cases. Custom 3D Secure rules add decisions and verification steps. Checkout customizations must be retested with every change. PCI scope decides which evidence you collect, and testing depth ranges from sandbox smoke tests to full regression across devices and wallets. Ask the partner to show how each factor changes the quote.

Do custom 3D Secure rules make a Braintree integration harder?

Yes, custom rules add decisions and test cases, so they usually add effort compared with default settings. The core question is which transactions should trigger a challenge, which should be exempt, and how the store handles declines and fallbacks. These choices affect conversion, liability and customer experience, so your payments and risk owners should agree on them before the build starts. Confirm with Braintree how its 3D Secure options apply to your account and region, and confirm with your acquirer any rule that affects liability. Document each rule so that later Magento upgrades do not change behavior without a review.

What does the merchant need to provide before a partner starts?

Plan to provide a Braintree merchant account with sandbox and production access, a list of the payment methods you want and the countries and currencies you sell in, and named contacts in payments, finance and risk who can approve decisions. The partner also needs a staging environment that mirrors production, your Magento version and extension list, documentation of any checkout customizations, and your current PCI DSS scope notes or prior questionnaire. Put engineering time for reviews and access to hosting accounts on the calendar. Missing inputs are a common cause of delay, so ask for a written list of inputs during scoping.

Can an in-house team set up Braintree on Magento without a partner?

Yes, an experienced Magento team can configure the bundled extension in-house, especially for one card method on a standard checkout. The work gets harder when several wallets, custom 3D Secure rules and checkout changes must be tested together, and when the team must also produce PCI DSS scope evidence. Check whether your team has capacity for testing and for keeping the integration working through each Magento patch cycle. A partner can make sense for the parts your team has not built before, or for a fixed-scope build with written test criteria. Before deciding, confirm your team's experience with hosted fields and the Braintree sandbox.

Does DeployOpen certify that a Magento store is PCI DSS compliant?

No. DeployOpen does not issue audit reports, attestations or certifications. PCI DSS is maintained by the PCI Security Standards Council, but the payment brands decide which entities must validate and run any enforcement. Validation is documented on official templates: either a Report on Compliance completed by a Qualified Security Assessor, or a Self-Assessment Questionnaire with an Attestation of Compliance. Certificates are not recognized as validation. DeployOpen can prepare the configuration, scope documentation and evidence an assessor will request, and can help test the controls. Your acquirer or assessor confirms which validation applies to your store. The current version is PCI DSS v4.0.1.

How DeployOpen works on this

DeployOpen plans, implements, configures and supports the Braintree extension for Magento Open Source inside your own infrastructure. Work starts with a written scope that names the payment methods, sandbox and production environments, and PCI DSS responsibilities. Engagements are fixed-scope, and ongoing support is available as a retainer.

How we scope

The written scope lists each payment method you accept, including cards, wallets, ACH and local methods.
Scope records whether cards use vaulting and 3D Secure, and which of those features your processor account supports.
Sandbox and production test plans, merchant account ownership and PCI DSS responsibilities are agreed before build starts.

How we build

Configure the bundled Braintree extension on your own Magento Open Source hosts, following your environment and change process.
Keep hosted fields in place so card numbers go to Braintree directly and stay off your web servers.
Test vaulting, 3D Secure challenges, refunds and each wallet in the Braintree sandbox before production cutover.

How we hand over

Written documentation of configured payment methods, credential locations, webhook settings and rollback steps.
Test evidence for each payment method and PCI DSS scope notes that your assessor can review.
Knowledge transfer sessions for the staff who will manage refunds, disputes and configuration changes.

How we support

Optional retainer covering extension updates, Magento patch-cycle upgrades and payment-method changes after go-live.
Review the PCI DSS scope whenever payment flows, hosting or the storefront's Content Security Policy change.
Confirm extension and PHP compatibility with each Magento release line before upgrading your production store.

Magento Open Source Braintree integration