What is the Magento Marketplace?
Short answer
The Adobe Commerce Marketplace (it used to be called “Magento Marketplace” and now lives at commercemarketplace.adobe.com) is Adobe’s official store for Magento 2 and Adobe Commerce extensions, themes and services. Vendors submit their packages and Adobe reviews each one in two parts: a technical review (Magento Coding Standard, install tests, security checks) and a marketing review of the listing. Approved extensions go on sale and Adobe keeps a 30% commission. Every extension you buy there is installed with Composer from repo.magento.com using your access keys.
- Sign up at commercemarketplace.adobe.com as a Developer 01
- Submit composer.json + zipfile + version manifest via the developer portal 02
- Tech Review (~7 business days), automated + manual 03
- Marketing Review (~3 business days), listing copy + screenshots 04
- Live on Marketplace; Adobe pays out monthly (70% to vendor) 05
Most common mistake Buying without checking the last-update date
Five steps from vendor signup to live listing
The submission flow is documented, but the first one always takes longer than you expect. This is the path from the vendor side, from signup to a live listing.
-
01
Sign up at commercemarketplace.adobe.com as a Developer
You start with an Adobe ID and a developer profile. Adobe asks for the legal name, tax or VAT details, payout bank details and a support email, and that support email is shown publicly on every listing. You can register as an individual or as a company. If the money should land in a business account, register the company.
-
02
Submit composer.json + zipfile + version manifest via the developer portal
In the developer portal you add the extension and upload a zip of the source with a valid
composer.jsonat its root: package name, version, licence and themagento/frameworkor module versions it supports. Leave outvendor/andnode_modules/. Each release gets its own notes on what changed. Price, support terms and a demo URL go into the same form. -
03
Tech Review (~7 business days), automated + manual
The technical review runs automated checks first, including
phpcs --standard=Magento2against the Magento Coding Standard, install tests on supported versions and a scan for malware and obfuscated code. A person then looks at security (CSRF, SQL injection, XSS) and things like ACL checks on admin controllers. If anything fails you get a report back and resubmit. I runvendor/bin/phpcs --standard=Magento2 app/code/Vendor/Modulelocally before every upload, which saves a round trip. -
04
Marketing Review (~3 business days), listing copy + screenshots
After the technical review passes, the marketing review checks what buyers will see: title, description, feature list, screenshots, demo link, pricing that matches the support terms, and a user guide. Wording that suggests the extension is made or endorsed by Adobe when it is not will get the listing sent back.
-
05
Live on Marketplace; Adobe pays out monthly (70% to vendor)
Once both reviews pass, the listing goes live and buyers pay through Adobe’s checkout. Adobe handles billing, refunds and sales tax, and pays the vendor monthly. The split is 70% to the vendor and 30% to Adobe. The buyer then installs the package with
composer requirefromrepo.magento.com.
Four situations where the Marketplace is the obvious answer
You can get Magento extensions from GitHub or straight from vendors too. In these four cases, though, the Marketplace is the sensible choice for buyers and vendors.
-
Buy instead of build when the feature is < 2 weeks dev
For a problem that many stores already have, such as a blog, reward points or a one-step checkout, buying an extension is usually cheaper than paying for the build. Before buying I check three things: the licence (one store or several domains), how long support and updates last, and whether the latest release supports the Magento and PHP version the store runs.
-
Verify a vendor before purchasing
A Marketplace listing tells you a few things a random GitHub repo does not: Adobe knows who the vendor is, the code passed the technical review, and the vendor accepted Adobe’s refund policy. It does not mean the code is good. If two extensions do the same job and only one is on the Marketplace, I start with that one, then still read the code before it goes on a client store.
-
Sell your own extension, visibility + billing handled
For a vendor the Marketplace handles three things you would otherwise build yourself: people finding the extension through search and categories, taking payment (cards, VAT, refunds, chargebacks), and the trust that comes with being on Adobe’s own store. The 30% commission is real money. Whether it is worth it depends on how much traffic you can get on your own.
-
Plan for the EQP review (Extension Quality Program)
EQP is not a badge you add later. It is the standard technical and marketing review every extension goes through before it is listed: malware scan, coding sniffs, plagiarism check, install and Varnish tests in production mode, MFTF tests and manual QA, plus a marketing review of the listing. Every new version you upload goes through the technical review again, so keep the code clean and the user guide current.
Three Marketplace mistakes that waste time and money
These three mistakes cost buyers and vendors the most time. Check for them before you buy or submit.
-
Buying without checking the last-update date
Many Marketplace listings are technically still “available” but functionally abandoned. The vendor hasn’t shipped a release in 18+ months, the support email auto-replies with a holding message, and the extension hasn’t been re-tested against Magento 2.4.7 or 2.4.8. Before purchase, check three things on the listing:
Last updatedate (should be under 12 months old), theCompatible Magento versionslist (must include your version), and the most-recent customer reviews. If any of the three look stale, treat the extension as abandoned. -
Ignoring composer dependency conflicts
Marketplace listings advertise a Magento compatibility range (e.g.
magento/product-community-edition: 2.4.5 - 2.4.8) but transitive composer dependencies often break it. A Marketplace extension that requireslaminas/laminas-mail: ^2.20can collide with another module pinned to^2.18, andcomposer requireblows up. Always runcomposer require --dry-runon adevenvironment first; never install a Marketplace extension straight onto a live store. -
Submitting an extension without running MEQP locally first
Many vendors submit without running the Magento Coding Standard on their own machine. The review then comes back with a list of
phpcsviolations, and the wait starts again after the fix. Installmagento/magento-coding-standard, runvendor/bin/phpcs --standard=Magento2 app/code/Vendor/Module, and clear every error before you upload. I also install the package on a clean 2.4.x instance withsetup:upgradeandsetup:di:compile, because a compile error is the other common reason for a rejection.
Magento Marketplace: frequently asked questions
-
Is the Magento Marketplace still active under Adobe?
Yes, very much so. Adobe rebranded the old magentomarketplace.com domain to commercemarketplace.adobe.com after the Adobe acquisition closed and migrated every existing listing, vendor account, and customer purchase record to the new domain. The submission workflow, the 30% commission, and the Tech + Marketing review pipeline are unchanged from the pre-Adobe era. As of 2026 the Marketplace lists roughly 3,500 extensions, 1,200 themes, and 800 services across both Magento Open Source and Adobe Commerce. The only meaningful change since the Adobe takeover is the addition of Adobe Commerce-specific listings (B2B modules, Adobe Sensei AI, Adobe Stock integrations) that don't apply to Open Source. -
What is the 30% Adobe Marketplace commission really for?
Four things, bundled. (1) Credit-card processing, Adobe runs the checkout, eats the chargeback risk, handles refunds, and absorbs the ~3% Stripe / Braintree merchant fee that would otherwise come out of your margin. (2) VAT / sales-tax collection, Adobe collects EU VAT, UK VAT, US sales tax, Australian GST, and remits it to the appropriate tax authority; vendors don't need to register in every jurisdiction. (3) Vendor verification, Adobe confirms the legal entity, tax ID, and bank details before any vendor can sell, which is what makes the Marketplace badge meaningful. (4) Marketing, Marketplace search, category pages, and the “Featured” rotation drive organic discovery the average extension vendor cannot replicate on their own site. -
How long does Marketplace submission take end-to-end?
For a clean submission with no rejections: about 10 business days, ~7 days in Tech Review plus ~3 days in Marketing Review. In practice first-time vendors usually iterate twice. The first submission almost always fails Tech Review on Magento Coding Standard violations the vendor didn't catch locally, which costs another 7 business days. The second submission often fails Marketing on screenshot sizing, demo-URL availability, or trademark misuse, which costs another 3 days. Budget 4-6 weeks for the first extension you list; subsequent extensions from the same vendor account typically clear in the advertised 10 business days because the vendor has internalised the standard. -
Are Marketplace extensions safe to install on production?
Mostly, with caveats. Adobe’s Tech Review catches obvious security issues (SQL injection, unsanitised input, missing ACL on admin controllers, hard-coded credentials, eval / base64 obfuscation) before an extension is approved. That eliminates the worst class of malicious extensions you'd find on a random forum. But Tech Review is not a full security audit, it doesn't catch subtle logic bugs, side-channel data leaks, or insecure dependency versions in vendor libraries. For a public-facing production Magento store, the right workflow is: install on dev first, runbin/magento dev:di:infoandbin/magento module:statusto see what the extension touches, review the controllers and observers manually, and only then promote to staging and production. -
Marketplace vs Hyvä Themes marketplace, do I need both?
They solve different problems. The Adobe Commerce Marketplace at commercemarketplace.adobe.com is Luma-first; every extension is expected to work with the default Magento Luma frontend, and Hyvä compatibility is a vendor-by-vendor add-on (often via a separate “Hyvä compatibility module” sold separately). The Hyvä Themes marketplace at hyva-themes.com/marketplace is Hyvä-specific; every extension there is built Hyvä-first using Alpine.js and TailwindCSS, with no Luma compatibility layer. If you run Luma, only the Adobe Marketplace is relevant. If you run Hyvä, you typically shop both: the Hyvä Marketplace for Hyvä-native modules, and the Adobe Marketplace for modules where a Hyvä compatibility shim exists. -
Can I sell themes and services on the Marketplace, not just extensions?
Yes, the Marketplace has three top-level categories, Extensions, Themes, and Services, each with its own submission workflow. Themes (~1,200 listed in 2026) go through a similar Tech + Marketing review but the Tech portion checks template syntax, LESS / Tailwind hygiene, and accessibility rather than PHP code quality. Services listings (~800 in 2026, things like “Magento Performance Audit” or “Hyvä Migration Sprint”) are reviewed on capability claims, case-study links, and Adobe Solution Partner status; pricing is shown as a starting point rather than a fixed product price. All three categories share the same 30% Adobe commission and monthly payout terms.
Want a Marketplace-ready extension built?
Send your extension spec: I will scope a Marketplace-ready build with Magento Coding Standard, MFTF tests, EQP submission, and reply with a fixed-price quote plus earliest start date. 24-business-hour turnaround.