Cómo diseñar pricing, permisos y límites por propiedad en un SaaS

En 60 segundos: Separá facturación, acceso a funciones, uso y autorización antes de construir el checkout. Stripe puede informar qué suscripción y entitlements están activos. Tu aplicación todavía decide si este usuario puede acceder a esta propiedad y si la cuenta admite otra. Definí upgrades, downgrades, pagos fallidos, reembolsos, demora de webhooks, propiedades eliminadas y excepciones de soporte. Probá esos estados antes de cobrarle al primer cliente.

Un SaaS con precio por propiedad parece sencillo en la landing: Analytics para una propiedad, Operaciones como adicional y un plan combinado con más comparaciones. La complejidad aparece cuando las reglas comerciales se cruzan con cuentas, roles, uso y eventos de pago.

Si cada función consulta el nombre del plan, un cambio de pricing se distribuye por todo el código. Si cada request llama a Stripe, disponibilidad y latencia dependen de una API externa. Si el límite entre clientes queda implícito, una función de billing puede terminar en fuga de datos.

Separá cuatro decisiones

La facturación responde qué compró el cliente y si la relación comercial sigue activa. Los entitlements indican qué funciones están habilitadas. El uso registra cuántas propiedades, comparaciones, reportes o checkouts se consumieron. La autorización decide si la persona actual puede ejecutar la acción sobre ese cliente y esa propiedad.

Estas decisiones se relacionan, pero no deberían convertirse en un solo booleano como isPremium.

Stripe Entitlements vincula funciones con productos y puede notificar mediante entitlements.active_entitlement_summary.updated. La guía de pricing por uso de Stripe explica modelos medidos. Ninguno comprende por sí solo todos tus permisos de cliente y propiedad.

Modelá el producto antes del checkout

Creá una tabla con plan, unidad facturable, función, límite, período de reinicio y comportamiento del downgrade.

Regla	Ejemplo
Unidad facturable	Por propiedad activa al mes
Entitlement	Analytics habilitado
Cuota	Dos competidores por propiedad
Rol	Owner gestiona pagos, limpieza no
Exceso	Bloquear, cobrar o pedir upgrade
Downgrade	Conservar datos y desactivar reportes nuevos

No escondas la política en identificadores de productos. Usá claves estables como analytics, operations o competitor_slots. Mapeá productos y precios de Stripe a esas claves mediante configuración.

Definí si propiedades archivadas cuentan, si una transferencia cambia el cobro y si una suscripción puede cubrir varias organizaciones. Es más barato responderlo en un documento que después de cobrar.

Usá estado local para decidir acceso

Procesá webhooks de suscripción y entitlements de manera idempotente. Guardá el identificador del evento para que un reintento no aplique dos veces el mismo cambio. Actualizá registros locales y dejá que los requests lean ese estado validado.

Una comprobación típica combina:

1. usuario autenticado
2. pertenencia al cliente
3. relación con la propiedad
4. permiso del rol
5. entitlement activo
6. cuota y uso actual

La cuenta puede tener Analytics mientras una persona de limpieza no puede ver reportes financieros. Un pago válido no entrega acceso a todas las propiedades.

La guía de autorización multi-tenant de AWS trata controles por roles y atributos con contexto del tenant. La regla práctica es llevar identidad de cliente y propiedad por endpoints, tareas en segundo plano, exportaciones, búsquedas y cachés.

Aplicá límites sin condiciones de carrera

Supongamos que un plan admite cinco propiedades y dos pedidos crean la quinta al mismo tiempo. Leer la cantidad y después escribir puede aceptar ambas. Usá una transacción, lock o contador atómico para que comprobación y reserva ocurran juntas.

Explicale el resultado al usuario. La respuesta debe mostrar plan, uso, límite y siguiente paso sin filtrar datos de otro cliente. No borres ni ocultes propiedades existentes cuando un downgrade reduzca la cuota. Definí un estado restringido y permití elegir cuál queda activa.

No todo uso se factura. Un competidor puede ser un límite duro mientras una operación de API se cobra por consumo. Escribí si cada número se reinicia, acumula o acompaña a la propiedad.

Diseñá las transiciones de pago

Los webhooks llegan después, pueden repetirse y cambiar de orden. Definí el comportamiento ante finalización de checkout, upgrade, downgrade, pago fallido, cancelación, devolución, fin de prueba y caída temporal del proveedor.

Soporte necesita ver el estado. Mostrá suscripción, último evento, entitlements, uso y cualquier excepción manual con responsable y vencimiento. Una excepción permanente y sin documentar termina siendo un error de pricing.

No uses invoice.paid como única autorización. El evento describe un pago. La aplicación todavía necesita estado del producto y permiso sobre el recurso solicitado.

Probá el límite antes de lanzar

Probá un usuario con dos propiedades, una persona en dos organizaciones, un owner eliminado, webhooks duplicados, eventos tardíos, creación simultánea, downgrade por debajo del uso, reembolso y propiedad borrada. Cambiá el ID de propiedad en una URL. Verificá que exportaciones y notificaciones no crucen clientes.

Probá también la explicación. Página de precios, checkout, configuración de cuenta y mensajes de límite deben describir la misma regla. Si “hasta cinco propiedades” significa cinco activas, escribilo.

El equipo debería cambiar un precio sin reescribir autorización y agregar una función sin inventar otro sistema de cobros. Kiia puede modelar este límite y sus casos raros antes de que la integración de pagos vuelva costoso corregirlo.