Guía completa de integración del Libro de Reclamaciones para e-commerce 2026 (WordPress, Shopify, VTEX, Magento, headless)

Este pillar va dirigido a CTOs, agencias de marketing y desarrolladores que necesitan implementar el Libro de Reclamaciones virtual en un ecommerce peruano y dejarlo listo para auditoría. La Casación 20463-2022 (Easy Taxi) y la Resolución 0272-2024/SPC-INDECOPI dejaron sin lugar a dudas que el libro debe estar accesible, conforme y trazable en cualquier portal o app que opere a consumidor final. La Ley 32495 publicada el 11 de noviembre de 2025 elevó el criterio jurisprudencial a obligación legal. Aquí te doy la arquitectura, los snippets de referencia para WordPress, Shopify, VTEX, Magento, Wix, Tienda Nube y stacks headless, y un checklist técnico de 15 puntos para validar el cumplimiento antes del próximo control.

Requisitos técnicos del libro virtual: lo que pide el régimen peruano

Antes de la arquitectura, conviene cerrar el alcance regulatorio. Estas son las nueve obligaciones técnicas que un ecommerce debe satisfacer al 30 de abril de 2026:

1. Visibilidad y accesibilidad: enlace al libro virtual identificable desde la home, con máximo dos clics (Resolución 0272-2024/SPC-INDECOPI). En apps móviles, máximo dos toques.
2. Aviso conforme al Anexo III del DS 006-2014-PCM: pantalla con el texto «Conforme a la Ley N° 29571, este establecimiento cuenta con un Libro de Reclamaciones a tu disposición. Solicítalo para registrar tu queja o reclamo».
3. Datos mínimos del Anexo I del DS 011-2011-PCM modificado por DS 101-2022-PCM: numeración correlativa con código único, identificación completa del proveedor (razón social, nombre comercial, RUC, dirección), identificación del consumidor (nombres, DNI/CE, domicilio, teléfono, email; al menos dos vías de contacto), identificación del bien o servicio, marcado reclamo o queja, descripción, pedido del consumidor, sección «Observaciones y acciones adoptadas por el proveedor», firma del consumidor, firma del proveedor y fecha del registro.
4. Generación de código único e inmutable por hoja: trazabilidad mediante UUID + correlativo + año, registro en base de datos relacional, presentación al consumidor.
5. Confirmación al consumidor por email con copia en PDF de la hoja registrada, código único y plazo de respuesta (15 días hábiles improrrogables).
6. Panel de respuesta dentro de 15 días hábiles: dashboard interno con alerta a los 12-13 días, posibilidad de proponer solución (suspende hasta 5 días hábiles si el consumidor acepta), envío de respuesta por email o carta.
7. Conservación de hojas por 2 años con cifrado conforme a la Ley 29733 modificada por DS 016-2024-JUS (vigente desde 31/03/2025): integridad, disponibilidad, confidencialidad, control de accesos por rol, bitácora de auditoría.
8. Libro físico de respaldo activable en 1 día calendario: cuando el sistema virtual quede inoperativo, el proveedor debe disponer de libro físico para no interrumpir el servicio al consumidor.
9. Reporte al SIREC si los ingresos brutos anuales del proveedor superan 3,000 UIT (S/ 16,500,000 en 2026): integración API conforme al artículo 16 del Reglamento del Libro.

A esto se suma el cumplimiento general del Reglamento de la Ley 29733 sobre Protección de Datos Personales modificado por el DS 016-2024-JUS, que exige acuerdos de tratamiento con encargados (cloud providers, proveedores de email) y notificación al titular del dato sobre el uso que se le dará.

Accesibilidad a «dos clics»: dónde y cómo ubicar el enlace

La regla práctica que circula en doctrina como «regla de los dos clics» se construyó a partir de la Resolución 0272-2024/SPC-INDECOPI. El criterio: el enlace al Libro de Reclamaciones Virtual debe ser identificable desde la página de inicio con un máximo de dos clics. La Sala lo argumentó sobre el deber de visibilidad y accesibilidad y sobre el principio pro consumidor.

Las ubicaciones que pasan el test, ordenadas por preferencia:

• Header persistente con enlace «Libro de Reclamaciones»: un clic desde cualquier página del sitio. Es la opción más segura y la que recomendamos a quien parte de cero.
• Footer global con enlace destacado: un clic. La SBS 04320-2025 también pide visibilidad permanente para entidades supervisadas; se alinea con esta opción.
• Banner persistente o flotante: un clic, alta visibilidad. No es obligatorio pero suma puntos.
• Menú de «Atención al cliente» en home → «Libro de Reclamaciones»: dos clics. Es lo máximo permisible.
• Submenú de «Soporte» → «Reclamos» → «Libro»: tres clics o más. No pasa el test. Genera infracción.

El detalle técnico que muchos pasan por alto: el enlace debe ser identificable como Libro de Reclamaciones, no como «Atención al cliente» o «Reclamos». El consumidor tiene que saber que está accediendo al canal regulado.

Generación de código único y trazabilidad

El Anexo I exige numeración correlativa con código de identificación. La práctica recomendada es combinar:

• Prefijo del año (2026), para diferenciar registros por ejercicio.
• Código del proveedor (RUC abreviado o slug), para multi-tenant.
• Correlativo (000001, 000002, …), para auditoría rápida.
• UUID v4 hash, para no exponer el correlativo en URLs públicas.

Ejemplo: 2026-CB-000123-7f8a2c4e. La parte 2026-CB-000123 es el correlativo legible; el sufijo 7f8a2c4e es el hash que va en la URL pública para evitar enumeración. La hoja se guarda con ambos identificadores y la confirmación al consumidor lleva el correlativo legible.

La base de datos debe garantizar atomicidad del incremento del correlativo. En PostgreSQL el patrón es SERIAL o BIGSERIAL; en MySQL es AUTO_INCREMENT; en sistemas distribuidos donde la atomicidad es difícil, conviene usar Snowflake IDs con prefijo del proveedor.

Cifrado, SSL y manejo de datos personales

El libro virtual maneja datos personales sensibles (DNI/CE, dirección, teléfono, email) y por lo tanto activa la Ley 29733 y su Reglamento modificado por el DS 016-2024-JUS vigente desde el 31 de marzo de 2025. Los lineamientos técnicos:

• SSL/TLS obligatorio: certificado válido, configuración TLS 1.2 mínimo (TLS 1.3 recomendado). HSTS activo en cabeceras HTTP. Sin SSL, la transmisión de datos personales viola la Ley 29733.
• Cifrado en reposo: AES-256 sobre los campos de DNI, dirección y teléfono. Bases de datos modernas ofrecen cifrado transparente (TDE en SQL Server, pgcrypto en PostgreSQL).
• Control de accesos por rol: el operador que responde el reclamo no necesita ver el DNI completo; conviene mostrarle solo la parte necesaria (últimos cuatro dígitos) salvo cuando explícitamente requiera el dato.
• Bitácora de auditoría: cada acceso a la hoja queda registrado con timestamp, usuario y motivo. Esto cubre la integridad y disponibilidad que exige el reglamento de protección de datos.
• Acuerdo de tratamiento con encargados: si usas AWS, Google Cloud, Azure, Mailgun, SendGrid, Twilio, debes firmar acuerdo de tratamiento de datos personales con cada uno y notificar a la Autoridad Nacional de Protección de Datos Personales si transfieres datos al extranjero sin marco adecuado.
• Notificación al titular: el formulario debe informar al consumidor sobre quién tratará sus datos, para qué, por cuánto tiempo y con quién se compartirán.

Sanción por incumplir Ley 29733: 0.5 a 100 UIT según gravedad (S/ 2,750 a S/ 550,000 con UIT 2026). La sanción es independiente de la del Libro de Reclamaciones; pueden acumular.

Libro físico de respaldo: cuándo activarlo

El artículo 5 del DS 011-2011-PCM dispone que cuando el libro virtual quede inoperativo, el proveedor debe activar libro físico de respaldo en máximo 1 día calendario. Esto es relevante para diseñar la arquitectura de alta disponibilidad:

• Uptime objetivo: lo razonable es 99.5 % o más (4.4 horas de downtime al mes). Sistemas mejores apuntan a 99.9 % (43 minutos al mes) o 99.95 %.
• Plan de contingencia: aviso al equipo de servicio al cliente cuando el sistema virtual falle, con instrucciones para activar libro físico de respaldo. Lo razonable es libro impreso pre-foliado en cada local (conservado para emergencias).
• Comunicación al consumidor: si el libro virtual no carga, el consumidor debe ser informado de cómo presentar el reclamo por canal alternativo (correo electrónico, libro físico en local). El silencio es sancionable.
• Sincronización al reactivar: cuando el sistema virtual vuelva, las hojas físicas registradas durante el downtime deben digitalizarse y subirse para mantener la conservación electrónica de 2 años.

Conservación 2 años: arquitectura recomendada

El artículo 12 del DS 011-2011-PCM modificado por DS 006-2014-PCM exige conservar por mínimo dos años desde la fecha de presentación: las hojas (físicas o virtuales), la información del SIREC y la constancia de respuesta y ampliación del plazo. Para una arquitectura cloud:

• Almacenamiento primario: base de datos relacional con cifrado en reposo, backup diario.
• Almacenamiento secundario: bucket S3, GCS o Azure Blob con cifrado AES-256 y política de versioning. Los PDF de cada hoja generada se guardan ahí.
• Lifecycle: regla de 24 meses + 30 días de margen para retención. Pasados los 25 meses, las hojas pueden archivarse en almacenamiento frío (Glacier, Archive) si así lo decide la empresa, aunque para auditoría es mejor mantenerlas accesibles.
• Backup geo-redundante: la disponibilidad debe garantizar entrega a Indecopi en plazo no menor a 3 días hábiles desde requerimiento (artículo 11 del DS 011-2011-PCM).
• Bitácora inmutable: cada modificación, acceso o exportación queda registrada en log inmutable (CloudWatch Logs Insights, Datadog, Loggly o similar).

Patrones de integración por plataforma

WordPress + WooCommerce

El error frecuente: usar Contact Form 7 o un plugin genérico de «formulario de contacto» pensando que satisface el libro. No sirve: faltan los datos del Anexo I, el correlativo único, la firma electrónica y el reporte al SIREC. La arquitectura correcta:

• Plugin específico de Libro de Reclamaciones que registre con todos los campos del Anexo I.
• Hook en wp_footer para inyectar enlace persistente al libro.
• Custom post type «hoja_reclamacion» con meta fields para cada campo del Anexo I.
• Cron job WP-Cron o externo (Action Scheduler) para alertas a los 12-13 días.
• Integración API REST con el endpoint del SIREC si aplica el umbral.
• Storage en wp_uploads con .htaccess que niegue acceso directo; los PDFs se sirven mediante endpoint autenticado.

Para detalle específico WordPress + WooCommerce con snippets, revisa el artículo dedicado a implementación en WordPress que sale en bloques siguientes del plan editorial.

Shopify

Shopify tiene tienda en gran parte de los ecommerce limeños, pero su flujo nativo no incorpora el Libro de Reclamaciones peruano. Las opciones:

• App de marketplace de Shopify específica para mercado peruano (verificar que cubra Anexo I).
• Integración via custom app + Shopify Functions para inyectar enlace en theme.
• Forma alternativa: webhook que envíe los datos a un sistema externo (SaaS de Libro) cuando el cliente registre el reclamo.
• Liquid template modificado: hook al footer global para añadir link «Libro de Reclamaciones» con liquid {% if shop.permanent_domain contains 'pe' %} o detección por idioma.

VTEX

VTEX maneja varios de los grandes retailers del Perú (Falabella, Saga, Plaza Vea Online). La integración pasa por:

• Custom app de VTEX IO con módulo de Libro de Reclamaciones.
• API VTEX para registrar el reclamo en MasterData con schema personalizado que cubra Anexo I.
• Hook en checkout y header para enlace persistente.
• Integración via webhook con el sistema de tickets corporativo (ServiceNow, Salesforce Service Cloud).

Magento (Adobe Commerce)

Magento sigue siendo la base de varios e-commerce mid-market peruanos. Patrón:

• Módulo Magento personalizado con table propia customer_complaint_book.
• Observer en controller_action_predispatch para inyectar enlace en cualquier página.
• Email transactional via Mailgun o equivalente con plantilla del Anexo I.
• Cron de Magento (schedule) para alertas y reporte SIREC.

Wix y Tienda Nube

Plataformas con menos flexibilidad. La opción habitual es:

• Página dedicada «Libro de Reclamaciones» creada como página estándar.
• Formulario embebido de SaaS externo (claimbook.pe u otro) via iframe o widget JavaScript.
• Enlace en menú principal con anchor «Libro de Reclamaciones».
• Si la plataforma no permite integración profunda, redirigir al portal del SaaS desde el enlace.

React, Next.js, Vue, Nuxt (headless)

Stacks modernos con desacoplamiento entre front y back. Patrón recomendado:

• Componente <LibroReclamaciones /> reusable, embebido en layout principal.
• Endpoint API (Node, Python, Go) que valide y registre la hoja con todos los campos.
• Schema validation con Zod o Joi para los campos del Anexo I.
• Almacenamiento en base de datos relacional con esquema multi-tenant.
• Generación de PDF server-side con Puppeteer o WeasyPrint.
• Email via SendGrid, Mailgun o AWS SES con plantilla MJML.
• Storage S3 o equivalente con cifrado.
• Webhook al SIREC si aplica.

Por qué los plugins genéricos NO satisfacen el régimen

Tres razones por las que Contact Form 7, Gravity Forms, Typeform o cualquier formulario genérico no cumplen:

1. Falta de campos obligatorios del Anexo I. El Anexo I exige campos específicos con formato definido (RUC, razón social, nombre comercial, dirección del establecimiento, número correlativo). Los plugins genéricos no los traen por defecto y, aunque se puedan añadir, no validan el formato exacto.
2. No generan código único correlativo persistente. Los formularios genéricos generan IDs por submission pero no controlan correlativos a nivel del proveedor con el formato exigido.
3. No reportan al SIREC. Para empresas con ingresos ≥3,000 UIT, el reporte a Indecopi es obligación. Ningún plugin genérico tiene la integración API con SIREC.

El caso Interbank (Resolución 2727-2024/SPC-INDECOPI) sancionó precisamente porque las hojas no tenían los datos exactos del Anexo I. La sanción fue de 3.3 UIT con UIT 2024 (aproximadamente S/ 16,995). Para análisis completo de la escala de multas, anda a cuánto cuesta no tener Libro de Reclamaciones en 2026.

Snippet de referencia: endpoint Node.js para registrar una hoja

Esquema mínimo para una API que reciba el formulario y registre la hoja conforme al Anexo I. Express.js con validación Zod:

// app/routes/reclamaciones.ts
import express from 'express';
import { z } from 'zod';
import { v4 as uuidv4 } from 'uuid';
import { sendEmail } from '../services/email';
import { saveHoja } from '../services/storage';

const router = express.Router();

const HojaSchema = z.object({
  proveedor_ruc: z.string().length(11),
  proveedor_razon_social: z.string().min(3),
  consumidor_nombre: z.string().min(2),
  consumidor_doc_tipo: z.enum(['DNI', 'CE', 'PASAPORTE']),
  consumidor_doc_numero: z.string().min(8).max(20),
  consumidor_email: z.string().email(),
  consumidor_telefono: z.string().min(7),
  servicio_descripcion: z.string().min(10),
  servicio_monto: z.number().nonnegative().optional(),
  tipo: z.enum(['RECLAMO', 'QUEJA']),
  detalle: z.string().min(20),
  pedido: z.string().min(10),
  observaciones: z.string().optional(),
});

router.post('/api/libro-reclamaciones', async (req, res) => {
  const parsed = HojaSchema.safeParse(req.body);
  if (!parsed.success) {
    return res.status(400).json({ ok: false, errors: parsed.error.flatten() });
  }
  const data = parsed.data;
  const correlativo = await getNextCorrelativo(data.proveedor_ruc);
  const codigo = `2026-${data.proveedor_ruc.slice(-4)}-${String(correlativo).padStart(6, '0')}-${uuidv4().slice(0, 8)}`;
  const hoja = {
    codigo,
    correlativo,
    fecha: new Date(),
    plazo_respuesta: addBusinessDays(new Date(), 15),
    ...data,
  };
  await saveHoja(hoja);
  await sendEmail({
    to: data.consumidor_email,
    subject: `Tu reclamo ${codigo} fue registrado`,
    template: 'hoja-confirmacion',
    data: hoja,
  });
  return res.status(201).json({ ok: true, codigo, plazo_respuesta: hoja.plazo_respuesta });
});

export default router;

Este snippet es ilustrativo. La implementación real debe agregar autenticación admin para registros internos, rate limiting (anti-bot), captcha, generación de PDF, almacenamiento cifrado y reporte SIREC para entidades obligadas.

Snippet de referencia: hook WordPress para inyectar enlace en footer

// claimbook-link.php (plugin mínimo)
<?php
/**
 * Plugin Name: Claimbook Link
 * Description: Inyecta enlace al Libro de Reclamaciones en footer
 * Version: 1.0
 */

add_action('wp_footer', function () {
    if (is_admin()) return;
    echo '<div class="claimbook-libro" style="text-align:center;padding:1rem;">'
       . '<a href="' . esc_url(home_url('/libro-de-reclamaciones')) . '" '
       . 'style="text-decoration:underline">Libro de Reclamaciones</a>'
       . '</div>';
});

add_action('wp_head', function () {
    echo '<meta name="claimbook:enabled" content="true">';
});

Este es el mínimo. Una implementación completa para WordPress incluye Custom Post Type, formulario con validación, generación de PDF, integración SMTP, dashboard admin y reporte SIREC.

Snippet de referencia: Liquid hook para Shopify

{%- comment -%} sections/footer-libro.liquid {%- endcomment -%}
{%- if shop.metafields.global.country == 'PE' or shop.permanent_domain contains 'pe' -%}
<div class="libro-reclamaciones">
  <a href="/pages/libro-reclamaciones" class="libro-link">
    Libro de Reclamaciones
  </a>
</div>
{%- endif -%}

Y la página /pages/libro-reclamaciones embebe el formulario de un SaaS externo o construye el formulario nativo con sección Liquid + endpoint en App Bridge.

Checklist técnico de cumplimiento (15 puntos)

1. Enlace al libro virtual identificable desde la home con máximo dos clics.
2. Aviso conforme al Anexo III en lugar visible (header o footer).
3. Formulario con todos los campos del Anexo I del DS 011-2011-PCM modificado por DS 101-2022-PCM.
4. Validación de RUC peruano con dígito verificador (algoritmo módulo 11).
5. Validación de DNI/CE conforme a formatos del Reniec/Migraciones.
6. Generación de código único correlativo con prefijo del año.
7. Confirmación al consumidor por email con PDF de la hoja registrada.
8. Panel de respuesta con alerta a los 12-13 días hábiles.
9. Mecanismo para registrar la respuesta y enviarla por email/carta dentro de 15 días.
10. Cifrado SSL/TLS 1.2+ y AES-256 en reposo.
11. Conservación de hojas por 2 años con backup geo-redundante.
12. Bitácora de auditoría de cada acceso a la hoja.
13. Libro físico de respaldo activable en 1 día calendario.
14. Reporte al SIREC si ingresos ≥3,000 UIT (S/ 16,500,000 con UIT 2026).
15. Política de privacidad enlazada al formulario, conforme a Ley 29733 y DS 016-2024-JUS.

Si tu equipo cumple los 15 puntos, estás auditable. Si tienes dudas en alguno, te conviene revisar la documentación del DS 011-2011-PCM consolidado disponible en SPIJ y consultar con asesoría legal especializada.

Comparativa: plugins gratuitos vs SaaS profesional

Auditoría del Indecopi: cómo prepararte

Si Indecopi notifica una verificación de cumplimiento, conviene tener listos:

• Captura de pantalla del libro virtual en home, en menú principal y en formulario completo.
• Listado de hojas registradas en los últimos 24 meses con código único, fecha, materia y estado de respuesta.
• Constancia de respuesta de cada hoja respondida (email, carta, copia firmada).
• Bitácora de modificaciones con timestamp y usuario.
• Política de tratamiento de datos firmada con encargados (cloud, email).
• Registros del SIREC si aplicó el umbral de 3,000 UIT.
• Acta de pruebas técnicas que demuestre el funcionamiento del formulario y la generación de PDF.

Los plazos de entrega de información a Indecopi son del orden de 3 días hábiles desde el requerimiento (artículo 11 del DS 011-2011-PCM). Si no cumples, agravante adicional.

Errores frecuentes en integraciones nuevas

Olvidar la firma electrónica del proveedor

El Anexo I exige firma del consumidor y del proveedor. Sistemas que generan PDF con la firma del consumidor pero sin la firma electrónica del proveedor (o sin sello digital) son sancionables. La solución: hash criptográfico del PDF firmado con certificado digital del proveedor (clave privada custodiada por el SaaS o por la propia empresa).

Confundir reclamo con queja

Reclamo es inconformidad con bien o servicio que pide reparación. Queja es manifestación de mala atención sin pedido económico concreto. El formulario debe permitir al consumidor elegir, con explicación corta de la diferencia.

Plazo mal calculado

Los 15 días son hábiles, no calendario. La regla es excluir sábados, domingos y feriados nacionales. Para 2026 son 16 feriados nacionales según el Decreto Legislativo 713 (Año Nuevo, Jueves Santo, Viernes Santo, Día del Trabajo, Batalla de Arica, San Pedro y San Pablo, Día de la Fuerza Aérea, Fiestas Patrias 28 y 29 de julio, Batalla de Junín, Santa Rosa, Combate de Angamos, Todos los Santos, Inmaculada Concepción, Batalla de Ayacucho, Navidad). Una librería como date-fns con locale es-PE simplifica el cálculo.

No cubrir 24/7

El libro virtual debe estar disponible 24/7. Mantenimientos programados deben hacerse fuera de horario de mayor tráfico y, si exceden cierto tiempo, requiere libro físico de respaldo.

No integrar con SIREC

Si tu empresa supera 3,000 UIT y no reporta al SIREC, la sanción es de 5 a 10 UIT (S/ 27,500 a S/ 55,000). La Casación LAN Perú del 5 de marzo de 2020 ratificó la validez de la obligación. La integración debe ser por API conforme al artículo 16 del Reglamento.

Cómo se conecta este pillar con el cluster Modelos Digitales

La integración técnica del Libro de Reclamaciones es la base sobre la cual descansan los artículos verticales del cluster Modelos Digitales. Para profundizar en casos específicos:

• Guía legal completa del Libro de Reclamaciones virtual 2026 (pillar Cluster 1).
• Ley 32495 y comercio electrónico: el cambio normativo que respalda toda la implementación.
• Libro de Reclamaciones para tienda online: aplicación práctica al ecommerce general.
• Libro de Reclamaciones para marketplaces: modelo seller + operador.
• Libro de Reclamaciones para taxis por aplicativo: la Casación 20463-2022 explicada.

Preguntas frecuentes

Conclusión

Tres ideas para llevar a la próxima reunión técnica con tu equipo: la Casación 20463-2022 y la Ley 32495 cerraron toda discusión sobre si el ecommerce o las apps móviles necesitan libro virtual; la implementación correcta exige nueve elementos verificables que cubren accesibilidad, formato, trazabilidad y reporte; los plugins genéricos quedan cortos y exponen la operación a sanciones evitables. Si tu equipo va a construir desde cero, evalúa el costo total contra el riesgo de multa y el costo de auditoría: el SaaS profesional gana en la mayoría de los casos.

¿Quieres saltarte el desarrollo a medida y poner el libro virtual conforme al Reglamento en producción este mes? Conoce claimbook.pe: Libro de Reclamaciones virtual con todos los campos del Anexo I, integración SIREC, panel de respuesta con alerta a 12 días, multi-tenant para cadenas y SDK para WordPress, Shopify, VTEX, Magento y stacks headless. Pide tu demo o empieza gratis.