Artificial Intelligence is becoming an increasingly important component of modern business software. From intelligent document processing and legal research to customer support, financial analysis, and business automation, large language models (LLMS) are creating new opportunities for software companies to deliver more capable digital products.
However, integrating AI into a business application is only the beginning. Operating those capabilities reliably, managing the cost of AI usage, protecting customer data, supporting multiple AI providers, and collecting payments from customers introduce a different set of engineering challenges.
For businesses operating in Kenya and across Africa, there is an additional consideration: making AI services accessible through familiar payment methods and pricing models that reflect local business realities.
At Tideflash Software Solutions Limited, we are exploring these challenges through Nia Gateway, a multi-tenant AI gateway designed to simplify how business applications connect to AI models, manage usage, and pay for AI services.
Nia Gateway provides a unified interface between applications and AI providers. It incorporates tenant-level access controls, token-based usage metering, prepaid balances denominated in Kenyan shillings, and payment integration through SMPLY PAY and M-Pesa.
The project represents an important step in our broader work at Tideflash: building software infrastructure that enables businesses to adopt emerging technologies without having to engineer every underlying capability independently.
The Challenge: Integrating AI Is Easier Than Operating It
A developer can connect an application to an AI provider using an API key and a relatively small amount of code. Turning that initial integration into a reliable, commercially sustainable feature requires substantially more infrastructure.
Consider a software platform serving dozens or hundreds of businesses. Each customer may use AI differently, consume different numbers of tokens, require different models, and have different expectations around data handling and costs.
Without a dedicated infrastructure layer, the platform operator must build and maintain several capabilities independently.
1. Managing AI costs across customers
AI providers typically charge according to model-specific usage rates, including input and output tokens. When a platform serves multiple customers, a single provider account can make it difficult to determine how much each customer consumes.
A business needs a reliable way to measure usage, calculate costs, maintain customer balances, and associate every charge with the relevant account.
2. Supporting local payment methods
International AI services may rely on foreign-currency billing and payments methods that do not fit every business's financial arrangements.
For Kenyan businesses, M-Pesa is an established payment channel. Integrating local payments into AI access can reduce friction by allowing customers to fund prepaid balances using a familiar method.
3. Avoiding unnecessary provider dependency
Building directly against one AI provider can tie an application to that provider's API structure, model availability, pricing, and operational behaviour.
Adding another provider may require changes to application code, error handling, pricing logic, and configuration.
4. Protecting customer information
Business applications often process information that should remain isolated between customers. A shared AI infrastructure layer must ensure that API credentials, usage records, balances, and administrative permissions are properly scoped.
Provider selection also matters when an application processes sensitive information. Switching to another provider during an outrage should not happen without appropriate controls.
5. Maintaining operational reliability
AI providers can experience timeouts, rate limits, service interruptions, and capacity constraints. Applications that do not manage these conditions carefully can become unreliable or incur avoidable operational costs.
Theses challenges demonstrate why AI adoption is not simply a matter of connecting an API. It also requires an infrastructure layer capable of managing the commercial, operational, and security requirements surrounding AI usage.
Introducing Nia Gateway: A Unified AI Gateway for Business Applications
Nia Gateway is Tideflash's approach to this infrastructure challenge.
It sits between a business application and the AI providers that application uses. Instead of requiring each product to implement separate integrations, usage accounting, billing controls, and provider-specific logic, applications can connect through a common API.
The gateway handles authentication, services selection, pricing, balance validation, provider communication, usage recording, and the return of AI responses.
Each participating application or business operates within its own tenant account, with separately scoped credentials, balances, usage records, and settings.
This architecture is designed to support software companies building AI-enabled products, businesses integrating AI into their internal workflows, and SaaS platforms that need to manage AI consumption across multiple customers.
A common interface for AI services
Nia Gateway exposes a unified completion endpoint:
POST /v1/ai/complete
An application submits a request using its assigned API key. Nia Gateway validates the request, resolves the selected AI service, checks the relevant billing conditions, communicates with the provider, and records the actual usage.
Applications can select a service through a stable identifier rather than embedding every provider's integration logic into their own codebase.
The objective is straightforward: make AI integration easier to manage as business applications grow in complexity and scale.
Designed for Kenya: AI Usage Metered in Kenyan Shillings
One of Nia Gateway's defining capabilities is its support for prepaid AI usage balances denominated in Kenyan Shillings (KES).
Rather than treating AI consumption as an opaque cost attached to a single platform account, the gateway records usage and charges against the relevant tenant.
Usage-based billing
Nia Gateway calculates metered usage using the input and output token counts reported by the AI provider, together with the applicable service rates.
The resulting charge is recorded against the tenant's ledger, allowing the platform to maintain a balance and associate costs with individual requests.
Pricing is effective-dated, meaning a new rate can be scheduled for future use without retrospectively changing the rate recorded for an earlier request.
The system also records exchange-rate snapshots when a service is priced in a currency other than KES. If an exchange rate is stale or unavailable, the gateway makes the affected service unavailable rather than estimating a price without a valid rate.
This approach provides a foundation for more transparent AI cost management, predictable account balances, and customer-level usage reporting.
M-Pesa payments through SMPLY PAY
Nia Gateway integrates with SMPLY PAY to support the funding of customer balances through M-Pesa.
Customers can initiate and M-Pesa STK Push or fund their account through Paybill, using the payment flow configured for their account.
Once a payment is settled and the corresponding transfer is confirmed, the gateway credits the customer's AI usage balance. The integration uses signed webhooks, unique payment references, and idempotent processing to reduce the risk of duplicate credits. A background reconciliation process provides an additional safeguard when a payment notification is interrupted or missed.
Importantly, payment processing and AI usage accounting are handled separately. Customers fund their balances through the payment integration, while individual AI requests are charged against the gateway's own usage ledger.
This separation helps avoid the need to initiate a payment-provider transaction for every AI request.
For businesses in Kenya, this architecture demonstrates how AI infrastructure can be adapted to local payment preferences without requiring every application developer to build a payment integration from scratch.
Multi-Provider AI: Building Beyond a Single Model
AI capabilities continue to evolve, with different providers offering different models, pricing structures, and technical characteristics.
Nia Gateway is designed around a service registry that separates the application-facing service identifier from the underlying provider and model configuration.
This means a platform can manage the services it makes available to customers without requiring every model choice to be hard-coded into the consuming application.
The system overview documents three integration paths:
- Anthropic: A native integration using the provider's Messages API.
- OpenAI-compatible services: An adapter for providers that implement the compatible chat-completions interface.
- Google Gemini: A native adapter for the Gemini API.
The implementation status of these integration is important. The Anthropic integration is documented as operating in the deployed gateway, while the OpenAI-compatible and Gemini adapters are built and tested for activation through configuration.
This architecture creates a foundation for expanding the available AI services as provider credentials, pricing, and operational requirements are configured.
Health monitoring and controlled failover
Nia Gateway also incorporates operational controls for managing unreliable upstream services.
These include provider timeouts, request-size limits, concurrency controls, circuit breakers, and configurable fallback chains.
Circuit breakers help prevent repeated requests to a provider that is experiencing persistent failures. Where fallback is configured, the gateway can attempt another approved service when the original service is unavailable.
However, fallback is disabled by default. This is especially relevant for applications handling sensitive business information, where routing a request to a different AI provider may have implications for data governance.
For applications requiring a specific provider, requests can explicitly prohibit fallback.
The result is a more controller approach to multi-provider AI integration, where provider choice and operational resilience remain subject to application and tenant requirements.
Security and Tenant Isolation as Core Design Principles
Shared infrastructure must provide more than convenience. It must also establish boundaries between the businesses and applications using it.
Nia Gateway incorporates tenant-level isolation across account balances, ledger entries, API keys, provider credentials, rate limits, request logs, and analytics.
This separation is supported by dedicated isolation tests.
Credential protection
Platform provider credentials are held outside ordinary application configuration data, while customer-provided provider keys are encrypted at rest using AES-256-GCM.
The system also uses passwords hashing, signed browser sessions, cross-site request forgery protections, and signed requests to the SMPLY PAY integration.
Controlled outbound requests
The gateway includes protections against server-side request forgery (SSRF), including restrictions on requests to private and reserved network addresses. Provider requests use HTTPS, do not follow redirects, and apply response-size limits.
These controls are important when a service accepts configurable provider endpoints or act as an intermediary between customer applications and external services.
Accountability and auditability
The administrative environment records significant activities, including change to credentials, user roles, service settings, pricing, deposits, and account status.
A durable request log and system error log support operational visibility while keeping prompts and credentials out of the documented logging paths.
These measures are part of the system's engineering design. As with any software platform, their presence should not be interpreted as a guarantee of absolute security or as a substitute for ongoing security reviews, deployment controls, and appropriate operational practices.
Nia Gateway and Yawakili: Applying AI Infrastructure to Legal Technology
An important part of developing infrastructure is validating it through a practical application.
For Tideflash, Yawakili provides that use case.
Yawakili is a legal practice management platform designed to support law firms through digital tools for managing their legal operations. Its AI capabilities include drafting and research workflows.
Through the Nia Gateway proof of concept, Yawakili connects its AI features to the gateway rather than embedding the complete provider-management and usage-accounting layer directly into the application.
This integration demonstrates how a specialised SaaS platform can consume shared AI infrastructure while retaining application-specific controls.
What the integration demonstrates
Centralised AI access: Yawakili can communicate with the gateway through a common API instead of implementing the entire provider integration and billing workflows independently.
Usage Visibility: AI requests can be associated with usage records and charges, providing a foundation for understanding the cost of AI features.
Model selection: Yawakili's AI settings can use the services exposed by Nia Gateway to support model selection for individual features.
Tenant-aware controls: The gateway provides account-level isolation and access controls that are relevant to a platform serving multiple law firms.
Explicit provider behaviour: The documented Yawakili integration disables automatic fallback for its requests. This helps ensure that legal information is not routed to another provider through an unrequested failover path.
The significance of this integration extends beyond legal technology. It illustrates a broader architectural approach in which an application-specific product can rely on a shared AI infrastructure layer for capabilities that would otherwise need to be developed and maintained separately.
Nia Gateway is designed to be sector-agnostic. The same underlying principles can be applied to other multi-customer software platforms, subject to their individual security, regulatory, and data-handling requirements.
Beyond a Single Product: The Potential of Shared AI Infrastructure
The architectural principles behind Nia Gateway are relevant to business beyond legal practice management.
SaaS platforms
Software companies can integrate AI features into their products while using a common layer to manage model access, usage measurement, and customer-level costs.
Professional services
Professional service platforms can use centralised AI access to support document processing, research, analysis, and other workflows while applying explicit provider-selection controls.
Financial and business applications
Platforms working with financial or commercial information can benefit from centralised usage accounting, access controls, and auditable configuration changes. Any deployment in a regulated environment would still need to meet the relevant legal, security, and operational requirements.
Healthcare and public-sector systems
Applications processing sensitive records may benefit from explicit provider selection and disabled by default fallback. Suitability for these environments depends on the specific data flows, provider terms, applicable regulations, and deployment arrangements.
These examples describe potential applications of the architecture, not a claim that Nia Gateway has already been deployed across all these sectors.
The broader opportunity is to reduce duplicated engineering work by providing a reusable infrastructure layer that different products can integrate according to their needs.
Building the Infrastructure Behind AI-Powered Business Software
The next phase of AI adoption will involve more than experimenting with individual models. Businesses will need reliable ways to integrate AI into their products, manage usage costs, support customers, control data flows, and adapt as providers and models change.
Nia Gateway is Tideflash's contribution to solving this infrastructure challenge.
By combining a unified AI API, tenant-aware usage metering, Kenyan shilling-based prepaid balances, M-pesa payment integration through SMPLY PAY, and configurable multi-provider support, the project establishes a foundation for managing AI as part of a business application's operating model.
The Yawakili proof of concept demonstrates how this infrastructure can be applied to a specialised SaaS platform, connecting AI capabilities with shared services for model access, cost accounting, and operational control.
At Tideflash Software Solutions Limited, we believe valuable software infrastructure should make complex capabilities easier to integrate, manage, and extend.
Nia Gateway is one example of that approach: building the layer between emerging AI capabilities and the business applications that put them to work.
