Every provider should have a defined and limited job.

This page explains the third-party service providers that KOMERRA Technologies Limited may use to operate, secure, support, and deliver KOMERRA.

It identifies confirmed core provider categories, named providers known to form part of the current KOMERRA architecture, optional feature providers, the information they may process, and the purpose for which they may process it.

A provider does not automatically receive every category of KOMERRA information. The information available to a provider depends on the service enabled, the affected workflow, the customer’s configuration, the provider contract, and the minimum information technically required.

This page should be read together with the Privacy Policy, Data Processing Agreement, Data Retention Policy, Security & Trust page, Cookie Policy, Responsible AI framework, and applicable enterprise agreement.

KOMERRA is operated by KOMERRA Technologies Limited, a company registered in the Federal Republic of Nigeria with registration number 9681120.

Questions about providers, international processing, processing locations, provider changes, or the provider serving a particular deployment may be sent to support@komerra.app.

Use “Subprocessor Question” in the subject.

Enterprise customers may also request the active provider register and applicable processing terms associated with their deployment.

A “data controller” determines the purposes and means of processing personal data.

A “data processor” processes personal data on behalf of a data controller according to the controller’s documented instructions.

A “subprocessor” is another processor engaged by a processor to perform part of the processing entrusted to that processor.

An “independent controller” determines its own purposes and legal responsibilities for some or all of the information it processes.

A “third-party provider” is a broader term that may include a processor, subprocessor, independent controller, professional adviser, communications provider, payment institution, or another service provider.

Not every provider named on this page acts as a subprocessor in every situation.

KOMERRA generally acts as a data controller for personal data used to operate its own relationship with Account holders, such as Account registration, authentication, service administration, billing, security, support, legal compliance, product communications, and platform protection.

In those circumstances, providers processing the information only on KOMERRA’s instructions are ordinarily KOMERRA’s data processors rather than subprocessors.

A payment, messaging, identity, or similar provider may instead act as an independent controller for processing it performs under its own legal duties and service terms.

A business using KOMERRA may determine why and how its customer, employee, supplier, order, communication, document, and other Workspace information is processed.

Where KOMERRA processes that information for the business under the applicable agreement, the business generally acts as controller and KOMERRA acts as processor.

A provider engaged by KOMERRA to help perform that processing may then act as a subprocessor.

The exact role depends on the service, information, contractual relationship, and applicable law rather than the provider’s name alone.

KOMERRA is configuration driven. A provider is used only where the associated service is enabled, appropriately configured, and supplied with valid credentials or another authorized connection.

A provider supported by source code, environment-variable names, documentation, development mocks, or a planned integration is not necessarily active in production.

A provider-dependent feature should remain unavailable where no approved production provider has been configured.

The existence of this page does not mean that every listed provider processes information belonging to every customer.

Each provider entry should be understood according to its stated function, possible information categories, and activation conditions.

“Possible information” describes the information the provider may receive when the relevant feature is used; it does not mean the provider receives every listed field during every request.

Provider infrastructure, corporate entities, affiliates, support teams, and processing regions may change according to the provider’s own services and applicable contract.

Where a customer requires precise entity, region, or deployment information, the active configuration should be confirmed through enterprise onboarding or a written provider request.

The following providers are associated with KOMERRA’s current core architecture and should remain listed only while their corresponding production services are actively used.

The exact division of workloads must be verified against current deployment configuration before each publication or material update of this register.

Vercel may host and deliver the KOMERRA web application, public website, static assets, server-rendered pages, and related frontend or edge functions.

Possible information may include IP addresses, request headers, browser and device information, URLs, technical logs, public-page content, session-related information in transit, error information, and information submitted through a Vercel-hosted KOMERRA experience.

KOMERRA should avoid placing secrets or unnecessary sensitive information in public build output, client-side environment variables, URLs, deployment logs, or frontend analytics.

A `NEXT_PUBLIC_` environment variable is exposed to the browser and must never contain a server secret.

Railway may host KOMERRA production application services, including API, background-processing, scheduling, and related service workloads.

Where separately configured, Railway may also host managed databases, caches, queues, volumes, logs, networking, or other infrastructure used by those services.

Possible information may include Account and Workspace data processed by the API, application requests and responses, operational records, job payloads, provider events, technical logs, service configuration, and encrypted secrets required by the running workloads.

The public provider register should not claim that every database, queue, cache, or backup is hosted by Railway unless the active production deployment confirms that configuration.

Cloudflare may provide domain-name services, traffic routing, network protection, content delivery, bot or abuse controls, object storage, signed file access, and email routing depending on the services enabled by KOMERRA.

Possible network information may include IP addresses, request metadata, security signals, URLs, connection information, and content transmitted through a configured Cloudflare service.

Cloudflare R2 may store authorized files such as logos, avatars, product images, attachments, generated documents, receipts, payment evidence, exports, and other Workspace files.

Cloudflare Email Routing may process sender and recipient addresses, routing information, technical headers, and message content required to forward an email to the configured destination mailbox.

Cloudflare does not automatically receive application database records merely because KOMERRA uses a Cloudflare domain or DNS service.

Resend may process transactional email sent by KOMERRA, including Account verification, password recovery, security alerts, billing notices, operational notifications, reports, support acknowledgements, and approved customer communications.

Possible information may include sender and recipient addresses, display names, subject lines, message content, templates, delivery events, bounce or complaint information, provider identifiers, IP information, and technical email headers.

KOMERRA should send only information reasonably necessary for the intended communication.

Passwords, one-time passwords unrelated to the message, bank PINs, card security codes, private keys, and unnecessary Business Content must not be placed in email templates or provider logs.

Google or Gmail may process support messages, security reports, legal enquiries, attachments, sender and recipient information, and related mailbox metadata where KOMERRA uses a Gmail-hosted mailbox to receive or send correspondence.

A support mailbox is not an appropriate destination for passwords, authentication tokens, private keys, card security codes, bank PINs, recovery codes, or unnecessary identity documents.

Information received through support should be transferred into a more restricted case or evidence system where the sensitivity or duration of the matter requires it.

The use of Gmail for a mailbox does not mean Google is used for every KOMERRA application workflow.

OpenAI may process information required for an approved AI-assisted workflow where OpenAI is the provider selected by KOMERRA for that workflow.

Possible information may include minimized prompts, user instructions, relevant Business Memory, customer or order context, messages, images, documents, structured fields, generated Output, technical metadata, and safety information.

Only information reasonably necessary for the requested task should be sent to the provider.

OpenAI does not process every Workspace record merely because an AI feature is available.

Provider use, model selection, retention configuration, regional options, and contractual terms should be verified against the active production configuration.

Anthropic may process information required for an approved AI-assisted workflow where Anthropic is the provider selected for that workflow.

Possible information may include minimized prompts, instructions, relevant Workspace context, messages, documents, images supported by the selected model, structured records, generated Output, and technical or safety metadata.

KOMERRA should not send the complete Workspace where a smaller relevant context is sufficient.

Anthropic and OpenAI may be available as alternative providers; this does not necessarily mean the same request is sent to both providers.

The production AI provider may be selected according to feature, model capability, language, input type, reliability, cost, safety requirement, region, customer agreement, or service availability.

A fallback provider must not receive customer information unless that fallback has been approved, contracted, disclosed where required, and configured with appropriate safeguards.

Mock AI providers are for local development and testing and must not be presented as live AI capability.

Production data should not be sent to an unapproved personal AI Account or pasted manually into an unrelated consumer AI service.

KOMERRA may engage an approved AI or specialist provider to transcribe voice notes, extract text from images and documents, translate supported language, classify content, or produce structured business information.

Possible information may include audio, voice recordings, images, screenshots, documents, extracted text, language information, prompts, and generated results.

These providers should be added to this register before material production use where they are separate from the named AI providers.

A library, mock implementation, or unconfigured API path does not establish that the capability is available in production.

Paystack may provide hosted or provider-controlled payment services for eligible KOMERRA purchases where Paystack is enabled.

Possible information may include payer contact information, amount, currency, transaction reference, payment-method information handled by Paystack, payment status, authorization information, refund information, chargeback information, and fraud or security signals.

KOMERRA ordinarily receives payment references, verified status, amount, currency, and other information needed to allocate Credits, issue billing records, reconcile transactions, prevent duplication, and handle disputes.

Paystack may act as an independent controller or regulated financial-service provider for parts of its payment processing rather than solely as a KOMERRA subprocessor.

Flutterwave may provide hosted or provider-controlled payment services for eligible KOMERRA purchases where Flutterwave is enabled.

Possible information may include payer details, amount, currency, transaction reference, payment-method information handled by Flutterwave, verification results, refund information, chargeback information, and security or fraud signals.

KOMERRA should allocate Credits or paid access only after trusted server-side verification of the provider outcome.

Flutterwave may act as an independent controller or regulated financial-service provider for parts of its processing.

A payment provider may determine independently how it performs identity, fraud, regulatory, banking, card-network, settlement, dispute, and legal-compliance processing.

For those activities, the provider may act as an independent controller rather than processing only on KOMERRA’s instructions.

The provider’s own privacy notice and terms may therefore apply directly to the payer.

KOMERRA should not describe a payment provider as a subprocessor for all activity merely because the provider is integrated into the KOMERRA billing flow.

KOMERRA does not ordinarily hold, route, settle, or act as escrow for money that a Mini Store customer pays directly to a business.

A customer’s bank, the business’s bank, transfer service, or payment provider may independently process the customer payment.

Those institutions are not necessarily KOMERRA subprocessors merely because the business displays payment instructions or records the resulting payment within KOMERRA.

KOMERRA may process a payment reference, uploaded evidence, claimed amount, recorded status, or business confirmation as part of the associated order.

Meta services may process information where a business deliberately connects an eligible WhatsApp or Instagram business capability and the provider approves and supports the connection.

Possible information may include business identifiers, telephone numbers, social Account identifiers, message content, message metadata, recipients, delivery status, media, templates, webhook events, and authorization information.

Meta may act as a processor, subprocessor, independent controller, or separate platform provider depending on the service and processing activity.

The existence of a WhatsApp or Instagram integration in product plans or source code does not mean the integration is active for every customer.

Provider rules, consent requirements, messaging restrictions, templates, fees, country availability, and approval status may affect the service.

An approved SMS or telecommunications provider may process telephone numbers, message content, delivery information, timestamps, sender identity, country, provider reference, and technical error information where SMS is enabled.

No SMS provider should be identified as active until its production contract and configuration have been confirmed.

Telephone networks and carriers may process communications under their own legal and operational responsibilities.

KOMERRA should minimize message content and avoid including highly sensitive information where a safer communication method is appropriate.

KOMERRA may engage a provider to verify telephone numbers, email addresses, identity information, government identifiers, business registration information, facial or liveness information, or related evidence where such a feature is introduced lawfully.

Possible information depends on the verification and may include names, contact details, photographs, identity documents, registration numbers, verification references, provider results, device information, and fraud signals.

A provider must be added to the active register before material production use.

KOMERRA should retain the minimum verification result reasonably sufficient for the purpose rather than keeping complete underlying evidence indefinitely.

No verification provider is implied merely because KOMERRA intends to support NIN, CAC, facial, or telephone-number checks.

KOMERRA may engage approved monitoring providers to detect errors, measure service performance, investigate failures, connect incidents with technical context, and support reliability.

Possible information may include page or API route, request identifier, device and browser information, IP information, application version, timestamps, stack traces, performance events, deployment information, and appropriately minimized diagnostic context.

The active monitoring provider should be named in this register before production use where it receives personal data or Business Content.

Diagnostic tools must not become uncontrolled copies of request bodies, authentication secrets, customer messages, files, payment credentials, or complete Workspace data.

Where session replay or interaction reconstruction is enabled, the relevant provider may receive masked page interactions, interface states, navigation, clicks, scrolling, error context, and technical device information.

Passwords, authentication codes, payment credentials, private keys, government identifiers, designated sensitive fields, private documents, and prohibited pages should be excluded or masked.

Replay should be limited to approved purposes such as investigating errors, accessibility barriers, performance failures, and serious usability problems.

The active replay provider, scope, masking controls, retention period, and access process should be verified before the feature is enabled in production.

KOMERRA may use an approved support, ticketing, communication, or customer-service provider to organize requests and responses.

Possible information may include Account and business identifiers, contact details, message content, attachments, issue category, diagnostic information, case history, and support actions.

The active support provider should be named before it receives production personal data beyond ordinary email handling.

Support personnel and providers should receive only the information necessary to understand and resolve the request.

KOMERRA may use approved analytics providers to understand public-page use, product adoption, feature performance, navigation, conversion, and reliability where a lawful basis and any required consent exist.

Possible information may include device information, approximate location derived from network information, page events, feature events, referral information, session identifiers, and limited Account or Workspace references where necessary.

An analytics provider should not receive private Business Content merely because it tracks page activity.

The active provider, cookies, identifiers, retention, and consent requirements should also be reflected in the Cookie Policy.

KOMERRA may evaluate additional providers for hosting, payments, messaging, AI, speech, OCR, translation, identity verification, monitoring, support, analytics, maps, or other services.

A provider under evaluation is not considered part of the active production register merely because it appears in a roadmap, code branch, environment example, architectural document, or internal comparison.

A material provider should be added to the register and complete the applicable review before receiving production personal data.

Optional providers should remain disabled until valid credentials, contractual terms, security controls, lawful transfer arrangements, and operational ownership are in place.

A provider should receive only the categories of information reasonably required to perform its defined service.

Using one provider for hosting does not authorize it to use customer information for unrelated advertising, profiling, model training, resale, or independent commercial purposes unless a separate lawful role and transparent basis apply.

Provider access should be limited by contract, service configuration, credentials, tenant controls, network controls, encryption, retention rules, and authorized personnel.

A provider’s ability to process information technically does not create permission to use it for an unrelated purpose.

Before material use, KOMERRA should assess the provider’s role, service necessity, security controls, privacy terms, subprocessor chain, breach process, deletion capabilities, retention, locations, legal obligations, reliability, access controls, and available contractual protections.

The depth of the assessment should reflect the sensitivity, volume, duration, and importance of the processing.

A provider processing private Workspace records, financial references, identity evidence, or sensitive personal data requires more scrutiny than a provider serving public website assets.

Marketing claims or a provider’s logo alone do not demonstrate that the KOMERRA configuration is compliant or secure.

Providers acting as processors or subprocessors should be governed by appropriate written processing terms.

Those terms should address the processing purpose, scope, duration, information categories, data subjects, instructions, confidentiality, security, incidents, data-subject assistance, audits or compliance information, additional subprocessors, international transfers, retention, return, deletion, and termination.

A provider’s standard agreement may be supplemented where the nature or risk of KOMERRA processing requires additional protection.

The public register does not replace the Data Processing Agreement between KOMERRA and a business customer.

Provider personnel should access KOMERRA information only where necessary to provide, secure, maintain, support, or investigate the relevant service.

Providers should apply suitable confidentiality duties, access controls, authentication, logging, training, and disciplinary or accountability measures.

Routine support access should not expose complete customer information where a minimized diagnostic example is sufficient.

Emergency or privileged provider access should be limited, attributable, reviewed, and removed when no longer required.

A named provider may use its own affiliates, infrastructure operators, support providers, data centres, content-delivery networks, or other subprocessors.

KOMERRA should review the provider’s subprocessor terms and available notification mechanism where those entities may process KOMERRA personal data.

Listing a primary provider does not mean the primary provider operates every server, support function, or technical dependency itself.

Where a provider’s downstream subprocessor creates a material new risk, KOMERRA should assess available safeguards, alternatives, configuration changes, or contractual rights.

Providers acting as processors or subprocessors should notify KOMERRA promptly after becoming aware of a personal-data breach affecting KOMERRA information.

The provider should supply information reasonably required to assess the nature, scope, affected data subjects, affected records, likely consequences, containment, remediation, and notification obligations.

KOMERRA may need to coordinate with the provider before complete incident information becomes available.

A provider incident does not remove KOMERRA’s responsibility to assess its own legal, contractual, customer, and data-subject obligations.

Providers acting on KOMERRA’s instructions should assist KOMERRA where necessary to respond to lawful requests for access, correction, deletion, restriction, objection, portability, or other applicable rights.

A data subject ordinarily submits the request to the relevant controller rather than contacting every infrastructure provider separately.

Where KOMERRA acts as processor, the business customer remains responsible for deciding how a request concerning its controlled data should be handled.

KOMERRA may pass documented instructions to an applicable subprocessor and track completion where required.

Each provider should retain information only for the period required to perform its defined service, comply with a documented legal obligation, protect security, or resolve an applicable dispute.

Provider retention may differ from the retention of the corresponding active KOMERRA record because logs, backups, payment records, security evidence, and provider legal obligations may follow separate rules.

At termination or expiry of the relevant purpose, the provider should delete, return, anonymize, or restrict the information according to the applicable agreement and lawful exceptions.

Provider-side deletion, backups, and evidence should be addressed in the KOMERRA Data Retention Policy and internal retention register.

When a processing relationship ends, KOMERRA should revoke provider credentials, disable integrations, remove access, stop new data transmission, address queued or scheduled work, and request return or deletion where applicable.

Migration to another provider should not create uncontrolled duplicate copies or leave the former provider active without a continuing purpose.

KOMERRA should retain appropriate evidence of termination, credential revocation, export, deletion request, or provider confirmation.

A provider may retain narrowly limited information where it has an independent legal obligation, but such information should not remain available for ordinary service use.

Some providers may process, store, support, or permit authorized access to information outside Nigeria.

The use of a globally distributed service can involve cross-border processing even where a preferred hosting region has been selected.

KOMERRA should identify the relevant transfer basis, recipient, destination or processing arrangement, contractual protections, security safeguards, and any applicable exception before the transfer occurs.

A provider’s general statement that it operates globally is not, by itself, a sufficient transfer assessment.

KOMERRA should maintain internal records of material cross-border transfers and the safeguards relied upon.

A stated hosting region may identify the principal storage or computing region without guaranteeing that support, security, backups, delivery, telemetry, or provider administration never occurs elsewhere.

KOMERRA should not promise Nigeria-only or region-only processing unless the complete architecture, provider terms, support access, backups, and subprocessors actually support that promise.

Enterprise customers with location requirements should raise them before activating the affected service.

A contractually agreed deployment restriction takes priority over general marketing language for the relevant customer.

KOMERRA may add, replace, or remove providers as its infrastructure, features, security requirements, costs, countries, legal obligations, and customer needs change.

This register should be updated before or within the applicable period for a material provider change.

Where a Data Processing Agreement or applicable law requires advance notice, KOMERRA will provide notice through the agreed email, Account, Workspace, website, enterprise, or contractual channel.

A provider change that does not expose customer information or materially alter processing may not require the same form of notice as a new provider receiving private Workspace data.

Where an applicable agreement provides an objection right, the customer should submit a reasoned objection within the stated notice period.

The objection should identify the customer, affected service, provider, specific data-protection concern, and any requested mitigation.

KOMERRA may respond by providing additional information, changing configuration, limiting the provider’s scope, offering a reasonable alternative, delaying the affected feature, or taking another proportionate measure.

Where no reasonable resolution is available, the applicable agreement will govern whether the affected service may be discontinued or terminated.

An objection process does not require KOMERRA to maintain an obsolete or insecure provider indefinitely.

KOMERRA may need to introduce or replace a provider urgently to address a security incident, major outage, legal restriction, provider termination, sanctions issue, loss of service, or other material risk.

Where advance notice is not reasonably possible, KOMERRA should provide notice as soon as appropriate and explain the general reason without exposing sensitive security or contractual information.

Emergency use does not remove the need for proportional due diligence, contractual protection, minimization, and later review.

A customer may instruct KOMERRA to connect with a provider selected, owned, or contracted directly by that customer.

Depending on the arrangement, that provider may not be a KOMERRA subprocessor because the customer determines and controls the relationship directly.

The customer remains responsible for ensuring that it has authority to connect the provider and that its use complies with applicable law, provider terms, consent requirements, and security obligations.

KOMERRA remains responsible for securing its own integration boundary and following the documented instructions applicable to the connection.

An enterprise or dedicated deployment may use a different region, infrastructure provider, customer-selected integration, dedicated service, private connection, or restricted provider set.

The applicable order form, Data Processing Agreement, security schedule, architecture documentation, or enterprise provider register will identify any material differences.

A public provider page cannot describe every customer-specific deployment with complete precision.

The customer-specific written agreement governs where it expressly differs from this general register.

KOMERRA aims to provide meaningful transparency about provider identity, role, purpose, data categories, and material changes.

KOMERRA may withhold credentials, internal network details, private configuration, account identifiers, security-sensitive architecture, negotiated pricing, confidential provider information, or details that would increase attack risk.

A request for provider transparency does not authorize access to another customer’s deployment, contract, data location, security information, or private configuration.

The use of a well-known provider does not automatically make KOMERRA certified, audited, compliant, secure, or suitable for every regulated use.

A provider’s certification applies only to the provider, scope, services, locations, controls, and assessment identified in the provider’s assurance materials.

KOMERRA will not claim ISO 27001, SOC 2, PCI DSS, government approval, NDPC certification, or another assurance merely because one of its providers holds such an assurance.

KOMERRA’s own implementation, configuration, access controls, contracts, software, and operational practices remain separately relevant.

This page does not claim that every listed provider processes every customer’s information.

It does not claim that every provider acts as a subprocessor for every processing activity.

It does not claim that all information is stored in one country.

It does not claim that source-code support means a provider is active.

It does not claim that payment providers, banks, communication platforms, and customer-selected services act only on KOMERRA’s instructions.

It does not replace the Privacy Policy, Data Processing Agreement, provider contract, or customer-specific deployment documentation.

KOMERRA should review this register whenever it deploys a new provider, changes a processing region, activates a new integration, changes an AI provider, introduces monitoring, changes email or storage infrastructure, or materially changes provider access to personal data.

The register should be reconciled with production environment variables, cloud dashboards, invoices, contracts, data-flow maps, Data Processing Agreements, architecture diagrams, and access records.

Inactive, test, abandoned, or replaced providers should be removed or identified accurately.

A provider should not be omitted merely because its access occurs through an SDK, API, CDN, logging agent, email route, webhook, or downstream processing arrangement.

This register was last reviewed on 20 July 2026.

Send provider and subprocessor questions to support@komerra.app.

Use “Subprocessor Question” in the subject.

Identify the business, Workspace, service, feature, provider category, processing location, or contractual question involved.

Enterprise customers may request the current provider list applicable to their deployment and relevant processing documentation.

Do not send passwords, one-time passwords, private keys, recovery codes, bank PINs, card security codes, or unnecessary identity documents through ordinary email.