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.
In short, the API needs to answer three questions on every call: who set the spend limit, what ran, and how much was paid. This is the API-shaped version of that 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 | Paybond POST /verify | A signed permission slip (capability token), scoped to one operation — confirms the agent can perform the requested action 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 | POST /intents/{id}/settlement/confirm or the Operator Console | Turns reviewed evidence into a release, refund, or exception path |
| Proof and receipt export | Ledger verifier pack and Signal signed exports | Gives finance, partners, and auditors a portable record |
| Retry behavior | idempotency-key on supported 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.
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 intent-lifecycle API calls are useful when a team already owns signing, review, or finance workflow controls. In that case, use the Harbor API reference for request shapes (the evidence-evaluation service behind Kit) 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
Start with Paybond Kit — TypeScript and Python middleware for authorize-before and receipt-after. Evidence evaluation, funding, settlement confirmation, dispute review, and proof export run behind Kit. Ledger preserves signed provenance. Signal optionally turns completed history into standing artifacts.
That lets an agent app focus on the workflow while Paybond keeps the agreement, release/refund 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. Ledger verifier packs support provenance checks; Signal exposes signed exports for standing and portfolio review.