Cómo reducir las comisiones de las tiendas de apps con compras integradas

Redirige el checkout de la app a la web de forma conforme

Enlace a un navegador externo: los desarrolladores que usan un WebView dentro de su app tienen pocas probabilidades de superar la revisión del iOS App Store. Redirige a un navegador externo para mantener el cumplimiento.

Comprueba el país de distribución: Apple solo admite actualmente Japón, Corea del Sur, la UE y Estados Unidos. Ten en cuenta tu región.

Usa una solución prediseñada para garantizar el cumplimiento: además de las directrices de Apple, debes cumplir las normas gubernamentales, bancarias y de las redes de pago aplicables. Incluyen estándares de seguridad como PCI, normas de privacidad como el RGPD de la UE y la CCPA de California, y las comunicaciones exigidas por bancos y compañías de tarjetas. Podemos orientarte sobre estos requisitos.

Cuándo pueden utilizarse pagos externos

Apple permite que las apps elegibles del App Store de Estados Unidos dirijan a los usuarios fuera de la app para comprar contenido o servicios digitales en situaciones específicas. Para juegos, membresías, suscripciones, bienes virtuales y contenido digital, esto ofrece una alternativa a las compras integradas de Apple (IAP).

Según las directrices de revisión de Apple 3.1.1 y 3.1.1(a), las apps de la tienda estadounidense pueden incluir botones, enlaces externos u otras llamadas a la acción que dirijan a mecanismos distintos de IAP para comprar contenido o servicios digitales.

• Objetos de juego, moneda virtual, niveles y contenido virtual
• Membresías y suscripciones
• Contenido y servicios digitales
• Apps que necesitan un checkout Web/H5 de terceros para compras externas

Las normas actuales de Apple no exigen solicitar el StoreKit External Purchase Link Entitlement para mostrar botones, enlaces o llamadas a compras externas en la tienda estadounidense. Antes del lanzamiento, el comercio debe confirmar que su modelo de negocio, categoría de app, tipo de producto y las últimas normas de revisión de Apple sean aplicables a su caso.

El pago externo es más que un enlace

Añadir un acceso al pago externo parece sencillo, pero un checkout fiable requiere más que una redirección. El comercio debe gestionar la creación de pedidos, confirmación del pago, entrega de productos o derechos, validación de notificaciones, reembolsos, excepciones y conciliación.

Cuando el usuario vuelve del checkout web, la app no debe depender únicamente del resultado del cliente. Los parámetros de retorno pueden mejorar la experiencia, pero no prueban el pago. El resultado definitivo debe obtenerse de una notificación del servidor de WooshPay o de una consulta del pedido.

Cómo WooshPay facilita el checkout externo

WooshPay ofrece un checkout móvil Web/H5 que recibe a los usuarios desde el acceso a compras externas de la app y los guía para pagar en el navegador.

• Creación de sesiones de pago
• Visualización del comercio, producto, importe, moneda y vencimiento del pedido
• Métodos habituales en Estados Unidos, como tarjetas de crédito y débito, y monederos según la elegibilidad del negocio
• Estados de pago correcto, fallido, pendiente, cerrado y relacionados con reembolsos
• Notificaciones del resultado del pago desde el servidor
• Consultas de pedidos, reembolsos, conciliación e informes de transacciones
• Validación de firmas, controles de riesgo, límites, prevención del fraude, pruebas en sandbox y comprobaciones de lanzamiento

Flujo de pago recomendado

Al pulsar el acceso a la compra externa, el comercio crea un pedido con un identificador único. Su servidor fija el producto, importe, moneda, ID de usuario, canal y vencimiento, y crea una sesión de pago de WooshPay.

El usuario paga en el checkout Web/H5 de WooshPay. Cuando cambia el estado, WooshPay notifica al notify_url del comercio. El servidor verifica la firma, ID del pedido, importe, moneda e ID del comercio antes de conceder el derecho digital.

Al volver a la app, debe consultarse el estado del pedido al servidor del comercio en lugar de confiar en los parámetros de redirección del cliente.

Qué debe preparar el comercio

• Configurar un acceso claro a las compras externas dentro de la app
• Explicar claramente que el usuario irá a una web o a un checkout seguro para completar la compra
• Crear pedidos con identificadores de comercio únicos a nivel global
• Fijar el producto, importe, moneda, ID de usuario, canal y vencimiento
• Admitir estados de pedido como pendiente de pago, en proceso, correcto, fallido, cerrado y reembolsado
• Configurar notify_url para notificaciones de pagos, reembolsos y cierre de pedidos
• Verificar firmas, IDs de pedidos, importes, monedas e IDs de comercio de las notificaciones
• Procesar las notificaciones de forma idempotente para evitar entregas duplicadas
• Conceder membresías, suscripciones, moneda virtual, objetos de juego u otros derechos digitales solo tras la confirmación del servidor
• Gestionar notificaciones y pagos duplicados, pedidos vencidos, reembolsos, reversos y pedidos anómalos

No es necesario informar a Apple sobre pagos de terceros

Para el caso estadounidense descrito en el documento original, el comercio no necesita informar a Apple sobre las transacciones de terceros. Debe conservar registros completos de transacciones, reembolsos, conciliación, riesgos y soporte para sus necesidades operativas y financieras.

Un checkout más flexible para usuarios del App Store de Estados Unidos

Los pagos externos ofrecen otra vía de compra para apps de contenido y servicios digitales en Estados Unidos. WooshPay conecta los accesos de compra de la app con un checkout Web/H5 y permite controlar desde el servidor el pago, la entrega, los reembolsos y la conciliación.

WooshPay reduce la complejidad de integración, mejora la gestión de estados y convierte los enlaces de compra externos en un checkout fiable, auditable y escalable.

En Japón, la compra externa es más que un enlace de pago

Apple permite a las apps iOS elegibles de Japón usar compras externas en situaciones específicas. Los editores de juegos pueden mantener Apple IAP y ofrecer además la opción de pagar en el navegador predeterminado del dispositivo.

No basta con añadir un enlace de pago al producto. Hay que gestionar el entitlement de Apple, elegibilidad regional y del dispositivo, igual prominencia de IAP, Apple Disclosure, navegador predeterminado, retorno por Universal Link, entrega desde el servidor e informes a Apple.

WooshPay conecta estos pasos mediante un SDK, Hosted Checkout y un servicio de datos de informes para juegos iOS, creando una vía de compra externa apta para lanzamiento, auditable y más fácil de conciliar.

Ámbito de aplicación

• Usuarios de iPhone en la tienda japonesa
• iOS 26.2 o posterior
• Juegos que hayan solicitado y configurado el entitlement de compra externa correspondiente de Apple
• Compras de productos digitales que necesitan un pago en navegador junto con Apple IAP
• Bienes digitales del juego, como objetos, moneda virtual, niveles y contenido virtual

Antes del lanzamiento, confirme la aplicabilidad según la documentación más reciente de Apple Developer, los requisitos de revisión, el modelo de negocio y la estrategia de publicación.

Cómo WooshPay facilita todo el proceso de compra

Al pulsar el acceso externo en la página del producto, WooshPay SDK ejecuta primero las comprobaciones de Apple en tiempo de ejecución. Si el jugador y el contexto son elegibles, muestra Apple Disclosure y, tras la confirmación, abre WooshPay Hosted Checkout en el navegador predeterminado.

Tras pagar, el jugador puede volver por Universal Link. El cliente no debe entregar objetos basándose solo en la URL de retorno: el servidor del juego debe consultar el estado definitivo de WooshPay o procesar su webhook antes de la entrega.

Funciones principales

1. Comprobación de elegibilidad antes de cada compra

El SDK debe ejecutar canMakePayments e isEligible antes de cada intento, sin depender solo de un resultado almacenado al iniciar la app. Las restricciones del usuario, tienda, versión de iOS y entitlement pueden afectar al resultado.

2. Compatibilidad con iOS 26.2/26.3 e iOS 26.4+

Las compras externas en Japón están disponibles desde iOS 26.2+. Las rutas de tokens e informes difieren entre iOS 26.2/26.3 e iOS 26.4+. WooshPay SDK puede cubrir ambas manteniendo una experiencia de compra coherente.

3. Gestión de tokens LINK_OUT y registro

En iOS 26.4+, el SDK obtiene un token LINK_OUT antes de cada posible transacción y lo envía a WooshPay Server antes del checkout. El token vincula el intento de compra, la sesión, el estado de la transacción y los informes a Apple.

4. Apple Disclosure antes de abrir el navegador

Apple Disclosure informa de que el usuario abandona el entorno de compra de Apple para operar con el desarrollador o un tercero. El SDK debe usar la API de Apple, no una interfaz propia similar. Si el jugador cierra o rechaza el aviso, debe devolver un estado cancelado sin abrir el navegador.

5. Hosted Checkout en el navegador predeterminado

Los enlaces externos deben abrir una página o pestaña del navegador predeterminado, no un WKWebView ni otro pago integrado en la app. WooshPay Hosted Checkout gestiona métodos de pago, riesgo, estados, resultados y el botón para volver al juego.

La entrega debe basarse en el estado definitivo del servidor

Universal Link devuelve al jugador a la app con información de pedido consultable, pero no acredita el pago. return_url no debe incluir un parámetro manipulable success=true que active directamente la entrega.

El estado definitivo debe venir de WooshPay Server. Se recomienda combinar notificaciones webhook y consultas activas. El servidor solo debe conceder membresías, suscripciones, moneda virtual, objetos u otros derechos cuando el pedido esté en SUCCESS y coincidan importe, moneda, pedido e identidad del jugador.

Qué debe gestionar el desarrollador del juego

WooshPay integra pagos, apertura del navegador y datos de informes, pero el desarrollador sigue teniendo tareas comerciales y de cumplimiento esenciales. La elegibilidad de Apple, presentación de productos, pedidos, entrega e informes deben implementarse en el contexto de su app, productos y cuentas de jugadores.

Configuración de Apple y App Store

• Confirmar que la app, el producto, la región del jugador y el caso de negocio estén dentro del alcance de las compras externas de Apple en Japón.
• Solicitar y configurar el entitlement de compra externa correspondiente en Apple Developer o App Store Connect.
• Establecer jp como región permitida en el archivo entitlements de Xcode y comprobar que el paquete de producción incluya el ajuste.
• Mantener coherentes el bundle identifier, la cuenta Apple, el entorno de lanzamiento y la app aprobada.
• Revisar la documentación y las directrices de Apple más recientes antes del lanzamiento para reducir riesgos de revisión por cambios de política.

Página de producto y acceso a la compra

• Diseñar el acceso externo en la página del producto, detalle del objeto o recarga, y mostrarlo solo en casos elegibles.
• Mantener Apple IAP disponible y al menos tan destacado como la opción externa en ubicación, peso visual, texto y orientación.
• Explicar claramente que el jugador saldrá de la app para pagar en un navegador o checkout seguro.
• Evitar insinuar que Apple procesa la compra externa y evitar descuentos, colores o diseños que desvíen claramente al usuario de IAP.
• Si falla canMakePayments o isEligible, ocultar o desactivar el acceso externo o guiar a Apple IAP según la estrategia del producto.

Integración del cliente y retorno a la app

• Inicializar WooshPay SDK al iniciar la app con merchantId, environment, returnUniversalLink y nivel de registro.
• Llamar a purchase solo cuando el jugador pulse activamente el acceso externo; no iniciar el flujo sin una acción del usuario.
• Configurar el dominio de Universal Link, el archivo apple-app-site-association y Associated Domains.
• Gestionar estados del cliente: correcto, pendiente, fallido, cancelado, fallo al abrir el navegador y alternativa de Universal Link.
• No guardar claves privadas de Apple API, issuer ID, key ID ni otras credenciales sensibles de informes en el cliente.

Pedidos y entrega desde el servidor

• Crear un merchant_order_id único globalmente y fijar producto, importe, moneda, jugador, servidor, personaje y vencimiento del pedido.
• Integrar las API del servidor de WooshPay para crear sesiones, consultar pedidos, recibir webhooks y procesar reembolsos.
• Verificar firmas webhook, IDs de pedidos, importes, monedas, identidad del jugador y protección frente a repetición.
• Realizar todas las entregas en el servidor del comercio con idempotencia por merchant_order_id o transaction_id.
• Definir reglas para PENDING, FAILED, CANCELLED, EXPIRED y REFUNDED que eviten entregas prematuras o duplicadas.
• Si el pago termina sin retorno a la app, el webhook debe activar igualmente la entrega desde el servidor; el jugador verá el derecho actualizado en la siguiente consulta de estado.

Informes, conciliación y operaciones

• Obtener los datos o archivos de informes para Apple mediante WooshPay Reporting API o Dashboard.
• Enviar informes a Apple con las credenciales/JWT propios del comercio y conservar la responsabilidad sobre plazos y exactitud.
• Crear controles, reintentos y trazas de auditoría para transacciones correctas, reembolsos, cancelaciones, vencimientos, tokens sin transacción y correcciones.
• Conciliar registros de pagos de WooshPay, entregas del juego, reembolsos e informes a Apple en los procesos financieros.
• Preparar SOP de soporte y operaciones para cancelaciones, pagos pendientes, cobros sin entrega, pagos sin retorno, reembolsos y recuperación de derechos.

Datos de informes a Apple y límites de responsabilidad

Los riesgos de informes en Japón también incluyen cancelaciones, vencimientos, pagos fallidos, tokens sin transacción, reembolsos y correcciones. El SDK y el servidor deben tratarlos como estados comerciales formales, no como ruido de registros.

El servicio de informes de WooshPay mantiene el registro de tokens y transforma transacciones, reembolsos, cancelaciones, vencimientos y resultados sin transacción en datos o archivos de informes para Apple.

Por defecto, WooshPay no conserva claves privadas de Apple API, issuer ID ni key ID del comercio, ni envía informes en su nombre. El comercio usa sus propias credenciales/JWT, manteniendo el control de credenciales y la responsabilidad jurídica y financiera.

Cree compras externas para juegos iOS en Japón con WooshPay

La compra externa aporta una nueva vía de pago a los juegos iOS en Japón, junto con requisitos de ingeniería, revisión e informes. WooshPay conecta SDK, Hosted Checkout, sincronización de estados y generación de informes para lanzar una experiencia controlada, conciliable y escalable.

WooshPay reduce el desarrollo repetido de flujos de Apple, simplifica la apertura del navegador y el retorno, permite entregar con el estado definitivo del servidor y prepara datos estructurados y auditables para los informes a Apple.