witnora

Witnora Assurance Wallet v0.1

The Assurance Wallet is a non-custodial authorization record for covered payment action paths. It does not hold money, cards, private keys, API keys, or raw Stripe/Cloudflare payment tokens.

It binds the existing assurance chain:

VerifiedPrincipal
  -> immutable mandate
  -> wallet budget policy
  -> one-use payment token digest
  -> PAY action
  -> approval
  -> independent outcome probe
  -> signed Action Assurance Receipt

Safety boundary

• v0.1 accepts SANDBOX and TEST provider accounts only.
• LIVE references are rejected before authorization.
• The customer-owned Gateway computes SHA-256 locally and submits only the digest.
• The server rejects fields named token, rawToken, secret, apiKey, privateKey, or cardNumber.
• One token reference can authorize one action. Binding and budget checks are atomic in PostgreSQL.
• v0.1 budgets use exactly one base currency so period limits are not computed across incomparable currencies.
• A failed or successful outcome consumes the reference, preventing replay.
• The receipt states whether provider execution was actually mediated. A token digest alone never upgrades evidence to ENFORCED.

Customer flow

Create the wallet and provider account in Hosted Runtime Assurance, then let the customer-owned Gateway register only a locally computed SHA-256 token reference. Keep the raw provider token in the customer’s secret store. It must not be uploaded to Hosted, logged, or added to evidence.

Provider semantics remain explicit rather than pretending every provider has the same token object:

• Stripe references can represent a test Shared Payment Token (SPT), which is transaction-scoped and time-limited. Stripe Agentic Commerce is currently a private-preview surface; Witnora does not enable access to it.
• Cloudflare references can represent an MPP/x402 payment proof or payment header. They are not Cloudflare account-billing credentials and Witnora does not hold the payer’s signing key.

Set tokenType to the concrete provider object or protocol proof being digested. Provider-specific execution and webhook verification belong in a customer-owned enforced adapter, not in the Hosted wallet record.

Wallet policy and provider-account bindings are human-administered. They cannot be created by the Gateway API key. In Setup -> Connections, create a Payment gateway key; it can register token digests but cannot change wallet authority. Create a separate Payment outcome probe key to submit observed provider state. Payment actions reject outcome reports from the gateway key, human UI, or ordinary action keys. The split makes execution and verification distinct, but a probe report still does not become ENFORCED without adapter attestation.

Non-goals

• no custody or stored balance;
• no real payment execution;
• no card vault;
• no crypto wallet or private key management;
• no claim that Stripe or Cloudflare endorsed the resulting receipt.

This site is open source. Improve this page.