欧盟DSA没做身份验证，App在27国下架

广州一家做健身记录应用的团队，二〇二四年起在欧洲跑订阅，德国、法国的用户每月稳定付费，团队把增长重心放在买量和功能迭代上，没太管后台那几条身份相关的提示。

二〇二五年六月，他们突然发现德国和法国的应用商店页面打不开，已上架的应用搜不到。后台只飘着一条提示：“trader verification incomplete”，意思是商家身份验证没有完成。

团队之前一直以为，付费开发者协议签完、税务和银行信息填好，主体这件事就算过关了。直到商店页面在欧盟27国集体消失，才意识到数字服务法要求的验证是另一套东西。

一、先对照：DSA商家身份验证对照

先把数字服务法第30至32条和两大商店的实际动作对照一遍，看清开发者到底被要求做些什么。

二、几种典型情形，哪种最伤

第一种，只填了税务与银行信息就当完成。这是最多人踩的坑。付费开发者协议那一套，平台要的是结算和税务信息，和数字服务法要求的商家身份核验不是一回事；填完前者不代表后者已通过，后台仍会卡在验证未完成。

第二种，用香港或新加坡主体开店，地址却填了内地办公地址。平台要求注册主体与可核查地址一致，跨法域的主体配错地址，验证反复被拒，商店页面迟迟上不了欧盟区，收入窗口一直关着。

第三种，代理提交时联系邮箱用的是代运营的。平台核验邮件发到代运营邮箱，开发团队自己收不到，验证进度停在半路，等发现时欧盟区已经下架一阵子，损失已经发生了。

三、一个完整案例

回到开头那家广州团队。二〇二四年他们以公司主体接入两大商店，签了付费协议，税务与银行信息齐全，欧洲订阅一路跑着，没人把后台的商家验证入口当回事。

二〇二五年六月，欧盟区页面打不开。他们翻后台才看到商家验证未完成，而验证入口早就在开发者后台挂着，只是没人把它和“商店页面消失”联系起来。团队紧急补交材料，又因为主体注册地与填写地址不一致被退了一次。

这段时间欧盟新用户装不了，已装用户收不到更新，德国法国的订阅与内购收入直接归零，部分到期用户还发起退款，压力回到开发者这边。等验证走完重新上架，丢掉的不只是几天收入，还有一批被竞品接走的活跃用户。

四、现在就能做的四步

·先判断自己是不是商家：只要应用有内购、订阅或广告变现，就属于商家，必须走验证；纯免费无变现的可报非商家，但一旦变现立刻改回。

·找到验证入口：在两大商店后台定位商家验证入口，别和付费开发者协议的税务银行信息混为一谈，那是两套流程。

·主体与地址保持一致：用哪国主体开店，就填该国可核查的注册地址与电话；香港、新加坡主体别配内地办公地址，避免反复被拒。

·留可接收核验邮件的邮箱：联系邮箱用团队自己能收的，代理提交时也要确保核验邮件能转到开发方，别卡在代运营邮箱里。

写在最后

数字服务法把“商家是谁”这件事钉死在商店页面上，平台只是把核验动作交给了开发者。验不过，欧盟27国的门就对你关上，而且一关就是收入、用户、更新三道一起断。不少团队把验证拖到商店下架才动手，那时已经不只是补材料，而是要把流失的用户重新拉回来，成本翻了好几倍。把验证当成上线前的硬关卡，比事后救火便宜得多。

CHENXING GLOBAL

EU DSA TRADER VERIFICATION. NO BADGE, NO MARKET.

【文末福利】评论区留言「欧盟DSA」，领《欧盟DSA商家身份验证自查清单》

清单里是：①判断自己是否属于商家的对照项；②两大商店后台验证入口与所需材料清单；③香港、新加坡主体配地址的常见被拒情形与规避办法。想让我按你的架构逐条回，留言写「欧盟DSA+行业+成立年份」，我看到就回。

这篇建议先收藏，真办手续时翻出来对一遍；觉得有用，点个「赞」和「在看」，让更多做出海的同行看到。

免责声明：本文为一般性信息分享，不构成针对任何具体情形的税务、法律或审计意见。各国及地区的政策、申报要求、费用标准与办理时效可能发生调整，实际操作应以当地现行法规、主管部门要求及专业机构核实结果为准。