Authority controls, evidence, and transparent operating boundaries.

1. Scope

This Privacy Policy applies to information processed through the Paylogee public website, Beta platform, sandbox environments, authenticated application, contact forms, developer interfaces, policy and approval workflows, evidence surfaces, and related services. It does not govern independent privacy practices of third-party infrastructure, model, financial, card, settlement, or other providers.

2. Data-minimization principle

Paylogee's current policy is to collect information reasonably necessary to operate, secure, administer, audit, support, and improve the Beta. Information should not be collected merely because it may become useful in the future.

3. Information that may be processed

• Account and organization information such as name, business email, role, tenant membership, and access level.
• Machine and platform configuration such as tenant, environment, agent identity, spend-account settings, policy configuration, delegated limits, approvals, and integration settings.
• Autonomous-commerce records such as transaction requests, amounts, currencies, merchant/provider context, policy decisions, terms fingerprints, approval outcomes, execution attempts, evidence, and reconciliation metadata.
• Public contact submissions and the integrity/technical metadata used to secure those submissions.

4. Sensitive information users must not submit

Users must not intentionally submit passwords, private keys, production API secrets, seed phrases, card PINs, CVVs, unnecessary government identifiers, medical information, or other credentials through public forms or general-purpose fields not specifically designed to receive that category of information.

5. Purposes of processing

Information may be used to provide and secure the Platform, authenticate users and machine identities, enforce tenant boundaries, administer delegated authority, evaluate policy, process approvals, preserve operational evidence, detect misuse, investigate errors, respond to inquiries, troubleshoot services, enforce applicable governance terms, and improve the product.

6. Tenant and administrator visibility

Organizations using Paylogee may control information submitted on behalf of their personnel, agents, systems, or integrations. Authorized organization administrators may be able to access tenant users, machine identities, policies, approvals, transactions, and evidence. Individual users should therefore understand that information generated in an enterprise tenant may be accessible to properly authorized tenant administrators.

7. Machine and agent data

Machine-generated information is not automatically treated as non-personal. If event data contains or can reasonably be associated with an identifiable person, Paylogee should handle the applicable portion according to the relevant privacy and enterprise-governance requirements.

8. Technical and security metadata

Paylogee may process timestamps, session identifiers, authentication events, request-correlation identifiers, rate-limit events, replay indicators, idempotency information, and security-relevant network metadata. The current public contact intake stores keyed hashes of source IP and user-agent values rather than those raw values in the intake table.

9. Contact-intake integrity records

Public contact submissions receive a unique ticket reference and an HMAC-SHA-256 integrity digest over canonical intake fields. This mechanism is intended to help detect later alteration of the captured intake record. It is not represented as making the entire application database immutable.

10. Cookies and browser storage

Paylogee may use first-party session, authentication, CSRF, security, and preference cookies or equivalent browser storage necessary for the requested application functionality. Paylogee does not claim that the authenticated application is cookie-free.

11. Advertising and sale of personal information

The current Beta is not designed to sell personal information for monetary consideration or use personal information for cross-context behavioral advertising. If that business practice changes, this policy and any legally required preference mechanisms should be updated before the practice is introduced.

12. Service providers and subprocessors

Paylogee may rely on infrastructure, database, email, security, monitoring, development, or communications providers. Providers should receive only the information reasonably necessary to perform the applicable function. A formal subprocessor register should be published before material enterprise production onboarding where appropriate.

13. Financial and execution providers

Future payment processors, card issuers, settlement providers, banks, or network services may independently process information under their own terms and privacy notices. Providing information to Paylogee does not itself mean information has been provided to every future financial provider.

14. Retention

Paylogee retains information for the period reasonably necessary to operate and secure the Beta, preserve relevant evidence, resolve disputes, satisfy applicable obligations, enforce agreements, and support legitimate business requirements. Retention periods may vary by data category. Paylogee does not presently promise a universal deletion period that the product cannot consistently enforce.

15. Access, correction, and deletion requests

Individuals may submit privacy inquiries through the Contact page. Paylogee may require reasonable verification before disclosing, correcting, or deleting information and may need to coordinate with an organization that controls the applicable tenant.

16. Security

Paylogee uses administrative, application, authentication, authorization, evidence, and technical safeguards intended to reduce unauthorized access or use. No system can guarantee absolute security. This policy deliberately avoids claiming a universal encryption algorithm, TLS version, certification, or security guarantee that has not been independently verified across the applicable deployment.

17. Security incidents

If Paylogee becomes aware of a security incident affecting information under its control, it may investigate, contain, remediate, preserve relevant evidence, and provide notifications where applicable law or an applicable agreement requires notification. This public Beta policy does not create an artificial incident-response deadline.

18. Children

The Paylogee Beta is intended for business and professional users and is not directed to children. Public Beta account access should be limited to persons legally able to enter the applicable agreement and, in any event, persons at least 18 years of age.

19. Changes

Material policy changes should receive a new version and updated effective date. Where a change materially alters terms requiring user agreement, Paylogee should seek affirmative acceptance rather than relying solely on passive publication.

1. Pre-registration status and contracting-party notice

These public Beta Terms describe the current operating conditions of Paylogee. Because Paylogee is presently a pre-registration software project, this public page does not fabricate a corporate contracting party. Before external clickwrap acceptance or a production commercial agreement is relied upon, the acceptance flow should identify the actual legal person or subsequently formed entity that is offering the service.

2. Eligibility

Users must be legally capable of entering the applicable agreement and at least 18 years old. A person using Paylogee for an organization represents that the person has authority to act for that organization with respect to the Platform.

3. Organizational authority

Creating a tenant, registering an agent, establishing a spend account, configuring policy, or approving a transaction does not itself create authority outside Paylogee. Users are responsible for ensuring their Paylogee configuration reflects authorization actually granted by their organization.

4. Account and credential security

Users are responsible for reasonable control over account credentials, MFA factors, sessions, service identities, tokens, and authorized devices. Credentials must not be deliberately shared in a manner that defeats access restrictions.

5. Beta nature

The Platform is under active development. Features may change, be restricted, behave differently between environments, become unavailable, or be discontinued. Product demonstrations and roadmaps are not commitments that a feature will become commercially available.

6. Permitted use

Subject to applicable restrictions, the Beta may be used to evaluate autonomous-commerce governance, model delegated authority, configure policies, test approval flows, develop integrations, create simulated transaction workflows, and evaluate available Beta functionality.

7. Prohibited use

• Violating law or another party's rights.
• Accessing or probing another tenant without authorization.
• Defeating authentication, rate limits, policy gates, or approval controls.
• Fabricating organizational authority or impersonating another person or organization.
• Introducing malware, disrupting service, harvesting credentials, or accessing confidential data without authorization.
• Representing sandbox or simulated events as completed settlement when they are not.

8. Autonomous systems

Organizations deploying agents remain responsible for deciding which systems may act on their behalf and what authority those systems receive. Registering an agent does not transfer the organization's legal responsibility for that delegation to Paylogee.

9. Financial authority

A Paylogee policy or approval result reflects configured Paylogee controls. It is not financial advice, bank authorization, legal approval, accounting approval, or a representation that an external provider will execute or settle the requested transaction.

10. Third-party services

External model providers, payment services, card programs, hosting platforms, APIs, networks, and other integrations may be governed by independent agreements. Paylogee does not become responsible for a third party merely because the Platform can interoperate with that third party.

11. Beta fees and future pricing

During waived-fee or pilot periods, Paylogee may display illustrative, shadow, or pro-forma billing information. Unless clearly stated otherwise, those displays do not create an obligation to pay an unpublished future price. A future paid plan should be presented before a user becomes obligated to pay.

12. Suspension and protective action

Paylogee may suspend or restrict access reasonably necessary to protect security, other tenants, legal compliance, platform integrity, or financial safety, including where there is suspected credential compromise, fraud, policy circumvention, unauthorized execution, or material violation of these terms.

13. Intellectual property

Access does not transfer ownership of Paylogee software, source code, documentation, product architecture, visual assets, interfaces, policy models, or other proprietary material. Users retain rights they otherwise possess in information they lawfully provide.

14. Feedback

By voluntarily providing feedback about the Beta, a participant grants the current Paylogee operator a perpetual, worldwide, royalty-free right to use that feedback to improve the Platform, provided this does not transfer ownership of the participant's confidential materials or independently developed intellectual property.

15. No warranty

16. Limitation of liability framework

To the maximum extent permitted by applicable law, the current Paylogee operator should not be liable for indirect, incidental, special, exemplary, punitive, or consequential damages, or for lost profits, lost revenue, loss of business, loss of data, or business interruption arising from the Beta. A specific monetary liability cap and any legally required carve-outs should be finalized with counsel before binding external clickwrap or live commercial use.

17. Governing law and dispute terms

This public pre-registration Governance Hub does not fabricate a governing-law venue, arbitration clause, or corporate contracting party. Those provisions should be finalized together with entity formation, the operator's jurisdiction, and counsel review, then versioned in the applicable binding agreement.

18. Changes and acceptance

Material changes should be versioned. Terms intended to bind external Beta participants should be presented through an affirmative acceptance workflow that records the accepted version, date, user, organization, and integrity evidence.

1. Essential technologies

Paylogee may use first-party cookies or equivalent browser storage necessary for session continuity, authentication, CSRF protection, security, and user preferences. Disabling essential browser storage may prevent portions of the Platform from functioning correctly.

2. Analytics

If analytics are introduced, Paylogee should identify whether they are first-party or third-party, what information they collect, and whether user consent or preference controls are required in the applicable jurisdiction.

3. Advertising

The current Beta is not designed to use the authenticated Platform or Governance Hub for third-party behavioral advertising.

4. Cross-site tracking

Paylogee does not intentionally deploy cross-site advertising trackers as part of the current Beta. If that practice changes, this policy and applicable controls should be updated before cross-site tracking is treated as an established practice.

5. Future preference center

If non-essential analytics or marketing technologies are introduced, Paylogee should provide a genuine preferences mechanism where legally required rather than a decorative consent control.

1. Purpose

These policies define the conditions under which an autonomous or automated request may progress through Paylogee toward an execution boundary during Beta.

2. Authority chain

No autonomous request should be treated as authorized merely because an AI model generated it. A valid decision should be capable of resolving the applicable tenant, environment, agent, delegated spend authority, policy, approval where required, and transaction context.

3. Sandbox-first posture

Unless an environment is explicitly designated and technically enabled otherwise, Beta workflows should be treated as sandbox, simulation, demonstration, shadow, or non-settling workflows.

4. No implied settlement

The existence of transaction records, authorization results, card interfaces, provider adapters, webhook events, x402 interfaces, or reconciliation screens does not itself establish that real funds moved.

5. Delegated limits

Authority may be constrained by amount, cumulative spend, transaction count, merchant, merchant category, country, currency, time, expiration, purpose, velocity, or other configured conditions.

6. Deterministic policy evaluation

Policy results are intended to be deterministic with respect to the configured rules and supplied inputs. Policy evaluation cannot guarantee that an input supplied by an external model, user, merchant, or service accurately represents reality.

7. Bound human approval

An approval should apply only to the transaction terms actually presented for approval. Material changes to amount, counterparty, commercial terms, scope, or transaction identity may require re-evaluation or renewed approval.

8. Fail-closed principle

Where required authority or a required security condition cannot be established, consequential execution should default toward denial, blocking, or escalation rather than silently inferring authority.

9. Idempotency and replay protection

Execution-capable requests should use idempotency, freshness, and replay controls appropriate to the execution surface so accidental duplicates or stale authorizations do not silently become repeated financial actions.

10. External provider decisions

An internal Paylogee ALLOW result does not guarantee an external provider will authorize, process, or settle a transaction. External providers may independently reject, delay, review, or reverse activity according to their own systems and agreements.

11. Virtual cards

Virtual-card features shown during Beta may represent internal card-control models, sandbox credentials, or future execution adapters. A card object displayed by Paylogee must not be interpreted as a live issued payment card unless an actual issuer/provider integration explicitly establishes that status.

12. x402 and other protocols

Protocol support may represent an integration boundary. Displaying x402 functionality does not itself establish active public-network settlement or externally funded liquidity.

13. Freeze, revoke, and kill controls

Authorized administrators should be able to suspend agents, freeze delegated spending capabilities, revoke machine identities, or otherwise stop future authorization where supported. Revocation does not necessarily reverse an external transaction that has already completed.

14. Evidence

Evidence should preserve the authority and decision path associated with a transaction. Evidence does not transform false, incomplete, or misleading user-supplied input into truthful input.

15. Production reliance restriction

1. Identifiable machine actor

Consequential autonomous actions should be attributable to an identifiable machine identity rather than relying solely on an undifferentiated application credential.

2. Human and organizational accountability

An organization remains responsible for deciding which autonomous systems may act on its behalf and what authority those systems receive.

3. Least authority

Agents should receive the minimum authority reasonably necessary for the task being performed, limited by purpose, amount, duration, environment, and applicable business conditions.

4. Explicit delegation

Commercial authority should be intentionally delegated. The existence of model capability, API access, or a technical tool does not itself constitute permission to spend.

5. Deterministic control layer

Consequential financial authority should not depend solely on probabilistic model output. Deterministic policy and explicit configuration should govern transaction permission.

6. Human-in-the-loop escalation

Requests exceeding delegated thresholds or configured risk boundaries should be capable of escalation to appropriately authorized human reviewers.

7. Approval binding

Human approval should bind to the actual transaction context reviewed, including the relevant agent, amount, counterparty, purpose, and commercial terms where available.

8. Separation of duties

Where feasible, the system requesting an action should not silently become the system that grants itself additional financial authority.

9. Tool governance

An agent's ability to request a financial action should remain distinct from its technical ability to invoke every execution tool. Tool availability should not automatically imply tool authorization.

10. Replay protection

Old approvals, signed requests, and previous execution instructions should not remain reusable indefinitely outside their intended scope.

11. Evidence provenance

Evidence should identify the relevant actor, inputs, policy result, approval state, execution attempt, and downstream reconciliation where available.

12. Human override

Organizations should retain appropriate freeze, revoke, deny, and escalation mechanisms for autonomous financial authority.

13. Model failure

AI systems can produce inaccurate, incomplete, adversarially influenced, or unexpected output. Paylogee controls are intended to reduce authority risk; they do not guarantee model correctness.

14. No autonomous expansion of authority

1. Ownership

Except for third-party materials, open-source software, and customer-owned information, Paylogee software, original source code, original documentation, visual design, original workflows, policy structures, schemas, text, graphics, names, and other original materials remain owned by their applicable creator or rights holder.

2. Limited Beta license

Subject to applicable Beta terms, an authorized participant receives a limited, revocable, non-exclusive, non-transferable right to access and use the Beta for authorized evaluation and testing.

3. No transfer of ownership

Access to the Platform does not transfer title, ownership, or other proprietary rights in Paylogee technology.

4. Restrictions

To the extent permitted by applicable law, users may not reproduce, commercially redistribute, sublicense, sell, rent, publicly republish, remove ownership notices from, or create unauthorized competing distributions of proprietary Paylogee material.

5. Reverse engineering

Except where a restriction is prohibited by applicable law, users may not reverse engineer, decompile, or circumvent technical access controls protecting proprietary portions of the Platform.

6. APIs and interfaces

Access to documented APIs or integration schemas does not transfer ownership of Paylogee's internal implementation, architecture, or unrelated proprietary interfaces.

7. Open-source software

Third-party open-source components remain governed by their respective licenses. Paylogee should maintain an appropriate software and license inventory as the Platform matures.

8. Brand and marks

Use of the Paylogee name, logos, design system, or other brand assets is not granted merely by receiving Beta access. Paylogee should not use a federal registration symbol unless the applicable mark is actually registered.

9. Feedback

Feedback may be used to improve the Platform without compensation, but customer confidential information and independently owned intellectual property remain subject to their applicable rights.

1. Beta purpose

The Beta is offered to evaluate product design, policy controls, integration workflows, security, governance behavior, developer experience, and usability.

2. Pre-release software

Participants acknowledge that the Platform is under development and may contain errors, incomplete features, compatibility limitations, or changing behavior.

3. No production dependency

4. Sandbox and test data

Participants should use synthetic, anonymized, or appropriately authorized data whenever practical and should not introduce sensitive production data merely for testing convenience.

5. Credentials

Participants must not upload unrelated production secrets, private keys, passwords, or credentials to public forms or test fields that are not specifically designed and approved to receive them.

6. No SLA

There is currently no contractual uptime, latency, throughput, recovery-time, support-response, commercial-availability, or production-settlement SLA unless separately agreed in writing.

7. No future-feature commitment

Roadmaps, demonstrations, architecture discussions, prototypes, and planned integrations are not promises to deliver a future feature or commercial capability.

8. Changes to the Beta

Paylogee may modify, limit, replace, or discontinue Beta functionality as the product, security controls, operating model, or legal requirements evolve.

9. Testing conduct

Participants must not intentionally degrade service, attack unrelated tenants or infrastructure, access information belonging to others, bypass authorization, or use testing access as permission to cause harm.

10. Vulnerability discovery

Good-faith security findings should be submitted through the Responsible Security Disclosure process. Testing authorization does not extend to systems or third parties that the Paylogee operator does not control.

11. Feedback

Participants are encouraged to report usability issues, security concerns, policy inconsistencies, unexpected outcomes, and integration problems.

12. Confidential Beta cohorts

Closed Beta programs may use a separate confidentiality agreement where non-public architecture, provider arrangements, credentials, customer information, or commercially sensitive roadmap information will be disclosed.

13. No commercial or regulatory reliance

Beta participation must not be represented as proof that Paylogee provides banking, issuing, acquiring, money-transmission, custody, regulated payment processing, or settlement services.

14. As-is availability

The Beta is provided as-is and as-available to the maximum extent permitted by law, subject to rights that cannot lawfully be waived.

15. Suspension and termination

Either side may discontinue the Beta relationship. Paylogee may immediately suspend access where continued access reasonably presents security, fraud, legal, financial, or platform-integrity risk.

16. Future affirmative acceptance

Before relying on these terms as a binding external Beta agreement, Paylogee should present them through an acceptance flow that identifies the actual contracting operator and records the accepted version, user, organization, timestamp, and integrity evidence.

1. Software-provider role

Paylogee is currently a Beta software-control platform designed to govern autonomous commercial authority, policy, approvals, execution boundaries, and evidence.

2. Not a financial institution

3. No custody representation

Current Beta functionality should not be interpreted as a representation that Paylogee accepts deposits, holds customer funds, maintains stored monetary balances, guarantees liquidity, or safeguards funds as a regulated financial custodian.

4. Provider dependency

Future live payment, card, banking, settlement, or network functionality may require separate third-party providers, eligibility reviews, financial accounts, technical integrations, and contractual arrangements.

5. No guarantee of provider acceptance

An external financial provider may independently approve, reject, delay, investigate, reverse, or otherwise handle a transaction under its own rules. A Paylogee internal authority decision is not a guarantee of financial completion.

6. No professional financial advice

Platform output is not financial, investment, tax, legal, accounting, banking, or insurance advice. Organizations remain responsible for obtaining appropriate professional advice for their circumstances.

7. No deposit-insurance representation

Paylogee does not claim that funds associated with a future integration are insured or protected by a deposit-insurance scheme merely because Paylogee can display or govern an execution workflow.

8. Transaction risk

Users remain responsible for verifying transaction purpose, merchant legitimacy, organizational authority, financial consequences, and applicable law before allowing consequential execution.

9. Model risk

AI-generated explanations, classifications, or purchasing requests may be inaccurate, incomplete, manipulated, or unexpected. Paylogee's governance layer is designed to constrain authority; it does not warrant that an AI system's reasoning is correct.

10. Beta operational risk

The Beta may experience interruptions, incomplete records, changing functionality, simulated providers, or other pre-production conditions. No public uptime, latency, recovery, or settlement guarantee is created by this Governance Hub.

11. Third-party risk

External model vendors, infrastructure hosts, card issuers, payment processors, networks, and other third parties operate under independent technical and contractual conditions.

12. Liability framework

To the maximum extent permitted by applicable law, the current Paylogee operator should not be liable for indirect, incidental, special, exemplary, punitive, or consequential damages arising from Beta use, subject to rights and liabilities that cannot lawfully be excluded. A specific monetary cap and jurisdiction-specific carve-outs should be finalized by counsel in the binding agreement rather than fabricated on this pre-registration public page.

13. Actual activity controls classification

Regulatory treatment depends on what a platform actually does, not solely on how it describes itself. Paylogee therefore intends to keep product behavior, provider relationships, custody posture, execution architecture, and public disclosures aligned as the platform evolves.

1. Purpose

Paylogee welcomes good-faith reports that help identify vulnerabilities in Paylogee-controlled Beta surfaces while minimizing harm to users, tenants, data, and third-party systems.

2. Reporting channel

Use the Security / responsible disclosure inquiry type on the Contact page. Include affected surface, reproducible steps, observed and expected behavior, impact, and supporting evidence that does not expose unrelated customer data.

3. Good-faith testing expectations

Researchers should limit testing to what is reasonably necessary to demonstrate a suspected vulnerability, avoid persistence, avoid lateral movement, minimize data access, and stop once sufficient evidence has been collected.

4. Prohibited destructive conduct

• Denial-of-service or deliberate service degradation.
• Destructive modification or deletion of data.
• Credential stuffing, phishing, social engineering, or physical attacks.
• Accessing unrelated tenant, user, or third-party information beyond what is necessary to demonstrate the issue.
• Testing third-party infrastructure or financial providers without their authorization.
• Extortion, threats, or conditioning disclosure on payment.

5. Sensitive evidence

Do not send production secrets, private keys, payment-card data, or unnecessary personal information in the initial report. If sensitive evidence is necessary, request a safer exchange mechanism through the Contact channel.

6. Review and communication

Good-faith reports will be reviewed as operating capacity allows. Paylogee does not publish a response-time or remediation SLA during Beta and does not promise a bounty or payment unless separately agreed in writing.

7. No third-party authorization

This disclosure policy does not grant permission to test systems, providers, networks, financial institutions, or services that are not controlled by the Paylogee operator.

8. Coordinated disclosure

Researchers are encouraged to allow reasonable time for investigation and remediation before public disclosure, particularly where immediate disclosure could expose users or third parties to active risk.