An agentic banking infrastructure API should not be a thin wrapper around a payment call. If agents can trigger commercial work, the API has to carry the agreement boundary, budget, allowed operations, evidence, and settlement decision in a way that can be reviewed later.
This is the API-shaped version of the infrastructure problem.
Core API primitives
| Primitive | Public surface | Why it matters |
|---|---|---|
| Tenant-scoped session | Kit Paybond.open, Gateway GET /v1/auth/principal | Derives workspace scope from credentials instead of request fields |
| Signed intent | Kit paybond.intents.create, Gateway POST /harbor/intents | Binds parties, budget, allowed operations, evidence requirements, deadline, and requested rail |
| Capability check | Harbor POST /verify | Confirms the agent can perform the requested operation before tool work begins |
| Rail-aware funding | Kit paybond.intents.fund, Gateway POST /harbor/intents/{id}/fund for delayed rails such as x402/USDC and Stripe ACH Direct Debit; Stripe Connect funding follows the approved tenant rail | Separates funding authorization from the later settlement outcome |
| Evidence submission | Kit paybond.intents.submitEvidence, Gateway POST /harbor/intents/{id}/evidence | Attaches signed workflow results for deterministic evaluation |
| Settlement confirmation | Harbor POST /intents/{id}/settlement/confirm or the Operator Console | Turns reviewed evidence into a release, refund, or exception path |
| Proof and receipt export | Harbor ledger verifier pack and Signal signed exports | Gives finance, partners, and auditors a portable record |
| Retry behavior | idempotency-key on supported Harbor write routes | Lets callers retry safely without creating duplicate lifecycle transitions |
Example lifecycle
1. Open session
2. Create intent
3. Authorize funding
4. Verify capability
5. Submit evidence
6. Confirm outcome
What the API should not trust
A secure agentic banking infrastructure API should avoid trusting:
- unauthenticated tenant IDs or workspace IDs from the client
- free-form settlement destinations submitted at funding time
- agent-authored release decisions with no deterministic rule
- webhook status as the only proof of completion
- evidence that cannot be tied back to the signed intent
Instead, tenant scope should come from credentials, settlement configuration should be resolved server-side, and every state transition should be replayable from signed records.
API design rule
The API should let callers request an allowed action, not invent the security context. Tenant, rail, budget, and settlement authority belong behind authenticated server boundaries.
Sandbox ACH testing
When a tenant admin switches the console to the sandbox tenant, stripe_ach_debit uses Paybond simulator routing and sandbox lifecycle events. That lets teams test ACH funding states without a Stripe test-mode secret or Connect account. Real Stripe ACH test-mode calls are an optional Paybond engineering verification path, separate from tenant sandbox onboarding.
Direct API vs SDK
Most application teams should start with Paybond Kit. The SDK opens a tenant-bound session, signs supported intent and evidence payloads, verifies capabilities, and wraps the x402/USDC funding handshake.
Direct Harbor calls are useful when a team needs to integrate from a service that already owns signing, review, or finance workflow controls. In that case, use the Harbor API reference for request shapes and keep the same boundary: tenant scope from credentials, approved settlement rails from tenant configuration, and idempotency keys on supported write routes.
Where Paybond fits
Paybond Kit gives TypeScript and Python applications a runtime client for this lifecycle. Harbor is the API surface for intents, funding, evidence, settlement confirmation, dispute review, and proof export. Ledger preserves signed provenance. Signal turns completed settlement history into receipts and standing.
That lets an agent app focus on the workflow while Paybond keeps the agreement, money movement decision, and review record tied together.
Common questions
Is this the same as a payment API?
No. A payment API moves money. An agentic banking infrastructure API also needs the signed agreement, budget, allowed operations, evidence, review path, and receipt trail that explain why money should release or return.
Which endpoint confirms settlement?
Evidence submission evaluates the rule, but it does not have to be the final money movement step. Settlement is confirmed through POST /intents/{id}/settlement/confirm or through the Operator Console when review is needed.
Where do receipts come from?
Receipts and proof exports come from the signed lifecycle record. Harbor exposes ledger verifier packs for provenance checks, and Signal exposes signed exports for standing and portfolio review.