El 28 de octubre, la Comisión de Comunicaciones de Corea del Sur (KMCC) multó a Google y Apple con 63.700 millones de wones, unos 42,7 millones de euros, por una práctica muy concreta: permitían pagos de terceros dentro de las apps, pero les cobraban un 26% de comisión. Casi lo mismo que el 30% de su propio sistema. Si mantienes una app con compras, esto no te obliga a tocar nada esta semana. Sí marca hacia dónde apuntar tu roadmap de monetización.

Qué ha pasado

La sanción llega de la KMCC bajo la Ley de Negocios de Telecomunicaciones, la norma de 2021 que hizo de Corea el primer país en prohibir que una tienda obligue a usar su sistema de pago. Google paga 42.900 millones de wones; Apple, 20.810 millones. La investigación venía de agosto de 2022.

El regulador no castiga por no permitir pagos externos, porque en teoría estaban permitidos. Castiga el cómo. Encontró tres conductas: una comisión del 26% sobre los pagos de terceros que dejaba sin incentivo real el cambio, el bloqueo de los pagos a través de webs externas y revisiones de app demoradas sin explicación ni fecha de reanudación. A Apple le suman un cargo histórico: entre 2015 y enero de 2023 calculó la comisión a los desarrolladores coreanos sobre precios con IVA incluido, y les cobró de más.

Las dos empresas tienen un mes para presentar un plan y tres para aplicarlo. Apple ya ha dicho que recurre; Google, que está decepcionado.

Por qué te afecta aunque no vendas en Corea

Lo que importa no es la cifra, que para ambas es calderilla, sino el patrón. En abril de 2025 la UE multó a Apple con 500 millones; en julio de 2026, a Google con 890 millones bajo la DMA. Ahora Corea. Y el reproche se repite en los tres casos: cobrar un 26% por el pago externo deja la obligación en papel mojado.

Eso tiene lectura para quien decide la monetización de un producto. Durante 2026, la respuesta de Apple y Google a la regulación fue abrir una rendija (puedes enlazar fuera, puedes usar otro proveedor) y cobrarla casi igual. La apuesta era que a casi nadie le compensaría irse por ahorrar cuatro puntos y cargar con el fraude, los reembolsos y el soporte de pagos. Esa apuesta sigue siendo correcta hoy: para la mayoría de apps, el pago nativo con RevenueCat por encima gana en coste total, que no es lo mismo que ganar en comisión.

Lo que cambia es la caducidad de esa respuesta. Si dos jurisdicciones grandes ya han dictado que la comisión espejo no cuela, vendrán más, y en algún momento el número bajará de verdad o la fricción caerá. Construir hoy toda tu facturación dando por hecho que StoreKit y Play Billing son el camino obligatorio es hipotecar el roadmap.

Qué haríamos nosotros

Nada de migraciones a lo loco. Si tu app factura por suscripción y tu volumen no es enorme, quédate en el pago nativo: el 26% externo de hoy no paga la complejidad que añade, y en la práctica el ahorro teórico se lo come el soporte de disputas. ¿Para quién sí tiene sentido mirar fuera ya? Apps con ticket alto, mucho volumen y un equipo de pagos propio, o un proveedor que te cubra PCI, fraude y reembolsos. Ahí cuatro puntos sobre millones son un sueldo entero, y ya analizamos cuándo el billing externo compensa.

Para el resto, la recomendación es de arquitectura, no de proveedor: no claves la caja a tu lógica de negocio. Mete una capa de abstracción entre tus suscripciones y el sistema de pago, de forma que pasar de StoreKit a un gateway web sea configuración y no un refactor de tres meses. Es barato hacerlo cuando diseñas la feature y carísimo cuando el regulador te obliga con la lógica de pago pegada al SDK de la tienda.

La pregunta útil es otra: cuánto te cuesta cambiar de idea cuando el marco se mueva otra vez. Y se va a mover.

Si te toca decidir esto

Hemos montado la capa de pagos de bastantes apps desde 2011, con el criterio de que un cambio de reglas sea un parámetro y no una crisis. Si estás rediseñando la monetización de tu producto, puedes empezar por el mismo árbol de decisión que usamos nosotros antes de escribir una línea.