paybondpaybond
Sign in

Product surfaces overview

A map of Paybond’s public, documentation, demo, and tenant-scoped console surfaces—plus how they fit together without crossing tenant boundaries.

Paybond is intentionally delivered as multiple product surfaces. Each surface has a different audience, trust boundary, and level of tenancy.

If you only read one screen, use the chooser and the map below to decide where to go next.

Where should I start?

I’m evaluating the product

Start with use cases and pricing, then validate the lifecycle hands-on.

I’m implementing

Go straight to docs and API references, then authenticate to reach your tenant console.

I’m operating a tenant

Use the console for day-to-day operational workflows once you’re authenticated.

I’m reviewing security / trust boundaries

Skim the trust-boundary rules below, then drill into docs for deeper implementation detail.

Surface map (at a glance)

Fast mental model

Public pages are for learning and evaluation. Auth pages establish a session. Tenant pages assume tenant context derived server-side and must never be reachable based on unauthenticated client identifiers alone.

Surface → purpose → tenancy

SurfaceExample routesPurposeTenancy / trust boundary
Public marketing/, /pricing, /use-cases/*Narrative, discovery, entry pointsPublic (no tenant)
Documentation/docs/*Implementation guidance and API referencePublic (no tenant)
Interactive demo/demoValidate the lifecycle hands-on without provisioningPublic (no tenant)
Session-establishing/signup/*, /loginCreate or resume an authenticated sessionPublic but security-sensitive
Operator console/console/*Operate disputes, audits, settlements, policiesTenant-scoped (server-derived tenant context)

How they connect

PublicDemo Docs Signup / Login Console (tenant-scoped)

Trust boundaries

Tenant isolation rules (practical)

These constraints keep public surfaces useful without becoming an authority source for tenant context.

Tenant isolation note

Public surfaces never accept tenant identifiers from the browser as authority. Tenant-scoped surfaces derive tenant context from authenticated credentials and server-side session state.

  • Public surfaces can render content and links, but must treat client-provided identifiers as untrusted input.
  • Session-establishing surfaces handle sensitive auth and billing flows; they may redirect into tenant-scoped areas only after the server establishes session state.
  • Tenant-scoped surfaces must never derive tenant context solely from URL params or client storage; they should rely on server-side session/auth context.

Surface details

Public marketing

High-level narrative, use cases, and entry points—no tenant required.

  • /: landing page with product story and anchor sections (e.g. Product surfaces).
  • /pricing: plans and signup entry points.
  • /use-cases/*: deeper narratives per problem shape (e.g. multi-agent workflows, compliance export bundles).

Interactive demo

Hands-on walkthrough of a signed intent lifecycle—no tenant required.

  • /demo: scenario-driven walkthrough demonstrating commitment → clearing, including capability checks and deterministic predicate evaluation.
Open the interactive walkthrough →

Documentation

Developer documentation rendered from the repository docs—no tenant required.

  • /docs/*: markdown-based docs for Kit, platform concepts, and API docs.
Browse docs →

Authentication entry points

Public pages that create or resume an authenticated session.

  • /signup/*: public signup funnel (including billing flows when enabled).
  • /login: public login surface.

Tenant-scoped operator console

Operational UI for a specific tenant—requires authentication and tenant context.

  • /console/*: the operator console. This surface is tenant-bound and should only be reachable after authentication.

Why it is tenant-scoped

The console can show disputes, audits, settlements, policies, and other operational artifacts. Those artifacts must never be queryable cross-tenant, so the console requires server-derived tenant context.

How the surfaces connect

A recommended journey

A simple path from initial understanding to hands-on validation to onboarding.

  1. Start with Public marketing to understand what Paybond solves.
  2. Use the Interactive demo to validate the lifecycle and artifacts without provisioning a tenant.
  3. Go to Docs for implementation details and API references.
  4. Use Signup/Login to establish an authenticated session.
  5. Operate inside the Console once tenant context is established.

What is public vs. tenant-bound (quick checklist)

  • Public /, /pricing, /use-cases/*, /docs/*, /demo
  • Session-establishing /signup/*, /login
  • Tenant-scoped /console/*