DEVELOPERS

Integrate once with a provider-neutral financial layer.

Nexus uses explicit transaction lifecycles, provider adapters, signed server-to-server events and idempotent ledger posting. Partner API access and detailed documentation are shared during approved integrations.

INTEGRATION MODEL

Intent first. Provider second. Ledger last.

  1. Create intentThe connected operator is identified and the financial request receives a Nexus reference.
  2. Call providerAn adapter translates the Nexus intent into the approved provider request.
  3. Verify eventSigned response or webhook evidence updates the provider lifecycle.
  4. Post ledgerExactly-once financial posting happens only after the required confirmation state.
FundingPayoutWebhook
POST /partner/v1/funding-intents

{
  "player_ref": "P-829182",
  "amount": "100.00",
  "currency": "EUR",
  "return_url": "https://partner.example/return"
}

// Operator identity is derived from
// authenticated partner credentials.
Illustrative partner API preview. Final production endpoints and scopes are issued during integration.

Idempotency

External references and event identifiers are controlled so retries do not create duplicate financial postings.

Webhooks

Provider-specific verification remains inside adapters while normalized events reach the central transaction lifecycle.

Sandbox-first

New providers and connected operators should pass simulator and sandbox regression tests before production funds are enabled.

CURRENT FOUNDATION

Existing Nexus modules already cover core orchestration.

The current platform foundation includes provider registry, payment intents, request/response/webhook logs, reconciliation, settlement controls, VLT cash-in flows and a network-aware crypto provider layer.

PARTNER ACCESS

Need technical documentation?

Architecture notes, endpoint specifications and sandbox credentials can be provided to approved provider and integration partners.

Request integration access