Customer billing is part of the Persona product model, not something you are expected to bolt on later.
Many products need to charge end customers directly inside the experience through credit, balance, or recurring access models.
Persona is designed to support that customer-facing billing layer as part of the runtime.
What the capability is for
Persona can support end-customer charging directly inside the product experience.
That means teams can build customer-facing monetization flows around the same runtime that already handles memory, plans, chat, agenda, and other product surfaces.
Charging models
Persona is designed to support the most common charging shapes teams need in production:
- top-up
- subscription
- hybrid combinations where a subscription and usage-linked charging need to coexist
The important point is not the label. The important point is that charging can live in the same runtime shape as Persona instead of becoming a separate system the team has to invent from scratch.
Runtime billing accounts
Billing is not treated as an external afterthought.
At runtime, Persona can work against billing accounts that belong to the owning space and deployment model. That gives the system a clean place to:
- read billing state
- apply credits or top-ups
- keep charging posture tied to the runtime
- keep monetization logic close to the Persona and product surfaces using it
That is the piece that keeps charging, entitlement, and product behavior from drifting apart.
Why this matters for product teams
Without this, teams usually end up building a parallel billing core around the AI system:
- one system for the runtime
- another system for subscriptions or credits
- another system for PSP orchestration
- another place to understand whether a customer should still be allowed to use the product
That is usually too fragmented.
Persona gives you a cleaner starting point because billing can sit inside the same product model as memory, agenda, chat, datastore, and other built-in capabilities.
In practice, that means less backend glue just to answer simple questions like:
- does this customer still have balance?
- is this user on a subscription plan?
- should this action consume credit?
- should the product allow this runtime flow to continue?
Payment gateways and PSPs
The current payment path is Stripe-first.
That means Stripe is the concrete PSP baseline today, while the billing model is already shaped to extend to additional external payment gateways as they are enabled.
I would not oversell that as “every gateway already works.” The stronger product message is simpler and more credible:
- Stripe is the live first path
- the billing model is prepared for broader PSP routing over time
What to understand before integrating
If customer billing is part of your deployment, the questions worth answering early are:
- Does the use case need top-up, subscription, or a hybrid model?
- Which product surfaces need access to billing state or charging actions?
- When should the product consume credit or enforce a billing decision?
- Which payment gateway path should the first deployment use?
Those answers shape the integration much more than the choice of checkout widget.