Getting started with Ormuz
Ormuz is a B2B financial-operations orchestration platform. It connects your business systems, a shared object model, configurable processes, and the external services required by your journeys — payment, credit, compliance, financing, data, or communications.
The role of Ormuz
A B2B journey often crosses several systems: e-commerce store, ERP, accounting tool, PSP, compliance provider, risk engine, or financing partner. Without a common layer, every new combination creates specific mappings, rules, webhooks, and handling.
Ormuz places a stable business language and an orchestration layer between these systems. Your processes work with the same concepts of company, order, invoice, payment, or credit limit, while extensions handle connectivity with external systems and services.
Your systems should depend on the expected business outcome, not on the provider that produced it. Replacing an external service or adapting a process should not force every consumer in your information system to change its model.
Position in your stack
Ormuz replaces neither your ERP, your e-commerce platform, nor specialized providers. It connects those building blocks, orchestrates their interactions, and exposes coherent public objects and events to your applications.
Your business systems supply context and remain responsible for their reference data. Ormuz orchestrates the external services and interactions required to achieve the business outcome.
| Your tool | Responsibility in the whole |
|---|---|
| E-commerce, ERP, accounting | These systems remain the sources of truth for the data they own. Ormuz connects them to processes and external services. |
| PSP, KYC, credit, financing, data | These services continue to provide their business expertise. Ormuz decides when to call them, normalizes the useful results, and feeds them back into the process. |
| Internal applications and back offices | They use public Ormuz objects and events rather than knowing every provider contract used in the journey. |
To understand the public surfaces, their responsibilities, and their interactions, see Product architecture.
The four pillars
The documentation deliberately separates four canonical concepts. This separation makes it possible to understand a business object without conflating it with its API endpoint, a process, or the integration feeding it.
Business model
A common language for B2B financial operations
Companies, orders, invoices, payments, credit, and other objects keep the same meaning regardless of the source system or provider.
Understand the business model →Orchestration
Compose business logic without recoding integrations
Processes, Decisions, and Agents are distinct orchestration artifacts: they respectively compose the journey, deterministic policies, and bounded AI activities.
Discover orchestration →Integrations
Connect your information system and add the services you need
Connectors link Ormuz to your business systems; other extensions provide the services your processes orchestrate.
Explore integrations →API & events
Stable public contracts for your applications
Your systems operate Ormuz through APIs and receive business changes through events and webhooks without depending on raw provider contracts.
View public contracts →What you can build
Business guides start from the desired operational outcome and then combine the required objects, processes, integrations, and public contracts.
B2B checkout
Verify a buyer, apply a credit or payment policy, and decide what happens next with the order.
View the journey →Customer onboarding
Collect the required information, run compliance checks, and orchestrate decisions.
View the journey →Payment and reconciliation
Track payment on the buyer side, observe collection on the merchant side, and reconcile amounts with receivables.
View the journey →Buyer credit
Manage limits, capacity, and exposure without locking your model into a provider's vocabulary.
View the journey →Where to start
Follow the First Steps journey
Start with a sandbox account, create your merchant, connect the required business systems, add your services, then run a first end-to-end process.
Understand your scopes
Before multiplying configurations, clarify the difference between user, account, merchant, sandbox, and production.
Go deeper only on the concept you need
Then use the canonical section matching your question: business model, integrations, orchestration, or API and event contracts. Getting started remains orientation, not a second reference.