A Chrome Web Store trader declaration is the EU trader or non-trader status every developer must set on the publisher account, and it sits beside a second gate, 2-Step Verification, that blocks publishing outright when it is off. Developers usually meet both at the same moment, when an upload or an update will not go through. The Chrome Web Store began enforcing 2-Step Verification for publishers in August 2021, and since then a Google account without a second factor cannot publish a new item or update an existing one. The trader declaration came later, tied to the EU Digital Services Act, which has applied to online platforms since 17 February 2024. Traders give a legal name, a phone number and an address, and that information is posted publicly at the bottom of the extension listing. Google does not publish a specific penalty for a missing declaration, but the regulation behind it does require platforms to suspend EU sales by traders who never supply their details.

Our lead insight is that this is a security and identity gate. When a client tells us they cannot publish, we check account settings before anything else. In most cases the cause is a Google account that was never secured, a declaration that was never completed, or contact details that no longer match the business. None of these are policy violations in the usual sense, and none of them call for a policy appeal. They call for the right settings on the right account, completed by the person who controls it.

What the 2-Step Verification Rule Requires

The Google account you use to publish or update items in the Chrome Web Store must have 2-Step Verification (2SV) turned on. A Chrome developer who cannot publish because 2SV is off is the most common case we see. Google announced the rule on its Chrome developer blog in its 2021 policy update on 2-Step Verification for extension developers, and enforcement began in August 2021. The August 4, 2021 note on that post says enforcement could take several weeks to reach every account. Once enforcement applies, the developer cannot publish new extensions or update existing ones until a second factor is enabled. The requirement now sits under Technical Requirements in the Chrome Web Store Program Policies, which every developer accepts alongside the Developer Agreement.

Why the requirement exists

An extension runs inside a user’s browser. If an attacker takes over the Google account that publishes a popular extension, they can push an update to every user who has it installed. A second factor on publishing accounts makes that takeover far harder. A hijacked publisher account can turn a legitimate extension into a malware incident overnight, and recovering from that is much harder than enabling a second factor. For a team, the requirement protects users and the business in the same stroke.

Which second factor to use

Google’s own 2-Step Verification help page lists the options. You turn it on from Security and sign-in in your Google Account. Choices include passkeys, hardware security keys, Google prompts on a signed-in phone, authenticator apps that produce one-time codes, 6-digit text or voice codes, and 8-digit backup codes for a lost phone. Google rates passkeys and security keys as the strongest protection against phishing and warns that text codes are more exposed to phone-number attacks. Two timing details matter for a team in a hurry. Google may take up to 7 days to trust a newly added phone number, and a flagged new number has to be confirmed within 30 days. Work or school accounts may block the setting entirely, in which case the domain administrator has to allow it.

• Publishing accounts owned by a company should use security keys or passkeys the company holds.
• Authenticator apps belong on a device assigned to the role, not on a personal phone.
• Backup codes go in the company’s password vault, with a record of who can open it.
• Text codes are a fallback, not the main method for an account that ships code to users.

Who gets caught by it

Three kinds of publishers meet this block most often.

Companies publishing from shared or legacy Google accounts. The extension was first published years ago from an account created by an early employee or a founder. Several people shared the password. Nobody set up 2-Step Verification because nobody owned the account. When a new update is ready, the upload fails, and the team discovers that the person who could enable the second factor left the company.

Agencies managing client publishing accounts. An agency builds and publishes extensions for clients. Sometimes the agency publishes from its own account, sometimes from the client’s, and the security settings are unclear to both. The agency cannot enable 2-Step Verification on an account it does not control, and the client does not know the account exists.

Commercial developers distributing in the EU. These developers qualify as traders and must complete the trader declaration. They usually have 2-Step Verification in place but have not finished the declaration or the phone verification that goes with it.

What blocks publishing

The two gates are often confused, so it pays to be precise about what each one does.

Trader or Non-Trader

Google’s Chrome Web Store trader disclosure page sets out the dates. The European Commission adopted the New Deal for Consumers on April 11, 2018, its provision took effect on May 28, 2022, and from February 17, 2024 EU rules required marketplaces to identify and verify traders. Under those rules, a marketplace must tell consumers whether they are dealing with a professional trader or an individual. EU consumers are told that consumer protection rights do not apply to contracts with non-traders. That one line explains why the declaration matters to users and why Google asks every developer to make it.

The legal basis in the Digital Services Act

The trader duty comes from Article 30 of the Digital Services Act, Regulation (EU) 2022/2065, headed Traceability of traders. It requires platforms that let consumers conclude distance contracts with traders to collect the trader’s name, address, telephone number and email address before the trader can offer products to consumers in the Union. Depending on the trader, the list also covers an identification document, payment account details, a trade register number and a self-certification about the products offered. Article 30 makes the trader liable for the accuracy of that information. Article 30(7) requires the platform to show the name and contact details, the register entry and the self-certification to users where the product is presented. Under Article 93, the regulation applies from 17 February 2024.

Two parts of Article 30 change how seriously a developer should take a stalled declaration. For traders already on a platform on 17 February 2024, providers had 12 months to make best efforts to collect the information. Traders who still failed to provide it within that period were to be suspended until they did. Where a trader’s details turn out to be inaccurate or incomplete and the trader does not correct them, the platform must swiftly suspend its service to that trader for offers to EU consumers. Google’s own pages do not describe how the Chrome Web Store applies those suspensions, so we treat Article 30 as the outer limit, not as a description of Google’s process.

How to decide your trader status for a Chrome extension in the EU

Google will not decide for you. Its Chrome Web Store trader verification FAQ says each publisher decides for itself, and it quotes the Commission’s definition. A trader acts for purposes relating to a trade, business, craft or profession. A non-trader acts outside those purposes. Most businesses find the question easy once they ask whether the extension is part of how they earn money or promote a business.

If you are unsure, take advice before you declare. A declaration has to be accurate on the day you make it and stay accurate afterward. If a hobby project starts earning money or becomes part of a business, revisit the status.

First-time setup versus an ongoing duty

For 2-Step Verification, the consequence is fixed and immediate. No second factor means no publishing. Once it is on, the only risk is losing control of the factor, which the security routine further down addresses. The trader declaration works differently. It is never finished in the sense of a one-time task, because the information shown to EU users is only useful while it is current. Treat the first declaration as the start of a duty that sits with whoever owns the publisher account.

Regional scope

The trader declaration exists because of EU law and protects consumers in the EU. Google asks all developers to declare, wherever they are based. The 2-Step Verification requirement applies to every publisher in every country. A developer in the United States who distributes to EU users still faces the trader question for those users. A developer who distributes only outside the EU still needs 2-Step Verification to publish. Neither Google page we reviewed describes a separate UK or US trader regime for the Chrome Web Store, so we do not invent one.

Developers who have already been through a denied review will find the escalation side in our guides to a rejected Purple Potassium appeal and Limited Use data controls for extensions.

What Users See

Trader information is posted publicly at the bottom of your extension listing. Google’s FAQ says traders must provide a legal name, a contact phone number and an address, usually the same details that appear on incorporation, tax or similar business documents. The phone number is verified by SMS and displayed on the listing. Before you submit, make sure the address is correct and that you are comfortable showing it to the public. A home address entered by a sole developer will be visible to anyone who scrolls down the page.

Why accuracy matters beyond compliance

Users decide whether to install based on trust. A clear, current trader identity tells them a real business stands behind the extension. It also ties into other store policies. Your privacy policy, your listing and your trader information should all describe the same business. Our guides to the Purple Lithium privacy policy requirement and the Purple Nickel prominent disclosure rule cover the listing side of that consistency.

Members of a shared publisher

Google says that if you publish only under a shared group publisher, your own verification information is not shown publicly. If you later publish from your own account, that information will be posted. A developer who uses a personal account for one side project and a company publisher for work should know which identity each listing will display.

Keeping one identity

Our method keeps a single, consistent legal identity across the developer account, the trader declaration, the Payments profile and your own business records. The identity problem we see most often is drift. The company changes its name, moves offices or reorganizes into a new entity, and the publisher account still shows the old details. Each change on its own is small. Together they leave a trader declaration that no longer describes the business behind the extension.

How to update each field

Google’s FAQ gives a separate route for each detail, and using the wrong one wastes days.

• The email contact is updated directly in the developer console.
• An address in the same country is edited in the verification settings of your Google Payments settings.
• A new country, phone number, name or D-U-N-S number needs verification restarted. You switch status from Trader to Non-Trader and back to Trader, then enter the new details.
• A developer who registered as an individual by mistake uses the same switch to restart as a corporation.

Fixing a Blocked Publish

Our method for this case is short, because the fix is mostly settings and documents. Identify the missing element, complete it with matching details, keep one identity, and confirm that publishing is restored.

Step one is to identify the missing element

Check the publishing account first. Sign in as the account that owns the items, or as a member of the publisher, and confirm whether 2-Step Verification is on. Then check the trader status in the developer dashboard. Then check that the contact details are current. Write down which of these is missing or wrong. In most blocked publishes the answer is the first one.

Step two is to enable 2-Step Verification on the right account

Turn on 2-Step Verification for the Google account that publishes. If items are published through a shared publisher, make sure every member who uploads has it on their own account. If the account belongs to a former employee or a shared mailbox nobody controls, recover control through your organization’s Google administration before anything else. Do not create a new account and republish the items under it to get around the block. That creates a second publisher identity for the same extension and causes far bigger problems than a missing second factor.

Step three is to complete the trader declaration

Declare trader or non-trader status, and complete verification if you are a trader. Use the exact legal name and address of the business as they appear on your registration documents. An individual trader needs an SMS-capable number. Google’s FAQ says telecom and VoIP providers, including Google Voice, can supply one. For corporations, Google says support for a D-U-N-S-associated phone number will be added in the future, so SMS is the route today.

Step four is to confirm publishing is restored

Try the upload or update again and confirm the item moves into review. Google’s Chrome Web Store review process page says most reviews finish within a few days but can take up to a few weeks, and it advises contacting developer support if a review is pending for more than three weeks. Our guide to a Chrome Web Store review stuck in pending covers that wait. Record what you changed, when and on which account, so the next person who hits a problem does not start from zero.

A worked example

A software company published a tab management extension in 2019 from a Google account created by its first developer. The extension has a paid tier, and most of its users are in Europe. The first developer left two years ago. The current team tries to ship a security fix and the update will not publish.

Working through the method, the missing element is clear within minutes. The publishing account has no second factor, and its recovery email points to the former developer’s personal address. The company’s Google administrator recovers the account through the organization’s own controls and turns on 2-Step Verification with a security key the company holds. The team then moves publishing to a company publisher with three named members, each on a secured account and each with the narrowest role they need. In the dashboard, the team sees that the trader status was never set. Because the extension has a paid tier and EU users, they declare trader status. They enter the registered legal name and address exactly as they appear on the registration certificate, verify the support line by SMS and add a monitored email. The update goes up again and moves into review. The team logs each step with its date.

Nothing in that sequence required an appeal. Every step was a setting or a document, done by the person entitled to do it, which is why we check settings first.

How a reviewer reads a verification file

When Google asks for verification and a person looks at what you submitted, they are comparing records. The name on the account, the name on the document, the name in the trader declaration and the name in your privacy policy should be the same entity. The address should match across them. The person submitting should have a clear role in the business. When all of that lines up, the file is easy to approve. When one field differs, even by a trading name used in place of the legal name, the file stalls. Prepare the documents first, compare every field side by side, and only then submit, so the reviewer sees one consistent identity on the first pass.

If you are still blocked

If settings are correct and publishing still fails, contact developer support through the dashboard. Google’s review process page says support replies can take up to three days and escalated concerns may take longer than seven days. Review verdicts and account suspensions can be appealed from the developer dashboard. Keep the message short and specific.

1. State that 2-Step Verification is enabled and the trader declaration is complete.
2. Identify the element that was missing and the date it was fixed.
3. List the matching details and documents you submitted.
4. Confirm that a single legal identity is used across the account and records.
5. Ask that publishing be restored or verification completed.

For EU developers, Article 4 of the Platform-to-Business Regulation, Regulation (EU) 2019/1150, requires a statement of reasons on a durable medium when a platform restricts or suspends a business user. A full termination must come with reasons at least 30 days before it takes effect. Article 11 of the same regulation requires a free internal complaint system. Under Article 20 of the Digital Services Act, a decision to suspend a service or account can be challenged through the platform’s internal complaint system for at least six months after the decision. You rarely need either law for a missing second factor, because the cause is known. They matter if your account is restricted and the reason is unclear. If the account has been suspended outright, start with our guide to a suspended Chrome Web Store developer account, and if a first appeal failed, read our notes on a denied Chrome Web Store appeal.

Mistakes that prolong the block

• Creating a new account to publish. A second account for the same items splits your identity and can look like an attempt to evade enforcement.
• Enabling 2-Step Verification on the wrong account. The account that publishes is the one that needs it.
• Using a departing employee’s personal phone as the second factor. Use devices and methods the business controls.
• Entering trading names instead of legal names. Use the registered legal name, and show the brand name in the listing.
• Restarting verification from a different member. The member who started it should finish it, or the team should restart on purpose with the status switch.
• Treating it as a policy appeal. A settings problem is fixed in settings. A long appeal about policy compliance does nothing for a missing second factor.

Deadlines and Timing

Most of the clocks here come from Google’s help pages and the two EU regulations, not from a notice addressed to you. Planning around them stops a fix from slipping into a lost release.

The practical rule is to set up 2-Step Verification at least a week before a release you cannot delay, because a new phone factor may not be trusted for 7 days. Hardware keys and passkeys avoid that wait.

Account Security Routine

The prevention lesson is short. Enable 2-Step Verification and keep the trader declaration current. The routine below keeps both true as the team changes.

Publisher roles

Google’s Chrome Web Store page on managing publisher members says the store no longer separates individual and group publishers. You can add members to any publisher you administer, with one of four roles. A Viewer sees items, analytics and draft revisions. An Item Manager can also create items, update packages and change visibility. An Editor can also change publisher settings and manage trusted testers. An Admin can also manage members and roles and delete the publisher. Google also warns that an account can create only one publisher in its lifetime, and deleting a publisher does not restore that quota, so plan the structure before you create it.

Account ownership

• Name one owner for the publisher account, by role, with a backup who holds the Admin role.
• Give each member an individual Google account with 2-Step Verification on, and the lowest role that lets them work.
• Use second factor methods the business controls, such as company-held security keys, and record where they are kept.
• Remove access the same day a team member leaves.
• Keep recovery options current on every account with publishing access.

Quarterly review

1. Confirm 2-Step Verification is on for every account with publishing access.
2. Confirm the publisher’s member list and roles match the current team.
3. Check the trader status and the listing’s name, address and phone against your registration records.
4. Check that the privacy policy, listing and trader details name the same business.
5. Record the review, with the date and the person who ran it.

Events that trigger an immediate review

Run the check at once after a company name change, a new registered address, a merger or new entity, or a change of agency. Do the same when a new team member will publish or someone leaves. Each of these can leave the declaration or the account security out of date.

Agencies and client accounts

Agencies should agree in writing with each client whose account publishes the extension, who owns it, and who controls the second factor. Our recommendation is that the client owns the publisher account and adds the agency’s staff as members with their own secured accounts and the Item Manager or Editor role. When the engagement ends, the client removes the agency members, and the extension keeps publishing without interruption. Where a handover has already gone wrong, our Chrome Web Store reinstatement team can sort out ownership and access.

Keep the rest of the account clean

Security and identity gates are rarely the only issue on an account that has been neglected. When a team rediscovers an old publisher account to fix 2-Step Verification, it is worth checking the items in it against current policies too, especially permissions and data handling. Start with our guides to Purple Potassium excessive permissions and the Limited Use data policy. Teams that ran several near-identical extensions from the old account should also read our note on repetitive content in the Chrome Web Store, a rule Google clarified in the same August 2021 update.

Frequently Asked Questions

Why does Chrome Web Store ask for a trader declaration and 2-step verification?

The trader declaration exists because the EU Digital Services Act requires marketplaces to tell EU consumers who the trader behind a product is. 2-Step Verification has been required since August 2021 to stop attackers who take over a publisher account from pushing malicious updates. Google asks every developer to set a trader status, and every publishing account to have a second factor.

What happens if 2-step verification is off on my publishing account?

You cannot publish new items or update existing ones until it is on. That includes security fixes for items already in the store. Turning on a second factor for the account that publishes clears this block.

What information does a Chrome Web Store trader have to provide?

A legal name, a contact phone number and an address, usually the details on your incorporation or tax records. The phone is verified by SMS. All three are posted publicly at the bottom of the extension listing.

Am I a Chrome Web Store non-trader if my extension is free?

Not automatically, because a free extension that promotes or supports a business still serves a commercial purpose. Google leaves the decision to each publisher and quotes the EU definition of a trader as someone acting for purposes relating to a trade, business, craft or profession. Take advice if your case is unclear.

Can I appeal a Chrome Web Store verification decision?

Yes, review verdicts and account suspensions can be appealed from the developer dashboard. For a missing second factor or an unfinished declaration, fixing the setting is faster than any appeal. EU business users can also rely on the statement of reasons and complaint rights in Regulation (EU) 2019/1150 and the Digital Services Act.

How do I change my trader details after verification?

Update the email in the developer console, and edit a same-country address in your Google Payments verification settings. For a new name, phone, country or D-U-N-S number, switch your status to Non-Trader and back to Trader to restart verification.

How do I prevent a blocked publish in the future?

Give every member their own Google account with 2-Step Verification, and use company-held security keys or passkeys. Review member roles and trader details every quarter and after any change to the business.

Get Help With Chrome Web Store Trader Declaration and 2-Step Verification

A single developer with one account can usually clear this alone in an afternoon. Bring it to us when several accounts and entities are involved, when an agency and a client both touch the publisher account, when the person who controlled the account has left, or when verification keeps failing. Organizing identity and security across accounts is where we help.

Our Chrome Web Store reinstatement service audits account ownership and settings, reconciles the trader declaration with your business records, prepares matching documents and handles any appeal. We know how the Chrome Web Store reviews identity and verification cases, though no one can promise how a review will decide. Book a free assessment to get started.

Publishers with problems on other app stores or developer programs can browse our full set of app store and developer reinstatement services.

Sources

1. Chrome Web Store, Trader disclosure
2. Chrome Web Store, Trader FAQ
3. Chrome for Developers blog, Chrome extensions policy update on 2-Step Verification
4. Chrome Web Store Program Policies
5. Chrome Web Store, Managing publisher members
6. Chrome Web Store, Review process
7. Google Account Help, Turn on 2-Step Verification
8. Regulation (EU) 2022/2065, Digital Services Act
9. Regulation (EU) 2019/1150, Platform-to-Business Regulation