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.

Docs

01Issuing contracts
02Authorization context
03Policy-aware controls

Fig 01operating 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.issuedcard.authorization.requestedcard.authorization.approvedcard.clearing.posted

Evidence retained

card_idauthorization_idpolicy_decisionmerchant_contextledger_entry

Fig 02failure paths

Card programs expose policy decisions.

Issuance, spend limits, authorization, clearing, freeze state, and disputes stay visible as operational state.

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.

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.

Fig 03api to product state

The integration creates visible state.

One call to POST /cards produces status, emitted events, and retained evidence a team can inspect without leaving the product surface.

issue cardrequest

await zentra.cards.issue({
  customer: "customer_ref",
  account: "operating_account",
  spend_limit_minor: 250000,
  idempotency_key: "card_live_042"
})

product consequence

status: issued
event: card.issued
evidence: card_id
entrypoint: POST /cards

Fig 04capability model

Issuance APIs

Provision and manage card artifacts through stable contracts.

Card controls

Apply configurable limits, channels, and merchant constraints.

Authorization surfaces

Capture authorization events for risk and experience workflows.

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.

Fig 05operational proof

Evidence that holds when production gets noisy.

State, actor, tenant, signature, and policy context remain reviewable after the happy path breaks — written to be checked by operators and compliance teams, not admired in a deck.

Docs

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.