Delimitar la entrega antes de diseñar
Este procedimiento sirve a comercios y desarrolladores que revisan un componente autoalojado, no a quienes buscan un servicio de premios gestionado. Registrar responsable, fechas, elegibilidad, canje y origen del resultado. Elegir ruleta, tarjeta para rascar o cajas por presentación; una animación no prueba la asignación. El modo local debe identificarse como demostración. El servidor del comercio asume los resultados reales, el inventario y la autenticación.
Conservar una exportación completa. Alojar index.html, widget.css y widget.js juntos o escoger conscientemente el HTML de archivo único. config.json es una copia editable, no un almacén secreto. Los visitantes pueden leer las ofertas incluidas en el código; las imágenes externas se solicitan desde sus navegadores. Usar datos ficticios en herramientas auxiliares, nunca claves, datos de clientes o códigos reales de canje.
Reconciliar configuración y contrato
Crear el JSON Schema a partir de la documentación de la exportación actual. Revisar version, campaignId, mode, endpoint e identificadores de premios. Confirmar por separado que los identificadores sean únicos y que las probabilidades locales sumen exactamente 100%; una validación estructural básica no demuestra estas relaciones. Los sectores iguales de la ruleta son visuales, no probabilidades iguales. Comparar las versiones y explicar cambios de reglas, textos y resultados. Tras aprobar cambios, volver a exportar sin mezclar scripts antiguos.
La solicitud contiene version, campaignId y requestId. La respuesta debe repetir requestId y devolver un prizeId configurado; los campos opcionales siguen el contrato exportado. Validar ejemplos ficticios de premio y de ausencia de premio, y conservar ejemplos incorrectos para las pruebas negativas. Esto no ejecuta la API ni verifica elegibilidad o inventario. La vista previa del editor nunca llama al punto de acceso.
Revisar todos los estados legibles
Medir los pares reales de texto y fondo, incluidos botones y mensajes finales. Un par aprobado no constituye una auditoría completa de accesibilidad. Revisar el HTML y confirmar manualmente etiquetas, foco, teclado, percepción del resultado y funcionamiento sin animación. No asumir que el análisis estático certifica la interacción de rascar o el marco incrustado.
Comprobar traducciones largas, letras ampliadas, imágenes y enlaces de canje. Mantener las reglas disponibles en texto y no aprobar únicamente la pantalla inicial. Documentar defectos pendientes aunque la vista previa tenga buen aspecto.
Ejercitar el alojamiento y la página incrustada
Subir los archivos al sitio HTTPS autorizado. Las comparaciones de anchos detectan recortes y las capturas conservan una vista; no prueban un sorteo. Pueden no alcanzar páginas autenticadas ni inspeccionar marcos de otro origen. Registrar dirección, ancho y versión, y abrir personalmente la tienda real para revisar altura, desplazamiento, teclado y enlaces externos.
Una ruta relativa de API se resuelve respecto al origen del componente, no al de la tienda contenedora. El código usa credenciales del mismo origen. CORS en un servidor externo no hace que se envíen cookies de sesión, y el bloqueo de cookies de terceros puede afectar a la autenticación incrustada. Utilizar un origen dedicado bajo tu control y revisar los permisos del marco: permiten la integración, pero no garantizan aislamiento del código del comercio.
Probar premio, resultado sin premio configurado, HTTP no satisfactorio, JSON incorrecto, prizeId desconocido, requestId distinto y demora superior a los 15 segundos documentados. Un error no debe conceder un premio local. El reintento manual reutiliza la solicitud pendiente solo en esa página; no protege tras recargar. El servidor debe guardar resultados idempotentes de forma transaccional y gestionar una respuesta perdida después de asignar un premio. Usar resultados de prueba, no premios reales.
Entregar una versión identificable
Calcular SHA-256 después del último cambio. Adjuntar archivos finales, diferencias de configuración, dominio, contrato, evidencias anonimizadas, pendientes y responsables. El hash identifica bytes, no demuestra equidad ni corrección del servidor. Inventario, elegibilidad, canje y autorización de campaña son requisitos separados.
Para enlaces de seguimiento y QR, seguir la revisión de enlaces de campaña; para evidencias antes/después, la revisión adaptable; para archivos candidatos de descuentos, la revisión previa de lotes Stripe. Ninguna sustituye la aceptación de esta integración.