Precio de las cuentas gestionadas y cambio de pagador

Una cuenta gestionada es una cuenta normal con su propio plan, y tu cuenta la paga hasta que su cliente asume el pago. No hay una lista de precios aparte para las cuentas gestionadas: tu suscripción usa los mismos precios que los planes y los add-ons de cualquier cuenta, y lo que cambia es quién paga. Esta guía explica lo que pagas, cómo eliges y cambias el plan, cuándo te cobramos, qué pasa cuando el pago pasa al cliente, y qué puedes y qué no puedes hacer mientras tu cuenta está en trial o tiene un problema de pago.

Las operaciones de esta guía que haces como proveedor de cuentas gestionadas necesitan el scope privilegiado accounts:read o accounts:write, que * no cubre: cuentas gestionadas explica cómo se conceden y se comprueban. {account} es el id de la cuenta gestionada, el que lista GET /v1/accounts, salvo en provisioning-usage, donde es tu propia cuenta.

Lo que pagas

Por cada cuenta gestionada live cuya gestión está vigente y cuyo cliente no ha asumido el pago, tu cuenta paga tres cosas, siempre mensuales. Todas van en una sola suscripción de tu cuenta, managed-accounts, que tiene un ítem por precio y la cantidad de todas tus cuentas gestionadas sumada, nunca un ítem por cuenta.

Lo que decide el importe:

• Tu nivel de acceso no cuenta. Una cuenta en none, view u operate cuesta lo mismo: el nivel cambia lo que alcanzan tus credenciales, no lo que pagas.
• El plan es el de la propia cuenta. Se guarda en la cuenta gestionada y sus NIF lo siguen. Tu propio plan nunca lo cambia, como explica tu cuenta en trial o con un problema de pago.
• Las cantidades salen del estado real de cada cuenta. Las recalculamos y las enviamos siempre al proveedor de pago como números absolutos, así que repetir una llamada nunca cobra dos veces.
• Los importes son base imponible. La vista previa del plan devuelve la base, sin IVA.

Lo que no te cuesta nada:

• Una cuenta gestionada de pruebas, creada con una clave fact_test_. Nunca llega al proveedor de pago: consulta probar cuentas gestionadas.
• Una cuenta en enterprise. Se factura por contrato, fuera de tu suscripción.
• Una cuenta que no es operable, porque su NIF titular no está active, por ejemplo cuando tu facturación está bloqueada.
• Una cuenta cuya gestión terminó, o cuyo cliente asumió el pago.

Elige el plan

Eliges el plan al aprovisionar la cuenta: plan es obligatorio en POST /v1/accounts, y no hay intervalo que elegir.

Una cuenta en enterprise se acuerda con nosotros por contrato y se factura por contrato, fuera de tu suscripción. No puedes pedirla al aprovisionar y, una vez que una cuenta está bajo contrato, tampoco puedes cambiar su plan con las operaciones de plan: responden el mismo 422 managed_account_plan_not_self_serve.

Cuándo se te cobra

Te cobramos cuando cambia algo que pagas, siempre en la misma suscripción. No hay checkout: si tu cuenta no tiene método de pago, la operación que te cobraría se rechaza antes.

Una reconciliación diaria mantiene las cantidades alineadas con las cuentas reales, sin prorrateo.

Cambia el plan

Puedes cambiar el plan de una cuenta gestionada que pagas en cualquier momento, también después de que el cliente la reclame, mientras sigas pagando. Además del scope, las dos operaciones necesitan que tu nivel de acceso en la cuenta sea operate. Previsualiza el cambio primero y luego hazlo.

Las tools MCP necesitan una API key: el canal OAuth no alcanza accounts:*. El cambio es irreversible, así que necesita una Idempotency-Key (idempotency_key en la tool), y una llamada sin ella responde 422 idempotency_key_required.

Las dos operaciones piden lo mismo:

• La cuenta es tuya y la pagas tú. Tiene que ser una cuenta gestionada aprovisionada por tu cuenta, con su gestión vigente y en el entorno de la clave. Tu propia cuenta, otra distinta, una cuya gestión terminó y una cuyo cliente asumió el pago responden el mismo 404 account_not_found.
• Tu nivel es operate. Con view o none la respuesta es 403 forbidden_action y no cambia nada.
• El plan es emprendedor, empresario o integral. enterprise responde 422 managed_account_plan_not_self_serve.

Previsualiza el cambio

curl -G https://api.factuarea.com/v1/accounts/$MANAGED_ACCOUNT_ID/plan/preview \
  -H "Authorization: Bearer $FACTUAREA_API_KEY" \
  --data-urlencode "plan=empresario"

{
  "data": {
    "object": "managed_account_plan_change_preview",
    "from_plan": "emprendedor",
    "to_plan": "empresario",
    "effective": "immediate",
    "effective_at": null,
    "prorated_amount_cents": 1250,
    "next_invoice_amount_cents": 3500,
    "currency": "EUR"
  }
}

Los importes son céntimos enteros de base imponible, sin IVA. A diferencia de los euros como cadenas de GET …/billing, la vista previa del plan mantiene los céntimos, como dicen los nombres de los campos. Los importes de los ejemplos son solo ilustrativos: pide a la vista previa los reales en lugar de fijarlos en tu código.

Haz el cambio

curl -X PATCH https://api.factuarea.com/v1/accounts/$MANAGED_ACCOUNT_ID/plan \
  -H "Authorization: Bearer $FACTUAREA_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{ "plan": "emprendedor" }'

La respuesta es 200 con la cuenta gestionada. Una bajada muestra el destino en pending_plan y conserva el plan actual en plan:

{
  "data": {
    "id": "0199a1f0-1c22-7a10-b111-6a6b6c6d6e6f",
    "object": "managed_account",
    "external_ref": "cliente-0042",
    "status": "claimed",
    "environment": "live",
    "plan": "empresario",
    "pending_plan": "emprendedor",
    "billing_interval": "monthly",
    "access_level": "operate",
    "display_name": "Talleres García",
    "language": "es",
    "companies": [
      {
        "id": "0199a1f0-1c22-7a10-b111-7a7b7c7d7e7f",
        "tax_id": "B12345674",
        "name": "Talleres García SL"
      }
    ],
    "claimed": true,
    "claimed_at": "2026-09-29T08:00:00+00:00",
    "management": {
      "status": "active",
      "ended_at": null
    },
    "paid_by_provider": true,
    "created_at": "2026-09-27T09:00:00+00:00"
  }
}

• Subir (emprendedor a empresario). Surte efecto y se cobra en el acto, prorrateado, en una sola actualización de tu suscripción, con una factura por el abono y el cargo. La respuesta ya muestra el plan nuevo.
• Bajar (empresario a emprendedor). Queda pendiente hasta el fin del periodo de tu suscripción managed-accounts. No se abona nada del periodo en curso, pero la factura de la renovación ya lleva el plan nuevo y ningún NIF adicional, porque emprendedor no los admite. Cuando el cambio surte efecto, se desactivan los NIF adicionales de la cuenta, nunca su empresa titular.
• Cambiar de idea. Una petición nueva sustituye a una pendiente, y pedir el plan que la cuenta ya tiene la retira. Si el cliente asume el pago antes, la bajada pendiente se descarta y el cliente continúa con el plan actual.
• Un cobro fallido. Si el proveedor de pago rechaza una subida, el plan no se escribe y no queda nada cobrado. La respuesta sigue mostrando el plan anterior, así que lee plan y pending_plan en ella y, si no cambiaron, repite el cambio con una Idempotency-Key nueva.
• Nada que cobrar. Una cuenta de pruebas, o una que no se te cobra porque su pagador está bloqueado, cambia en el acto sin cargo, y su vista previa muestra los dos importes a 0.

Lee lo que pagas

GET /v1/accounts/{account}/provisioning-usage, con tu propio account.id como {account}, cuenta lo que pagas. managed_accounts_by_plan tiene tus cuentas live de cada plan, donde las enterprise no están en tu suscripción, y provider_paid_additional_nifs y provider_paid_employee_seats tienen los NIF adicionales y los asientos de empleado que pagas además de su plan. Necesita accounts:read, y cuentas gestionadas describe la respuesta completa.

La API no devuelve ningún importe por cuenta. El listado de cuentas de clientes de la app muestra el importe mensual de cada una, y la vista previa de una importación masiva devuelve el importe mensual y el prorrateo de cada fila y de todo el fichero antes de que confirmes.

Cambio de pagador

Tu cuenta paga hasta que el cliente asume el pago. El pagador cambia de las formas de abajo, y en todas ellas el cliente continúa con el mismo plan y el mismo precio: nada se reprecia y no hay un plan nuevo que elegir.

Así pasa el pago de ti al cliente, para que nada se cobre dos veces y no haya huecos:

• El cliente empieza a pagar cuando termina el periodo que ya pagaste. Creamos sus suscripciones primero, las verificamos y solo después bajamos la tuya. El primer cobro del cliente cae cuando ese periodo termina, nunca antes. Si esa fecha ya pasó, el primer cobro es inmediato.
• No se te abona nada y no pagas dos veces. Tu siguiente factura sale sin las unidades de la cuenta. No se abona nada del resto del periodo, porque el cliente empieza a pagar cuando termina.
• Un fallo nunca deja la cuenta sin pagador. Reintentamos, y si el pago no se puede completar deshacemos lo que creamos y sigues pagando tú.
• El cliente necesita un método de pago en su propia cuenta. La app se lo pide antes de que el cliente asuma el pago, y no cambia nada hasta que lo añade.
• Una bajada pendiente se descarta. El cliente continúa con el plan que tiene la cuenta.

Síguelo desde tu lado

paid_by_provider te dice quién paga mientras la gestión está vigente. Para darte cuenta de que el cliente asumió el pago, busca estas señales:

• GET /v1/accounts/{account} responde 404 account_not_found, y la cuenta ya no está en GET /v1/accounts.
• GET /v1/me lista la cuenta en client_accounts como un acceso cedido, con origin: "granted" y paid_by_provider: false:

{
  "id": "0199a1f0-1c22-7a10-b111-6a6b6c6d6e6f",
  "name": "Talleres García",
  "origin": "granted",
  "access_level": "operate",
  "status": "active",
  "paid_by_provider": false,
  "environment": "live"
}

Cuando la gestión termina, en cambio, sí publicamos account.management_ended en los endpoints de webhook de tu cuenta.

Enterprise por contrato

Una cuenta bajo un contrato enterprise no tiene plan en el que continuar hasta que lo fijamos nosotros. Si terminas la gestión, o su cliente intenta asumir el pago, antes de que lo hayamos fijado, la respuesta es 422 enterprise_contract_transition_required: no cambia nada y la gestión sigue vigente. Vale también antes de la reclamación, porque el cliente necesitará el mismo plan cuando reclame la cuenta. Contacta con nosotros, fijamos el plan en el que continúa la cuenta y repites la operación. Si ese plan es emprendedor, se desactivan los NIF adicionales de la cuenta, porque ese plan no los admite.

Termina la gestión

DELETE /v1/accounts/{account}/management termina la gestión, como explica cuentas gestionadas. Lo que pasa con el pago depende de si el cliente había reclamado la cuenta: consulta la tabla de cambio de pagador. Necesita una Idempotency-Key, y la tool MCP es end_account_management. La respuesta es 200 con la cuenta y management.status: "ended", y desde la siguiente petición tu cuenta pierde el acceso.

Tu cuenta en trial o con un problema de pago

Aprovisionar una cuenta gestionada live comprueba tres cosas, en este orden, antes de crear o cobrar nada:

1. En trial. Una cuenta gestionada live se cobra desde el primer día, así que una cuenta en su trial solo puede crear cuentas gestionadas de pruebas. Una live responde 422 managed_account_provider_in_trial. Tu cuenta está en trial durante su ventana de prueba sin suscripción, o mientras su suscripción del plan está en su periodo de prueba. Cuando el trial termina y empiezas a pagar, la siguiente provisión live pasa a la comprobación siguiente. Una clave fact_test_ crea cuentas de pruebas durante el trial, sin cargo.
2. El tope. En tu tope de cuentas gestionadas live, la respuesta es 422 managed_accounts_limit_reached. Las cuentas de pruebas no cuentan: limit y remaining en provisioning-usage te dicen dónde estás.
3. El método de pago. Una cuenta live necesita un método de pago en tu cuenta. Sin él, la respuesta es 402 payment_method_required. Da de alta uno en el portal de facturación de la app y repite la llamada.

El mismo orden se aplica cuando reactivas, por external_ref, una gestión que terminó antes de la reclamación.

Si tu cuenta deja de pagar, las cuentas gestionadas que pagas dejan de ser operables. No se borra nada. Ocurre cuando tu propio plan queda impagado, cuando caduca sin ninguna suscripción activa, o cuando tu suscripción managed-accounts termina unpaid o canceled tras los reintentos de cobro. Una renovación fallida no bloquea en el acto: antes se ejecutan los reintentos habituales. El efecto es:

• Todos los NIF de esas cuentas pasan a inactive, con suspension_reason: "payer_blocked", como describe el estado de un NIF. Las llamadas sobre ellos responden 403 company_inactive.
• Se reanudan solos cuando tu facturación vuelve a estar al día, o cuando el cliente asume el pago. Solo se reanudan los NIF que suspendió el bloqueo: uno que la propia cuenta desactivó se queda como estaba.
• Las cuentas gestionadas de pruebas no se ven afectadas.

Por lo demás, tu propio plan es independiente de tus cuentas gestionadas: subirlo, bajarlo o programar su cancelación no cambia nada en ellas, y su suscripción, managed-accounts, no se toca.

Lo que el cliente no puede comprar mientras pagas

Mientras pagas y la gestión está vigente, el cliente no compra nada en su propia cuenta, porque lo que compraría va en tu factura. Sus credenciales, y sus personas en la app y en MCP, reciben 403 billing_managed_by_provider en estas operaciones, sin cargo y sin cambios. En esta tabla {account} es la propia cuenta del cliente:

Leer la facturación no es un error: GET /v1/companies/{company}/billing de un NIF de una cuenta así responde managed: true sin gestoria_seats ni payment_method, así que lo que pagas nunca llega a las claves del cliente.

Por tu parte, no compras asientos de empleado para una cuenta gestionada: la cantidad sigue a sus empleados activos. Los NIF adicionales los da de alta tu cuenta, con el {account} de la cuenta gestionada y nivel operate, y el cargo va a tu suscripción: consulta NIF adicionales. Cuando el cliente asume el pago, la cuenta se paga a sí misma y su titular y sus administradores pueden volver a usar esas operaciones.

Errores

Relacionado