IndiePackTras un reembolso de Dodo Payments, revoca el permiso mediante un evento verificado en el servidor, pero conserva el pago original, el movimiento de reembolso y la relación con el cliente. Borrar la compra elimina trazabilidad y hace mucho más difícil distinguir un reembolso, un fallo temporal y una persona que nunca pagó.
Índice
¿Qué tablas deben separar el pago del acceso?
Deben separar clientes, pagos o pedidos, eventos recibidos y concesiones de acceso. El pedido conserva importe, producto e identificador externo; la concesión indica si una función está activa y por qué.
Esta estructura permite retirar un producto sin borrar la cuenta ni sus datos. También evita usar el email como unión permanente, un riesgo descrito en la guía para cambiar el correo sin perder la compra.
¿Cuál es la forma rápida: automatizarlo con IndiePack?
La forma rápida es usar IndiePack como base de Next.js 15, Supabase y Dodo Payments. Su recorrido de pagos y webhooks te deja añadir la política de reembolso de tu producto sin inventar primero todo el circuito de cobro.
Ver IndiePackVer precio¿Cómo procesa Next.js un reembolso de forma segura?
Lo procesa verificando la firma, deduplicando el identificador del evento y guardando el cambio antes de ejecutar efectos secundarios. Después actualiza la concesión correspondiente dentro de una operación controlada y registra el motivo.
No aceptes una llamada del navegador con refunded=true ni localices el pedido por un email enviado por el cliente. El mismo principio de idempotencia del webhook impide revocar o notificar dos veces durante un reintento.
¿Un reembolso parcial debe retirar todo el producto?
No necesariamente: la regla depende del catálogo y debe escribirse antes de recibir el primer caso. Puedes conservar acceso, reducir un saldo o retirar una parte concreta, pero el importe reembolsado por sí solo no describe qué función corresponde.
Modela una política por producto y registra la decisión aplicada. Si existe una revisión manual, el panel debe mostrar el pago y el evento sin exponer claves privilegiadas al navegador.
¿Cómo se prueba la revocación sin dañar a un cliente real?
Se prueba en modo de prueba con un pago, el reembolso correspondiente, el mismo evento repetido y un identificador desconocido. Comprueba que el historial permanece, el acceso cambia una sola vez y otra cuenta no se ve afectada.
Incluye una sesión ya abierta y una petición nueva: RLS o el servidor deben denegar la segunda aunque la interfaz conserve estado antiguo. Con IndiePack, el cierre correcto combina un registro auditable con permisos actuales claros y una experiencia que explica al comprador qué ha cambiado.