paybondpaybond
Sign in

Onboarding

Roll out Paybond Kit with the right security model, integration sequence, and production checklist.

This guide is for teams that are taking Paybond from evaluation into an application or agent workflow. It assumes you already have a Paybond Gateway URL, a Harbor URL, and a service-account API key for a single tenant.

The Kit is designed for product teams, not platform operators. It covers the application-facing lifecycle: sessions, intents, capability verification, evidence submission, selected protocol helpers, and read-only Signal access.

Before you write code

  • Confirm which tenant, environment, and settlement rail you are targeting.
  • Decide where service-account API keys will live and how they will be rotated.
  • Decide which application or tool operations should map to allowedTools or allowed_tools.
  • Decide what evidence payloads and artifacts you need to preserve for later review.

Shared responsibilities

Your team owns:

  • Business configuration, tenant-specific credentials, and application-side signing material.
  • The mapping between your business actions and Paybond operations.
  • The evidence payloads your workflow will submit.

Paybond owns:

  • Hosted Harbor, Gateway, and Signal services.
  • Platform signing keys, shared infrastructure credentials, and hosted operational workflows.
  • Enforcement of tenant binding, capability verification, and settlement rules.

Security model

  1. Tenant scope comes from authenticated credentials, not from caller-supplied tenant identifiers.
  2. Sessions are single-tenant. Create one client per tenant and service account.
  3. Capability tokens are intent-scoped. Never reuse a token across intents.
  4. Cache access tokens in memory only, and rotate them through the supported session APIs.
  1. Start with One-command guardrails using a Free Developer sandbox key.
  2. Open a Kit session and confirm the tenant returned by the Gateway matches the environment you expect.
  3. Run one sandbox guardrail around a representative paid tool and submit simulator evidence.
  4. Move to the TypeScript quickstart or Python quickstart when the workflow needs production intent creation, funding, and settlement.
  5. Add idempotency keys, structured logging, and credential rotation before moving to production.
  6. If you use an agent framework, layer in the Agent runtime tutorial, agent integrations, or the MCP server.

Signal reads

If your application needs standing or portfolio data, use the tenant-bound Signal helpers after the Harbor flow is working. That keeps the first rollout focused and makes it easier to separate settlement behavior from reporting behavior.

Production checklist

  • Store service-account API keys and signing material in a secret manager.
  • Use the same idempotency key when retrying the same write request.
  • Log request IDs, status codes, tenant context, and intent IDs without logging secrets.
  • Close SDK sessions cleanly so HTTP resources are released.
  • Keep settlement confirmation in an operator-reviewed workflow unless you are calling the Harbor API directly by design.

Where to go next