XKOVA Docs
Docs / Start Here / Try the Demos

Try the Demos

The shared Plover Credit Union tenant shows the same rails from the management and member views. The management Console has a fixed demo-staff entry. The Plover member app offers branded email sign-in and a one-click Quick Demo. Nothing runs on your machine, and nothing you do in the demo affects your own workspace.

The two surfaces

SurfaceWhat it is
Plover management ConsoleThe workspace Console signed in to the Plover Credit Union demo tenant, where staff manage payments, treasury, compliance, and tokens.
Plover member appThe Consumer Xperience reference front end. Plover-branded email sign-in and Quick Demo both complete through its confidential BFF into the same scoped XKOVA member session.

Enter the demo

The demo is entered from the console: on the signup intent screen, choose Try the demo. That takes you to the shared demo chooser (no signup of your own required, and it does not set up or alter your own workspace). The management choice opens a fixed demo-staff session. The member choice opens Plover. Choose Sign in with email to enter the Plover-branded Hosted Auth ceremony, or choose Quick Demo to lease an available seeded persona for 30 minutes. Quick Demo selects the persona on XKOVA's server and never asks the browser for an account-holder, wallet, chain, or funding amount. Its opaque application session expires with the 30-minute lease, and a server-side admission gate protects the small public persona pool. Both paths finish through the same one-time authorization result and Plover BFF session exchange.

A first-time email member receives a distinct Plover account holder, the demo savings and checking accounts, wallet readiness, and one idempotent sandbox funding request for a fixed amount of dUSDC. The account holder and subsequent payments remain in the existing Plover tenant and workspace, so the same activity is visible from the management Console.

Hosted sign-in, the XKOVA member session, and wallet provisioning keep identity, session, and wallet-provider credentials server-side. Plover sends a bodyless member-self request through its BFF, XKOVA selects the exact session-bound account holder, and Plover receives only provider-neutral wallet readiness. Actual payment signing happens later in a separate purpose-bound signing ceremony.

FI/BYO OIDC remains a supported enterprise member-authentication integration, but it is not a Plover customer-facing option. See Authentication for enterprise OIDC guidance.

The shared demo tenant resets on a regular schedule, so it is always safe to explore: send payments, work compliance cases, drive treasury flows. Anything you change is wiped on the next reset, so do not keep anything you care about there.

What to try

  • As a management user: watch a payment move through queued, pending, and success on the Payments list; triage the compliance queue; open Treasury and walk a transfer's draft, sign, execute journey. See the onboarding guide for what each area does.
  • As a member: sign in with email or enter Quick Demo, check balances, and send money. The signing ceremony uses the same short-lived, memory-only Thirdweb MPC session and exact signature acceptance boundary your own members use. See the Non-custodial Model.
  • Both at once: send from the member app, then find the same payment in the management Console. The shared tenant connects the two views without making identity a activity under the Plover tenant.

Next

When you are ready to build against your own workspace, follow the Quickstart, and see Local Development for pointing your local app at the hosted sandbox.