← Prop firm solutions

Your firm
Your customer journey

The turnkey workspace connects a branded website, challenge programs, automatic or stock-based account delivery, orders and customer support

Two ways to work with MIRRO

Turnkey workspace
Use the firm-branded website, trader workspace and back office
Manage content, programs, account stock, orders and support from one place
Engine integration
Keep your existing website, CRM and checkout
Use the Firm API for program evaluation, trading-account connections and signed challenge events

Choose the product for each firm

MIRRO operators select a template when approving a firm and can change it later in Operators’ desk → Firms → Product & features

The firm sees its exact approved usage in Package & features, including enabled features, exclusions and services requiring implementation
Active trader seats, connected-account hosting, API usage and deployment are separate from this approval

Tick the features agreed with that firm
Required features are selected together
Every saved change records a reason and revision; a stale save is refused so another operator’s work cannot be overwritten

Services marked Needs implementation are not available for use
Selecting them does not activate payouts, KYC or another unfinished integration
Removing a feature stops new setup while preserving existing records, cancellation, trade exits and risk monitoring

Managed or dedicated hosting

MIRRO-managed — fewer setup steps
MIRRO operates the application and database with separate firm access
The firm provides its brand, policies, domain and provider accounts
A configured workspace still needs payment, hosting and account-delivery verification before launch
Dedicated — a separate deployment and database
Choose dedicated deployment in your approved package, then open Infrastructure and the server setup form
Enter the firm’s hostname, server address, SSH port and owner email, then select Request installation
The deployment operator verifies access to a fresh Ubuntu 24.04 server before running the installer
The website, trader dashboard, back office, API and trading engine run with a private database

Keep server passwords, SSH keys and database credentials in protected configuration
Saving a setup form does not install the server or migrate existing data
An existing website or database needs a separate migration review
Follow the installation status and health checks in Infrastructure

Your providers belong to your firm

Each firm uses its own payment, payout and identity-provider accounts
Challenge fees settle into that firm’s merchant account
There is no fallback to MIRRO’s merchant account

Checkout includes Paystack, Squad, TransactPay and KoraPay
Automated payout transfers and identity-provider decisions require a separate implementation; selecting a package does not activate them
Staff-recorded payout and identity attestations are not provider verification

Connect service keys through protected server configuration, separately for each firm
Confirm provider approval, currencies, callback signatures, identity and real test results before enabling a service

Choose how accounts are delivered

Automatic broker accounts
When included in your approved package, open Automatic accounts and choose a broker for each program
After a verified purchase, MIRRO requests a demo account in the buyer’s name, connects it and checks the balance, currency and environment before showing it as ready
The selected broker follows the challenge into its next phase
Only brokers that do not require verification codes are offered for automatic creation
Accounts from your stock
Import firm-owned demo accounts with matching balances and currencies into Account stock
Maintain stock for Phase 1, Phase 2 and Funded as required by the program
MIRRO reserves an eligible account and assigns it after payment and connection checks

Check broker availability and hosting capacity before opening checkout
If a broker response is uncertain, staff review the existing request instead of creating another account
Account details appear in the trader dashboard only after delivery succeeds

Moving between challenge stages

Stock-based two-stage challenges use separate pools for Phase 1, Phase 2 and Funded
A verified purchase reserves Phase 1 stock
A passed phase queues a fresh account, while the challenge keeps its purchase reference and complete account history

Open Account stock to see each stage’s available accounts and pending deliveries
The final evaluation requires staff confirmation of identity and the signed funded agreement before a funded demo account can be assigned

Advanced: creating Exness demo stock
  1. Choose a challenge, the number of accounts for each stage and a stock expiry
  2. Prepare a private creation session, valid for two hours
  3. Sign in to your firm’s Exness Personal Area and have your operator run the returned script in that tab’s developer console
  4. The script creates MT5 Standard demo accounts with the configured balance and currency, then saves their encrypted credentials into the selected pools

Each slot is reserved before a broker request
An uncertain response stops creation; find that account in Exness and import it manually before making another
Revoking a session stops new claims and imports but does not delete broker accounts

The adapter follows the observed Exness browser workflow and needs a signed-in rehearsal against the current interface before launch
It is not an official broker manager API
Exness limits, sign-in and verification still apply

Funded continuation after payout

The firm owner opens a funded challenge and selects Record payout & continue
Record the completed payment’s reference, amount, currency and verification note
This records a staff attestation; it neither transfers money nor verifies an external payment provider

Continuation queues one fresh funded account at the purchased balance and rules
Duplicate payout references and duplicate successors are refused
A later payout can start the next cycle; automatic balance scaling is not included

Every handover requires fresh broker data, no open positions or pending orders, no unresolved executions and paused copy links
The new account must report the exact starting balance, currency and demo environment
Missing stock waits without changing the current account

Retired accounts remain in the challenge history and cannot accept new MIRRO trading work
Retirement does not revoke an Exness broker login
The handover requests shutdown of the old hosted terminal
The operator must still manage broker-side access and verify runtime shutdown

Before opening checkout, confirm the firm’s merchant account, hosting coverage and selected account-delivery route together in the launch checklist

The stock-based purchase flow

  1. Create a challenge program with its fee, fee currency, trading account currency, starting balance and rules
  2. Import firm-owned MT4 or MT5 demo accounts with matching balances and currencies
    Passwords are encrypted and excluded from inventory listings
  3. The trader signs in, reviews every program rule and accepts your terms
    If the fee, rules or policies change while the review is open, checkout asks them to review the latest version
  4. The server reserves one stock account and freezes the price, rules and accepted policies on the order
  5. Payment opens on your own payment provider
    The server checks the payment directly with the provider
  6. The existing terminal provisioner connects the reserved account to that trader
  7. Challenge activation waits for a fresh empty account with the expected balance and currency
  8. The trader sees the challenge and can reveal their account details from My orders

Challenge fees and trading balances

Set the fee currency separately from the trading account currency
For example, a firm can charge NGN for a challenge that runs on a USD demo account
The merchant must accept the fee currency, and the stock account must match the trading balance and currency
No exchange rate is applied automatically

Your company collects its own payments

Customers choose an enabled gateway and pay your firm’s own merchant account
MIRRO connects checkout, checks the payment and delivers the account through your selected broker or stock workflow
MIRRO does not receive or hold your challenge fees

  1. Sign in as the firm owner and open Developer tools → Your payments go to you
  2. Choose Paystack, Squad, TransactPay or KoraPay, select Test mode and add your company’s keys and approved currency
  3. Save the keys — Paystack, Squad and KoraPay use a read-only access check
    TransactPay keys are saved securely and checked through a test purchase
  4. Copy the generated Webhook URL into that provider’s webhook settings in the same mode and save
    The callback address is already attached to each checkout and is also available to copy
  5. With sandbox hosting and the selected account-delivery route ready, enable Show at checkout and complete a test purchase through to a ready trading account
  6. Connect your live keys, copy the newly shown webhook address into Live mode, then enable Show at checkout once the listed hosting and rehearsal checks pass

The secret key is encrypted and never returned to the browser after saving
TransactPay requires its public, secret and encryption keys from the same merchant and mode
The other gateways require a secret key
A successful key check proves API access, not settlement currency approval, bank settlement or a complete launch

Checked gateways appear automatically for compatible challenge currencies
Live options hide test options so customers cannot confuse them
If no gateway supports a challenge fee, its checkout stays closed

New keys pause new checkout links until you reopen them
Existing orders retain their original key — settle or resolve those orders before revoking it at the provider
Pausing checkout never stops verification of payments already started
Duplicate signed notifications cannot assign a second account

The website return address comes from the deployment’s approved console host, not an editable branding field
Use MIRRO_FIRM_MERCHANTS only for existing deployment-managed integrations or approved custom return hosts — it is not required for an owner to save keys
An explicit self-service setup never falls back to MIRRO’s merchant

Payment verification follows Paystack’s webhook guidance and its read-only integration check
Squad, TransactPay and KoraPay have their own checkout adapters
Payouts and identity-provider connections remain separate integrations

Before live activation, test a purchase and account delivery with the firm's demo stock, verify the merchant's approved currencies, configure DNS and the email sender, and confirm how account hosting is paid
No live credentials are included in the example

Company-paid hosting
MIRRO operators record reviewed invoice or contract coverage in the firm’s Hosting allowance panel
Set the agreed number of challenge places, an exact UTC expiry and an evidence reference
This records human review — it does not collect money or verify a provider receipt

Each purchase reserves a hosting place together with its stock account before the payment page opens
Simultaneous purchases cannot exceed the allowance
The place follows Phase 1, Phase 2 and funded continuations, including one pending handover
It cannot cover the trader’s unrelated accounts

Cancelled unpaid orders release their place
Closed or failed challenges can release a place only after all issued accounts are retired, runtime shutdown is complete and no unresolved exposure remains
Use Your product → Hosting allowance → Free places from finished challenges

Expired or suspended company coverage refuses new exposure and purchases
It never starts charging a trader’s personal balance
Exits stay available, and existing hosting grace and safe-shutdown checks remain in place
Live and sandbox allowances are separate — a test purchase uses its own recorded sandbox place, including on a live gateway

Live launch requirement
Keep live checkout disabled until the firm-owned merchant, recorded company coverage, broker stock and a newly registered trader’s full account delivery have been verified together
The local tests do not certify a live launch

Connect your website or trader workspace

For website packages, open Website studio → Go live & domain
For Branded Workspace, open Company settings → Your trader workspace address
Add your hostname, publish the displayed ownership and CNAME records at your DNS provider, then follow the DNS and HTTPS checks
MIRRO monitors the saved domain automatically; saving an address alone does not make it live

A verified website domain opens your storefront
A verified workspace-only domain opens trader sign-in, then the customer dashboard or staff back office
Domain approval must include a website or trader dashboard; a stale or unverified domain does not route to another firm

Your system, one clear integration path

Keep your website, customer database, checkout and dashboard
Your backend talks to MIRRO with one private staff API key
MIRRO keeps account delivery and challenge rules inside your firm’s approved scope

Choose the workflow you actually use

Both paths require an active trader membership and a saved program
Current enrollment uses an invitation the trader accepts — your customer ID or email cannot substitute for that membership
Store the MIRRO member ID alongside your own customer record
Confirm enrollment, account delivery settings and hosting capacity before enabling a new purchase in your checkout

A tested client, ready to use

npm install https://mirroapi.com/downloads/mirroapi-client-0.7.1.tgz

The server-side JavaScript and TypeScript client includes request recovery, bounded waiting and webhook signature verification
Use the account delivery starter with your own payment and database functions
Python and other languages can use the same documented HTTP endpoints

Your checkout, MIRRO account delivery

Account Automation and Branded Workspace keep payments in your application
Your server verifies the payment and only then asks MIRRO to deliver an account
Engine API alone evaluates an existing connected account; it does not include automatic account creation

  1. Create a live owner or operations API key with trade scope and no account restriction
    Keep it on your server and send your firm slug in X-Mirro-Tenant
  2. Before collecting a challenge payment, enroll the buyer through POST /v1/firm/members/invite using role trader
    The buyer registers and accepts the invitation
    Read their active membership and userId from GET /v1/firm/members — an email address or your application’s customer ID is not a MIRRO member ID
  3. Save the challenge program, select a verified automatic broker and confirm company hosting capacity
    The broker must support the program’s balance, currency and every required phase
  4. After your payment verification, submit the member ID, program ID and a unique purchase reference
POST /v1/firm/account-requests
Authorization: Bearer YOUR_SERVER_API_KEY
X-Mirro-Tenant: YOUR_FIRM_SLUG
Idempotency-Key: order-1001
Content-Type: application/json

{"programId":"PROGRAM_UUID","userId":"MEMBER_UUID","reference":"order-1001"}

Save the returned request ID
Read GET /v1/firm/account-requests/{id} with a delay between requests until state is ready
Only then display the returned account and challenge IDs
If the request needs review, stop automatic retries and show the reason to your operations team
Retry an interrupted request with the same body, reference and idempotency key — do not create another purchase reference

Read current account credentials through POST /v1/firm/account-requests/{id}/credentials on your backend, only for the authenticated buyer who owns that request
Never put your staff key or account passwords in public HTML, analytics or logs

When a request is interrupted

429 and temporary network/5xx failures use bounded backoff and the same saved identity
401/403 need key or role correction; 400 needs input correction; 409 needs the reported configuration or conflict resolved
Save the response’s X-Request-Id for support
Polling and retries count toward request limits and any usage terms in your firm’s agreement — slow polling when a delivery takes longer

Keep your application in sync

Subscribe a staff webhook receiver to challenge.phase_passed, challenge.funded, challenge.failed and challenge.warning
Use verifyWebhook(rawBody, signature, secret) from the client to verify the original bytes
Persist and enqueue the event atomically before returning 2xx; deduplicate by event ID across restarts
Never assume arrival order — read the challenge’s current state before updating your dashboard
Active staff receive events for their firm’s challenges, while ordinary position and order activity remains account-owner scoped
A phase event is not a promise that a new account is connected — read the challenge and delivery state before displaying credentials

Initial account readiness is read from the request endpoint; there is no separate account-request-ready event
A webhook retry does not authorize a second account creation

GET /v1/firm/launch is available to an unrestricted staff session or trade/admin API key
It checks eligible live keys, unrestricted receivers for all four challenge events, recent successful delivery and account coverage
These records guide a rehearsal; they do not certify a new provider or customer launch

Developer API

Send x-mirro-tenant: your-firm-slug with the firm's staff credentials
Account-restricted keys cannot manage the business workspace

GET /v1/firm/business
Read storefront configuration, stock, recent orders, support tickets, events and integration readiness
PUT /v1/firm/site
Save or publish website content as the firm owner
POST /v1/firm/stock
Import an account as an owner or operations member
Required fields: programId, platform, login, password, server, currency, startingBalance, expiresAt, environment: demo and ownedByFirm: true
POST /v1/firm/orders/{orderId}/retry
Retry a paid order needing staff review after correcting its stock or hosting issue
A payment received after cancellation requires refund review and cannot be retried into stock already reused
GET /v1/firm/support
Staff read their firm's support queue
Traders can only read their own requests and never see internal notes

Failure handling

Run your daily operations

The business overview highlights orders needing review, challenge programs short of stock and open support conversations
Stock coverage checks the current program balance, currency and expiry across the whole inventory

Orders & delivery searches the full order history with status filters and pagination
Open an order for its payment and delivery timeline, saved price and purchase rules
Traders can open a support request linked to their own order

Developer tools shows each preparation step, its owner and the next action
Configured services are not proof of a live launch — hosting coverage must be recorded and tested with a newly registered trader

For integrations, use GET /v1/firm/orders and GET /v1/firm/orders/{orderId} for staff, or the customer-owned GET /v1/me/firm-orders/page and GET /v1/me/firm-orders/{orderId}
Pass the returned nextCursor as after without changing filters

Understand what your package enables

Package & features is the source of truth for your firm’s approved scope
Website publishing, challenge evaluation, account pools, supported automatic demo creation and phase handovers are separate features with their own setup requirements

Automated KYC, payout transfers, provider refunds, affiliate settlement, competitions, account scaling and broker-manager provisioning require separate implementation
Staff-recorded identity, agreement or payout checks are attestations; they do not verify a provider or transfer money
The phase-delivery workflow described above is available when enabled; it is distinct from general account recovery or balance scaling

Each firm remains responsible for its company registration, programme terms, customer support decisions, payment-provider approval and reward funding
MIRRO supplies technology, not legal incorporation or payout capital

Full Firm API reference → · Open your launch checklist →