Ofertas privadas de facturación
Canjea un descuento, precio pactado o ampliación de prueba para tu empresa con una cotización revisada y recuperable.
Una oferta privada pertenece a una empresa pagadora concreta y un producto: su plan, asientos de empleados o asientos de empresas gestionadas. Un código para un producto no compra los otros dos. Solo el administrador de plataforma crea o revoca ofertas. La aplicación permite copiar el código a ese administrador; no lo envía automáticamente.
Beneficios y elegibilidad
| Beneficio | Condiciones |
|---|---|
discount | Porcentaje o importe fijo en EUR, con duración once, repeating o forever. Sin acumulación implícita con otro descuento. |
negotiated_price | Precio unitario neto pactado en EUR, incluido cero, no superior al catálogo. Dura para siempre o entre 1 y 24 periodos de facturación; después vuelve al precio de catálogo fijado. |
trial_extension | De 1 a 90 días adicionales en una prueba activa elegible de un plan de contratación autónoma, sin reiniciar una prueba caducada. La prueba acumulada no puede superar 180 días desde su activación inicial fiable. |
La prueba adicional solo puede acompañar a un descuento permanente de plan o un precio pactado permanente de plan. Los precios pactados y las pruebas independientes seleccionan un plan y un intervalo. Los precios temporales muestran la fecha de vuelta, el importe futuro y el requisito de método de pago antes del cobro posterior. Los periodos mensuales y anuales son ciclos de facturación, no cantidades de días intercambiables. Se excluyen Enterprise por contrato, empresas gestionadas actuando como cliente de un plan y compras en sandbox.
Las fechas de prueba usan UTC. La aplicación muestra el final anterior y el nuevo y cualquier cambio de ancla de facturación. Una ampliación independiente no fuerza tarjeta. Los planes caducados, de pago, en gracia o cancelados no pueden usarla. Revocar un código impide canjes futuros y conserva el beneficio ya adquirido y su vuelta programada al precio de catálogo.
Canjear en su contexto
En la aplicación, introduce el código desde el checkout correspondiente de planes, empleados o empresas gestionadas. Facturación también muestra beneficios adquiridos y operaciones. El código es privado: no lo pongas en URLs, incidencias, registros ni ejemplos compartidos. No existe campaña de registro anónimo ni flujo de invitaciones automáticas.
REST y MCP exponen solo canjes de empleados y empresas gestionadas. Los canjes de planes y la administración de ofertas siguen siendo exclusivos de la aplicación. Usa employees:write para /v1/employee-seat-offer-redemptions y companies:write para /v1/gestoria-seat-offer-redemptions; las lecturas usan el scope :read correspondiente. El propietario del producto vuelve a comprobar pertenencia, acceso al módulo, empresa pagadora y restricciones de sandbox.
Preparar envía {code, purchase} y una cabecera Idempotency-Key. Las compras de empleados usan employee_individual (alta de perfil o reactivación de UUID) o employee_batch (un batch_id existente y su quote_version). Las compras de empresas gestionadas usan gestoria_purchase con create, activate o activate_batch. El servidor elige precios, impuestos y cliente pagador; nunca envíes identificadores remotos de Stripe ni totales.
Revisar y confirmar
La fecha de caducidad del código no es la fecha de fin del beneficio. Si aún no existe una primera ancla, el precio temporal se acepta por N ciclos completos desde la primera factura, con benefit_end_basis = first_invoice_pending y benefit_ends_at = null. Un descuento repetitivo pendiente de aplicar usa discount_application_pending. Una ancla conocida se identifica con accepted_anchor; tras comprobar la aplicación, el GET puede mostrar la fecha exacta en UTC con verified_schedule o verified_discount. Esta información de presentación no modifica la cotización aceptada ni su huella.
Cuando una oferta de asientos de empleado o de empresas gestionadas con un beneficio recurrente (un descuento repeating o forever, o un precio pactado) se canjea sobre una suscripción de asientos ya activa, el beneficio empieza en la siguiente renovación: benefit_starts_at es igual a next_bill_at. Hoy solo se cobran las plazas nuevas de la compra, prorrateadas con las condiciones vigentes, así que cash_today_cents no lleva el beneficio y recurring_total_cents ya lo incluye. El periodo en curso no se abona y no se genera saldo a favor del cliente. Un descuento once sigue aplicándose a la factura de hoy. En una primera compra sin suscripción de asientos no hay periodo en curso, y el beneficio se aplica desde el inicio.
La cotización distingue importe elegible, descuento, base neta, impuestos, total fiscal, saldo de cuenta, cobro de hoy e importe recurrente. quote_complete debe ser verdadero antes de confirmar; los valores desconocidos siguen siendo null. Un cobro cero se explica con zero_reason: el saldo de cuenta, un descuento total, un precio pactado gratuito y una prueba activa tienen consecuencias distintas. Revisa advertencias, caducidad, precios futuros y fechas de prueba antes de aceptar quote_version.
Cada propietario expone seis operaciones: POST en su raíz para preparar; GET en la raíz para listar; GET /{id} para consultar; y POST /{id}/quote, POST /{id}/confirm, POST /{id}/cancel. Las mutaciones exigen claves estables distintas por intención. Una repetición idéntica consulta la operación existente; reutilizar una clave con otros datos provoca conflicto. Una cotización cambiada o caducada debe actualizarse y revisarse otra vez. Si todos los asientos de empleados ya están cubiertos, details.reason = offer_requires_chargeable_seats rechaza la oferta sin consumirla; continúa el flujo normal del lote para conservar la cobertura.
Estados pendientes y errores
Una confirmación 202 está pendiente, no es una compra exitosa. Consulta la misma operación tras recargar, un tiempo de espera o autenticar la tarjeta. Sigue allowed_actions y una action_url autorizada y verificada; no crees otro canje. La falta de método de pago puede devolver 402 con details.payment_setup_url. customer_offer_purchase_failed es un fallo final verificado; su operación sigue siendo consultable.
Una oferta no disponible, caducada, agotada o reservada, un plan o intervalo incompatible, un descuento o calendario externo existente, otra compra concurrente, una prueba cuyo inicio ha cambiado o una cotización desconocida producen un rechazo controlado. Cancelar puede exigir restauración financiera. needs_review o customer_offer_legacy_outcome_unknown exigen comprobar la operación existente antes de otra compra. Cancelar una operación no promete el reembolso instantáneo de una factura. Los beneficios aplicados siguen sujetos a las reglas normales de renovación, cancelación y reembolso del producto.
Al perder acceso al producto, el recibo mínimo de Facturación en la aplicación solo permite consultar y cancelar cuando esté permitido. No expone perfiles ni permite confirmar, actualizar condiciones, añadir tarjeta o autenticarla. REST y MCP siguen respetando la restricción global de plan y módulo.
MCP usa prepare_*_seat_offer_redemption, refresh_*_seat_offer_redemption, confirm_*_seat_offer_redemption, cancel_*_seat_offer_redemption, get_*_seat_offer_redemption y list_*_seat_offer_redemptions, sustituyendo * por employee o gestoria. Las mutaciones reciben idempotency_key.
El endpoint autenticado existente de la aplicación GET /api/features publica data.purchase_availability con los booleanos employee_batches y customer_offers del servidor. Estos interruptores controlan las entradas de compra nuevas y las acciones de cotizar/confirmar, no los permisos de empresa. Al estar desactivados o ser desconocidos, la aplicación conserva el historial y la cancelación autorizados. No son variables de entorno frontend ni scopes públicos nuevos.