Operating pillars
4
Capability layers rendered with explicit operational behavior.
Platform Capability
Cards Capability For Issuing At Scale
Build card experiences with controllable risk posture, policy enforcement, and card-level evidence that stays visible in production.
- 01Issuing contracts
- 02Authorization context
- 03Policy-aware controls
Replay-safe Events
PosterReplay-safe
Retries and reconciliation rendered as one deterministic flow.
Visual center
Event runtime
Replay-safe event handling with delivery, retry, and operator visibility.
Runtime model
Deterministic
Replay-safe money and identity workflows under retry pressure.
Control boundary
Tenant-scoped
Isolation across authorization, data access, and operator actions.
Operating model
A card program keeps issuance, spend policy, authorization, and clearing in one inspected path.
Entrypoint
POST /cards
01Issue
Create card artifact
The card is linked to customer, tenant, spend controls, and account context.
02Control
Apply card policy
Limits, merchant categories, channels, and freeze state are resolved before approval.
03Authorize
Handle auth request
Authorization events expose approved, declined, and review states.
04Clear
Match clearing files
Clearing records connect back to authorization and ledger entries.
05Review
Preserve dispute trail
Operations retain the card, actor, merchant, and evidence packet.
Events emitted
card.issued
card.authorization.requested
card.authorization.approved
card.clearing.posted
Evidence retained
card_id
authorization_id
policy_decision
merchant_context
ledger_entry
Failure path proof
Card programs expose policy decisions.
Issuance, spend limits, authorization, clearing, freeze state, and disputes stay visible as operational state.
01
Declined authorization
Incident
A cardholder hits a merchant or limit rule during a live authorization request.
Zentra path
The card policy decision is recorded before approval or decline is returned.
Evidence
Card ID, merchant context, policy result, authorization ID, and spend rule are retained.
02
Clearing mismatch
Incident
A clearing file does not align with the original authorization amount.
Zentra path
The clearing record is matched against authorization and ledger state for review.
Evidence
Authorization, clearing record, ledger entry, delta, and review owner stay attached.
Lifecycle proof
From API request to operational evidence.
This page makes the runtime visible: POST /cards, the state path, emitted events, and evidence a team can inspect when the happy path breaks.
API request
liveawait zentra.runtime.intents.create({
intent_id: "intent_042",
scope: "workspace_scope",
money_model: "minor_units + ledger_currency",
primitives: ["policy", "ledger", "events"]
})
intent accepted
workspace scope resolved
runtime trace attached
Runtime state machine
01Accept intentruntime contractaccepted
02Resolve controlsscope + policycontrolled
03Post ledger stateminor-unit entriesledgered
04Select routecorridor contextrouted
05Sync eventssigned streamsynchronized
06Seal evidenceactor + scope + timeevidenced
Ledger entries
debitcustomer_balance-125000 mu
creditreserved_balance+125000 mu
debitreserved_balance-125000 mu
creditsettlement_account+125000 mu
Audit evidence
actorsvc_runtime
scopeworkspace_scope
policylimit_check.passed
signatureverified
Capability model
Operational building blocks, not vague feature claims.
Each pillar below maps product capability to runtime behavior teams can reason about before launch.
01
Issuance APIs
Provision and manage card artifacts through stable contracts.
02
Card controls
Apply configurable limits, channels, and merchant constraints.
03
Authorization surfaces
Capture authorization events for risk and experience workflows.
04
Admin operations
Review card state and transaction history through dedicated tooling.
Visual center
Event runtime
Replay-safe event handling with delivery, retry, and operator visibility.
- Keep issuance apis deterministic under retries, delays, and asynchronous callbacks.
- Expose state transitions and error semantics clearly enough for operators and integrators to act.
- Capture audit events with tenant and actor attribution for regulated review workflows.
API to product
The integration should create visible state.
A buyer should see the first call, the system response, the webhook behavior, and the ledger/audit consequence without leaving the product page.
issue card
await zentra.cards.issue({
customer: "customer_ref",
account: "operating_account",
spend_limit_minor: 250000,
idempotency_key: "card_live_042"
})System response
status
issued
event
card.issued
evidence
card_id
entrypoint
POST /cards
The first integration proof should show POST /cards, emitted events, retained evidence, and visible product state.
Webhook replay
01timeoutevent card.issuedretained
02signature verifiedevent card.issuedretrying
03deliveredevent card.issuedresolved
Result: one ledger-safe state transition
Delivery state remains visible without creating duplicate financial state.
Ledger flow
account
Customer
-125000 mu
account
Reserved
+125000 mu
account
Settlement
+125000 mu
account
Merchant
+125000 mu
account
Payout
closed
Operational proof
Evidence that the capability behaves correctly when production gets noisy.
The proof points below are written to be checked by operators, solution engineers, and compliance teams, not just admired in a brand presentation.
Authorization, clearing, reversal, and dispute records stay tied to the card and tenant policy that allowed them.
Spend controls fail closed with visible policy decisions instead of provider-only decline reasons.
Operations can review merchant context, program limits, and ledger impact from one evidence trail.
Trust layer
Audit evidence travels with the capability.
Every primitive page needs proof that state, actor, tenant, signature, and policy context remain reviewable after the happy path breaks.
Trust evidence
The proof stays attached to the runtime state.
actorsvc_runtime
scopeworkspace_scope
timestamp2026-04-26T14:12:09Z
policylimit_check.passed
intentintent_042
signatureverified
ledgerentry_042
statusaudit_ready