This documentation explains the OwnPay platform, its product boundaries, core concepts, security principles and development direction. Detailed implementation instructions belong in the relevant Merchant and Developer documentation.
Important: Feature availability depends on the relevant product, network, environment and deployment status. Documentation describes intended behavior only where current implementation has not yet been verified.
1. Platform Overview
Our Mission
Our mission is to make programmable digital payments more accessible to businesses, developers and software agents without treating every payment workflow as a separate infrastructure problem.
We aim to provide a coherent layer for initiating payment workflows, applying authorization and spending rules, observing transaction status and connecting payment activity to applications.
The Problem We Address
Payment integrations can involve separate systems for checkout, wallet authorization, blockchain transactions, transaction monitoring, merchant operations and programmatic software payments.
These components often require different interfaces and operational assumptions. OwnPay is designed to bring selected parts of this workflow into a more consistent platform, while relying on supported blockchain networks and external infrastructure where appropriate.
Our Approach
OwnPay focuses on four core principles:
- Accessible payment experiences: Support practical payment workflows for merchants and their customers.
- Programmable payments: Provide developer-oriented interfaces for applications and AI-agent workflows.
- Explicit authorization: Design payment execution around appropriate permissions, spending limits and user or operator controls.
- Verifiable activity: Make transaction status and settlement evidence easier to inspect where supported by available on-chain data.
OwnPay does not replace the underlying blockchain networks, stablecoin issuers, wallet providers or third-party infrastructure that a particular integration depends on.
2. OwnPay Product Ecosystem
The OwnPay platform brings together merchant payment experiences and programmable payment capabilities through a shared product ecosystem across specialized environments:
Merchant & Human Rails
The Merchant Rails product is designed for businesses that need to create and manage digital payment workflows. Depending on implementation and availability, merchant capabilities may include hosted checkout, payment links, point-of-sale workflows, invoicing, transaction monitoring, webhooks and settlement-related tools.
Developer & AI-Agent Rails
The Developer Rails product is designed for software developers building payment-enabled applications and AI-agent workflows. The platform's technical direction includes API-based payment operations, agent authorization, spending policies, Model Context Protocol (MCP), HTTP 402/x402 payment workflows and smart-account-related capabilities where implemented.
Settlement Explorer
The Settlement Explorer is intended to help users inspect supported transaction and settlement information. Where available, records link to the relevant blockchain explorer and clearly distinguish verified on-chain activity from test, simulated or application-generated records.
An explorer record is not, by itself, proof of regulatory approval, a security audit or the overall financial status of OwnPay.
3. Architecture & Payment Lifecycle
OwnPay can be understood as an application and orchestration layer connecting payment experiences, application logic and supported blockchain infrastructure. A typical payment workflow involves:
- Initiation: A merchant, application or authorized agent creates a payment request or intent.
- Validation: The application checks required parameters, environment, permissions and applicable policy rules.
- Authorization: The required wallet owner, signer or authorized execution mechanism approves the transaction.
- Execution: The transaction is submitted to the relevant supported network.
- Verification: The system checks transaction evidence and the confirmation criteria configured for that workflow.
- Notification: Where configured, an application event or signed webhook communicates the resulting status.
- Reconciliation: The merchant or application compares its records with available transaction and settlement evidence.
The exact sequence depends on the integration. Not every product supports every step, and transaction submission, block inclusion, confirmation and finality are distinct states. A payment should not be described as settled solely because a request was created or submitted.
Transaction Verification and Finality Model
Payment status should be based on defined evidence and explicit state transitions. A useful status model distinguishes:
Transaction speed varies by network conditions, fees, RPC performance, confirmation requirements and the workflow being measured. Any public latency statement specifies what is measured and provides a reliable measurement basis.
4. Security & Trust
Non-Custodial Design Principles
OwnPay's design direction emphasizes non-custodial payment workflows where funds are transferred directly between the relevant blockchain addresses rather than being held in an OwnPay-controlled pooled account.
The term non-custodial must be understood in the context of the actual implementation. Wallet ownership, private-key handling, transaction-signing authority, smart-account permissions, upgrade controls and any intermediary contracts determine the real custody and control model. Users should verify the applicable wallet and transaction flow before relying on a non-custodial claim.
Non-custodial design does not eliminate all risks. Users may still face incorrect transfers, compromised devices, malicious approvals, smart-contract vulnerabilities, network outages, third-party failures or irreversible transactions.
Security as an Engineering Responsibility
Security is a continuous engineering responsibility, not a single product feature or a permanent guarantee. OwnPay's security approach prioritizes:
- Least-privilege access and appropriate separation of responsibilities.
- Secure credential storage, rotation and revocation.
- Strict separation between sandbox, testnet and production environments.
- Transaction authorization and server-side enforcement of applicable spending limits.
- Replay resistance, idempotent processing and appropriate webhook signature verification.
- Continuous monitoring, tamper-evident audit records and incident response readiness.
- Protection of personal information, tenant data and confidential integration details.
- Testing of failure cases, recovery procedures and emergency controls.
If you believe you have found a security vulnerability, contact the designated OwnPay security contact through our official contact page or directly at contact@iktiarshovo.com.
Provide a clear description, affected component, potential impact and safe reproduction steps. Do not include private keys, seed phrases, passwords or unrelated personal information. Do not disrupt production systems while investigating a potential issue.
5. Protocol Concepts
Supported Networks and Digital Assets
OwnPay's product documentation references networks including Base (Chain ID: 8453), Solana, BNB Smart Chain (BSC), and opBNB. Actual availability must be confirmed for each product and environment. A network appearing in documentation does not mean every feature is enabled on that network.
Before initiating any transaction, verify:
- The selected network and environment (testnet vs. mainnet).
- The correct asset and official token contract or mint address.
- The destination address and requested payment amount.
- The transaction fees and applicable confirmation requirements.
- Whether the asset is a test token or a real asset.
A token with the same ticker on different networks is not necessarily the same asset. Network-specific token identifiers must be used for verification. Where USDC is supported, integrations should identify the applicable official token contract or mint for the selected network.
AI-Agent Payment Principles
AI agents can introduce new authorization and operational risks because software may initiate actions at machine speed and with limited direct human supervision. OwnPay's AI-agent direction emphasizes explicit permissions, constrained spending and human oversight where appropriate:
- Explicit Action Scope: Define strictly which actions an agent may request.
- Spending Caps: Limit transaction amounts and spending frequency where supported.
- Destination Restriction: Restrict allowable recipient destinations or smart contracts.
- Elevated Approvals: Require additional human approval for sensitive or high-risk transactions.
- Separation of Authority: Keep cryptographic signing authority separate from general-purpose model reasoning.
- Revocation Controls: Provide instant mechanisms to revoke permissions or pause execution.
- Audit Logging: Record payment decisions and execution outcomes for review.
An AI agent should not be assumed to have permission to spend merely because it can access an API. Actual enforcement must occur in trusted application, authorization or wallet-execution components rather than relying only on a model prompt. The availability of MCP, x402, smart accounts, session keys and policy controls depends on the current implementation of the relevant product.
6. Roadmap & Release Status
Environments and Release Boundaries
OwnPay documentation and interfaces strictly distinguish the following operating environments:
- Sandbox / Simulated: A controlled environment that may simulate parts of a payment workflow. Simulated success does not prove that a real blockchain transaction occurred.
- Testnet: A blockchain testing environment using test assets. Testnet transactions do not represent production settlement.
- Production / Mainnet: A real blockchain environment where transactions involve real assets and irreversible financial consequences.
The active environment should be visible before a user executes a payment. Feature status is also explicit across all platforms:
Roadmap Development Principles
OwnPay is being developed iteratively. Product priorities may change as implementation, security validation, testing and user feedback progress. A target date is a planning milestone, not a guarantee of release. Production use involving real assets should be gated by appropriate end-to-end validation, incident readiness, security review and operational approval.
Refer to our official Roadmap page for the latest published status and milestone ledger.
7. Policies, Legal & Contact
Availability, Limitations and Third Parties
OwnPay relies on a combination of application services, supported blockchain networks and, where applicable, third-party infrastructure. Service availability may be affected by network congestion, RPC outages, wallet behavior, external APIs, software defects, maintenance or other events outside the application's direct control.
Blockchain transactions may be irreversible. Token transfers can fail, remain pending or be sent to an incorrect address. Exchange rates and network transaction fees can fluctuate. Documentation does not constitute a guarantee of uninterrupted service, transaction speed, asset value, recovery of funds or suitability for a particular use case.
Documentation Boundaries
This platform documentation explains the OwnPay ecosystem and its design principles. It is not a substitute for product-specific implementation references:
- Merchant operational workflows: https://ownpaylab.tech/merchant/docs
- Developer and AI-agent integrations: https://ownpaylab.dev
- Transaction verification and explorer records: https://scan.ownpay.tech
When documentation conflicts with the behavior of a deployed feature, report the discrepancy through the official contact channel so that the implementation and documentation can be reviewed.
Legal and Compliance Information
OwnPay's services may be subject to laws, regulations, sanctions requirements and third-party provider terms that vary by jurisdiction and use case. Users remain responsible for evaluating their own legal, tax, licensing and compliance obligations where applicable. Access to a product or completion of an onboarding step does not, by itself, establish regulatory approval or guarantee eligibility to use every feature.
Refer to our official Privacy Policy, Terms of Service, Security Architecture, and Compliance Framework for applicable details.
Contact and Documentation Feedback
For general questions, product inquiries or documentation corrections, use the official OwnPay contact directory. Include the relevant page or endpoint, the environment in which the issue occurred, the expected behavior and the observed behavior. Never share passwords, private keys, seed phrases or production secrets.