Pricing por uso para SaaS: los patrones de metering y billing que funcionan

Al final de esta guía tendrás una pipeline de billing por uso funcionando en un SaaS Next.js + Stripe: un meter que ingiere eventos al ritmo de la API, un plan híbrido que combina suscripción base con overages por consumo, registro idempotente de eventos, una vista de uso dentro del producto y los controles que evitan que un bug de billing se convierta en una avalancha de reembolsos.

El pricing por uso ya no es una elección marginal. En los benchmarks 2025 de OpenView y Metronome, el 85% de los SaaS encuestados había adoptado o estaba probando pricing por uso, frente al 28% en 2023. Las empresas con modelos por uso reportan aproximadamente 10% más de net retention y 22% menos de churn que las que usan modelos por asiento. La razón es simple: cuando el revenue crece con el éxito del cliente, el cliente lo ve como gasto proporcional, no como una línea fija que recortar.

El contrapeso es que ahora vendes algo más difícil de entregar. Un error del 1% en el metering de un plan por asiento es invisible. Un error del 1% en un plan por consumo es un ticket de finanzas y un cliente perdido.

Lo que necesitas antes de empezar

• Un SaaS ya en Stripe (Subscriptions o Customer en su sitio) o un PSP comparable. Los patrones de abajo se escriben sobre Stripe Billing porque es el punto de partida más común y ofrece Meters y Meter Events como primitivas de primera clase.
• Una unidad facturable claramente nombrada. Llamada API, token, seat-hour, fila procesada, imagen generada. Si no la nombras en tres palabras, no estás listo para tarifarla.
• Una fuente de eventos que ya existe. Logs, colas, escrituras de BD que registran la unidad. No levantes un bus de eventos nuevo solo para facturar: instrumenta lo que ya corre.
• Un contacto de finanzas que firme las reglas de redondeo, proration, política de reembolso e impuestos. No es opcional en un plan B2B.

Paso 1. Elige una forma de pricing, no solo un precio

La forma que mejor convierte y renueva en 2026 es el plan híbrido: una suscripción base que cubre una cuota incluida generosa, más una tarifa por unidad por encima. La mayoría de los clientes lo prefiere porque obtiene una base previsible y solo paga más cuando realmente escala. El pay-as-you-go puro funciona para herramientas dev e infraestructura, donde los compradores lo esperan; para el resto deprime la conversión de trial a paid.

Decide tres números y escríbelos antes de tocar código:

1. Precio base por tier (Starter, Team, Business).
2. Cuota incluida por periodo de facturación en cada tier.
3. Precio unitario de overage, idealmente con un escalón de volumen por encima de un umbral (así un cliente que hace 10x la cuota incluida no paga 10x el overage).

Mantén el modelo aburrido el primer día. Tarifa por tiers con un solo eje de overage ya basta. Añade meters por feature solo después de que el primer modelo lleve dos ciclos en producción.

Paso 2. Define el meter

En Stripe, un meter es el esquema de una señal de uso agregada. Configuras el meter una vez: nombre del evento (por ejemplo api_request), método de agregación (count o sum) y el campo del payload que lleva el valor numérico.

// One-off, desde un script de servidor
await stripe.billing.meters.create({
  display_name: 'API requests',
  event_name: 'api_request',
  default_aggregation: { formula: 'count' },
  customer_mapping: { event_payload_key: 'stripe_customer_id', type: 'by_id' },
  value_settings: { event_payload_key: 'value' },
});

Tres reglas. Primera, un meter por dimensión facturable; no multipliques dos significados en el mismo event name. Segunda, el customer mapping es el contrato que ata un evento a una línea de factura: si está mal, no aflorará ningún uso. Tercera, antes o después renombrarás el evento; mantén estable el id del meter.

Paso 3. Registra eventos de forma idempotente

Este paso decide si tu modelo es confiable. Cada meter event debe llevar una idempotency key derivada de una propiedad estable de la acción subyacente (request id, job id, message id), no de un timestamp. El endpoint Meter Events de Stripe acepta un campo identifier con ese fin y el endpoint admite hasta 1.000 llamadas por segundo en live mode.

// En tu handler, después de que el trabajo haya tenido éxito
await stripe.billing.meterEvents.create({
  event_name: 'api_request',
  payload: {
    stripe_customer_id: customer.stripeId,
    value: '1',
  },
  identifier: requestId, // ya único arriba
  timestamp: Math.floor(Date.now() / 1000),
});

Envía el evento después de que el trabajo haya tenido éxito, no antes. Una llamada fallida que ya facturaste es el peor bug posible, porque genera facturas que el equipo de soporte no puede defender. Deduplica en el límite de ingesta y trata las colas de aguas abajo como best-effort.

Paso 4. Conecta el meter a un Price y a una Subscription

Crea un Price de Stripe con recurring.usage_type = 'metered' que referencie tu meter. Engancha ese price a la subscription junto al price flat-fee base. El cliente ahora tiene una subscription con dos items: un item flat-fee que factura previsible y un item metered que factura el consumo agregado al cierre del periodo.

El overage por tiers es una propiedad del Price metered: configura tiers con una cuota incluida free y un precio unitario de overage. Stripe gestiona la matemática en el momento de la factura.

Paso 5. Muestra el uso dentro del producto

Esta es la palanca que la mayoría de equipos ignora y la que genera la mayor mejora de retención. Renderiza un widget de uso en el dashboard con tres cosas: consumo del periodo actual, cuota incluida y porcentaje usado, overage proyectado a final de periodo según el run-rate actual. Saca los datos de tu propio event store, no de Stripe; Stripe es el sistema de registro del billing, no de la UX en vivo.

Envía una notificación al 75%, al 90% y al 100% de la cuota incluida. Los clientes que nunca ven un número se llevan un susto en su primera factura; los que ven el número subir hacen upgrade voluntariamente. El mismo widget es donde colocas un CTA de upgrade cuando un cliente empieza a pasarse del cap dos ciclos seguidos.

Paso 6. Verificar que funciona

• Ida y vuelta evento-factura. Envía un conjunto controlado de eventos de prueba para un cliente test en un Stripe test clock. Avanza el reloj hasta el cierre del periodo. Confirma que la línea de factura cuadra al céntimo con la matemática esperada.
• Replay duplicado. Envía el mismo evento dos veces con el mismo identifier. El segundo no debe incrementar el meter.
• Eventos atrasados. Envía un evento con timestamp 24 horas en el pasado. Confirma que cae en el periodo correcto y que el cierre nocturno no ha bloqueado ya el periodo.
• Customer mapping. Envía un evento con un stripe_customer_id desconocido. Confirma que se rechaza ruidosamente y aparece en tu alerting, no se descarta en silencio.

Modos de fallo comunes

El meter muestra cero uso en producción. Casi siempre un bug de customer mapping: el campo del payload no coincide con customer_mapping.event_payload_key del meter. Stripe acepta los eventos pero no los liga a ningún cliente. Añade una aserción en servidor que cada evento saliente lleve un customer id conocido.

La matemática de la factura se desvía 1-5%. Race conditions entre la emisión del evento y el éxito del trabajo. Mueve el emit al camino de éxito, y si no puedes, pasa a un outbox transaccional: escribe el meter event en una tabla local dentro de la misma transacción de BD que la escritura de negocio, después un worker drena la tabla hacia Stripe con reintentos.

Rate limits de Stripe en picos. El tope de 1.000 eventos por segundo es por cuenta, no por cliente. El blog de ingeniería de Stripe describe el patrón de batching: agrega eventos en cliente en una ventana de 1 a 5 segundos, emite un evento Stripe por (customer, meter, ventana) en lugar de uno por petición. No pierdes nada en factura, ganas 100x de margen.

Cliente que disputa un cargo que no puede reconciliar. Construye la ruta de disputa dentro del producto, no en los tickets de soporte. Expone un export CSV de cada evento registrado para el cliente en el periodo disputado. La carga de soporte se reduce a la mitad en cuanto el cliente puede auditar su propio uso.

Cuándo dejar Stripe Billing por una plataforma dedicada

Stripe Billing lleva cómodamente a un SaaS de un solo meter hasta ARRs de mitad de ocho cifras. Los puntos de quiebre donde los equipos pasan a Metronome, Orb o al open source Lago son: más de tres meters independientes, pricing contract-aware (tarifas custom por cliente enterprise firmadas en DocuSign), entitlements en tiempo real (paywalls que necesitan saber en menos de 50 ms si al cliente le queda cuota), o requisitos multi-PSP donde el lock-in con Stripe se vuelve un riesgo estratégico. Por debajo de esos puntos, cambiar de plataforma es trabajo de ingeniería que no produce revenue.

Dos ciclos de datos en vivo valen más que dos meses comparando plataformas. Despliega el plan híbrido aburrido en Stripe Billing, observa las facturas y después decide.

Para profundizar

• Multi-tenant desde el día uno para la arquitectura de datos bajo cualquier plan por uso.
• El agency tax para el contexto de pricing más amplio donde encaja esto.