Acceso controlado a Stripe para un traspaso de facturación sensible

Una clave secreta de Stripe puede autorizar acciones importantes. Por eso MoveMRR usa Restricted Keys específicas para el acceso normal de origen y destino y comprueba sus permisos. La función de origen necesita leer los objetos que describen la facturación vigente. La de destino necesita los permisos requeridos para recrear los objetos acordados. Separarlas facilita revisar la capacidad concedida.

El principio de privilegio mínimo no produce una lista idéntica para todos los proyectos. Subscription Schedules, cupones, impuestos, Products, Prices o la recreación opcional de webhooks pueden cambiar el alcance. La regla práctica es conceder los permisos documentados para el flujo elegido, rechazar una clave insuficiente y evitar permisos ajenos al trabajo.

Las claves reales almacenadas utilizan Supabase Vault. Tras guardarlas, el secreto real no se devuelve al navegador; la interfaz recibe estado y metadatos de validación, no el valor de la clave. Las operaciones internas solicitan el secreto solo cuando necesitan llamar a Stripe. Si la vía segura de Vault no está disponible, MoveMRR rechaza almacenar una clave real en lugar de degradarla silenciosamente a una codificación Base64.

Una clave real guardada recibe una fecha de caducidad en MoveMRR después de 30 días. Cuando vence, las operaciones rechazan su uso y el proceso de limpieza puede retirar el secreto almacenado. Este límite reduce la retención, pero no entra en Stripe para revocar la credencial. La rotación, revocación y respuesta a incidentes siguen siendo responsabilidad del titular.

MoveMRR no recopila ni almacena números de tarjeta sin procesar. Cuando una migración cumple los requisitos, Stripe puede copiar datos elegibles de clientes y métodos de pago entre cuentas. El flujo de MoveMRR relaciona después los objetos Customer y Payment Method copiados con las nuevas suscripciones de destino. Stripe documenta tanto los datos elegibles como los objetos excluidos de Customer Data Copy.

Esta separación no significa que todos los métodos funcionen sin seguimiento. Métodos no admitidos, ausencia de método predeterminado, rechazos del emisor y Strong Customer Authentication pueden exigir correcciones o intervención. El ensayo y el informe de excepciones son controles operativos, no una garantía de autorización futura.

El sembrado reproduce estructuras seleccionadas de una cuenta real dentro del modo de prueba de Stripe. Para una ejecución, el operador proporciona una clave real de lectura y una clave de prueba con las escrituras necesarias en el sandbox. Ambas viajan como argumentos al proceso del backend y no se insertan en los registros de claves almacenadas del proyecto.

El cliente real es de solo lectura por contrato del código y todas las escrituras del sembrado apuntan a una cuenta de prueba. El servicio valida modo y permisos antes de empezar. La sincronización de clientes entre dos sandboxes preparados es otra operación y utiliza las claves de prueba guardadas para origen y destino. Esta separación impide convertir permisos temporales de sembrado en el acceso normal de una migración real.

MoveMRR puede aplicar controles dentro del producto, pero no decidir quién debe autorizar el acceso en una transacción. Comprador y vendedor deben nombrar responsables para la cuenta de origen, la cuenta de destino, la aplicación, el cutover y el canal de incidentes. También deben acordar cuándo crear las claves, quién revisa las pruebas y quién revoca el acceso tras la conciliación final.

Las credenciales de la aplicación, los Webhook Signing Secrets, los permisos de la base de datos y el acceso del personal están separados del almacenamiento de Stripe API Keys. Un traspaso completo requiere un inventario propio para cada elemento. Esta página no afirma una certificación, un dictamen de auditoría ni una protección absoluta. Describe el comportamiento actual del producto y enlaza las fuentes de la plataforma.