Skip to content

Changelog

2026-10-18: financial confirmation and market controls

Section titled “2026-10-18: financial confirmation and market controls”

Wallet compatibility change: debit, credit and rollback success responses now require the exact request txId, an explicit integer balance and matching currency. Previously the ID could be omitted. Update and certify the wallet before adopting this server revision. Empty/malformed 4xx responses remain unknown.

  • Exposure limits now reserve capacity before debit and acceptance, including unpaid obligations and unrecovered corrections. Added scopes: competition, brand, explicit event group and company by currency/environment. Company limits require two platform administrators; new ceilings start disabled.
  • In production, player sessions now require operator integration and a seamless wallet. Local account, KYC and cashier endpoints return 403 operator_managed; older local-login tokens are refused. Staff login and account, jurisdiction, session and financial controls remain. Integrated seamless-wallet players no longer require a location lookup or location heartbeat in staging or production. The B2B module starts without a locator and never fabricates a country verdict; this change does not certify production readiness.
  • Unconfirmed credits superseded by result corrections stop for review; transport reconciliation cannot bypass posting order.
  • Placement revalidates after wallet latency; cash-out revalues at commit. Catalogue, outright, special and supplementary product sources fence local price/state changes in the single-instance deployment, including a deadline for lock acquisition.
  • Staff-made special markets close and persist a replayable result in one transaction before settlement. A crash or failed hand-off is recovered automatically from that result; no new bet can cross the closure.
  • Catalogue changes and their results are committed together before publication. Final bets and cash-outs read committed catalogue state and current operator pricing/product settings; an older cache cannot bypass a confirmed market hold. Undelivered results survive prolonged outages. Deployment remains restricted to one API instance while other sources and exposure controls are migrated.
  • Feed input is persisted before its checkpoint advances. Statistics, verification, derived results and catalogue acknowledgement survive failures and restarts. Replayed messages retain their age; stale input queues degrade API health and refuse financial decisions on outdated prices.
  • Virtual sports, number draws and racing persist product state and settlement output together. Final quotes read the current database revision and reject expired supplier data. Overlapping polls cannot overwrite newer state; draw settlement includes picks committed before closure. Published RNG commitments remain fixed, and incomplete virtual results are retried. Shared exposure/compliance controls and external certification still prevent a multi-API or real-money readiness claim.
  • Long-term markets persist prices, trading controls and pending results together. Final bets and cash-outs reject a price when its match inputs change or its refresh expires. Independent updates preserve existing operator holds, and automatic results remain recoverable until durable hand-off. The single-API restriction remains.
  • Unfunded correction debits are refused for operator review, without overdraft, partial collection or capture of future deposits. Stored refusals remain final.
  • Financial postings retain immutable identities and execute in order per bet; unresolved predecessors block later corrections.
  • Market controls distinguish the operator’s hold from feed/platform restrictions and persist before confirmation.
  • The back-office shows unresolved financial obligations separately from bet results and callback history.
  • Monthly invoice deductions, pass-through charges and approval hashes are independent of the database session time zone; betting movements retain UTC period boundaries.
  • Production startup rejects simulated feeds/history, the default mock vendor identity and enabled mock identity/payment providers. Staging fixtures remain available; provider and wallet certification is still required.
  • Added OpenAPI, certification and the operator guide.

2026-10-17: sessions use the platform player ID

Section titled “2026-10-17: sessions use the platform player ID”
  • Removed the CPF requirement from integrated sessions, including BR; identity uses tenant + externalPlayerId.
  • The legacy cpf field is accepted and ignored. It is neither validated nor stored by new session requests; the Node example no longer sends it.
  • Betting authorization for integrated players does not require CPF or query CPF lists. Local restrictions and remaining betting controls still apply.
  • Registration, CPF, KYC and cashier remain on the client platform. Existing player IDs and histories are preserved.
  • OrbiSportbook provides the sportsbook via iframe; registration, CPF validation, KYC, cashier, deposits and withdrawals belong to the client platform.
  • Removed the full-platform offer and Brazil legal-status notice. Branding applies to the sportsbook.
  • Documented delegated KYC status and the BR session CPF dependency that existed at that point. No API, wallet or tenant behavior changed.

The integration follows the versioning policy: compatible additions within a version, a new SDK URL for breaking changes.

First public version of the iframe integration.

API

  • POST /api/v1/integration/sessions also returns launchToken (single use, 120 seconds), launchExpiresAt and launchUrl, and accepts path and locale for the launch URL.
  • New POST /api/v1/integration/launch: exchanges a launch token once for the session token. Refusals carry details.reason: launch_token_invalid, launch_token_used, launch_token_expired.
  • GET /api/v1/config exposes tenant.embedOrigins.
  • Sportsbook pages carry Content-Security-Policy: frame-ancestors from the tenant’s embedOrigins.

Embed SDK

  • /embed/v1.js (global OrbiSportbook) and @bookmaker/embed-sdk (ES module with types): mount() with launch tokens, auto and fill sizing, deep links, locale, every event as a callback and every command as a method; origin checks on every message.

postMessage protocol v1

  • Events: ready, resize, route, login_required, session_expired, balance_changed, bet_placed, bet_settled, deposit_requested, error.
  • Commands: set_launch_token, navigate, set_locale, refresh_balance, logout.

Deprecated

  • Launching with the session token in the URL (?token=). It keeps working; move to ?launch= or the SDK.

Durable bet attempts and liability reservations

Section titled “Durable bet attempts and liability reservations”

Bet attempts now reserve configured outcome liability in PostgreSQL before the wallet debit. Retries retain the same operation; expired attempts cannot be accepted by a late reply. Refunds remain pending until confirmed, including after restart. SP and fixed-price twins share liability, and SP/BOG use the payout cap for their reserve. This does not certify aggregate risk controls or production wallet contracts.