paybondpaybond
Sign in

Product surfaces overview

A map of Paybond’s public site, documentation, demo, and tenant-scoped console surfaces, and how they fit together.

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

Start with the trust-boundary rules below, then continue into the product and API docs.

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/*Product documentation, SDK guides, 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

Product documentation, SDK guides, and API references—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 product concepts, SDK guides, 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/*