Glossary

A handful of terms in these docs are worth pinning down up front. Some come from card-payments vocabulary. The rest are specific to billing on a stablecoin chain.

API key kinds

Secret key. Full permissions, server-side only. Prefixed sk_test_ or sk_live_.

Publishable key. Marks browser calls as test or live mode and grants no access. The public checkout and token routes do not check it, and every other route rejects it. It cannot create a payment session. Safe to ship in a browser. Prefixed pk_test_ or pk_live_.

Charge attempt ID

A 32-byte deterministic identifier passed to the contract's batchCharge so retries are safe. Computed as keccak256(abi.encodePacked(onchainSubId, currentPeriodEndAt, attempt)), with attempt from 0 to 7. The contract's usedAttempts mapping skips a reused id with outcome Duplicate instead of charging again.

Confirmations

The number of blocks the indexer waits behind the chain head before projecting an event, set with CONFIRMATIONS. It is required and has no default. Arc has deterministic sub-second finality, so there are no reorgs to guard against; 1 is the recommended value.

EIP-2612

The "permit" standard. The payer signs a structured message that grants a contract an ERC-20 allowance. USDC and EURC both implement it natively. Strimz uses it in the subscription enrolment call (permitAndCreateSubscription), alongside a second signed SubscriptionIntent. The meta-tx flow page walks through the full sequence.

EIP-3009

The "transfer with authorization" standard. The payer signs a structured message authorising a specific recipient to pull a specific amount of a specific token. USDC and EURC implement it natively. Strimz uses it for the single-signature one-shot payment call (payWithAuthorization). See the meta-tx flow page for the wire-level detail.

EIP-712 typed-data

The format a wallet uses to display a structured message instead of a raw transaction or an opaque personal_sign blob. EIP-3009 and EIP-2612 are both built on top of it, which is how the wallet renders human-readable fields like from, to, value, and deadline rather than a hex string.

ERC-7201

The "namespaced storage" pattern. It lets a contract park its state at a deterministic slot so adding fields later can't collide with the previous layout. Strimz's upgradeable contracts use it, which makes forge upgrade provably safe.

Idempotency key

A string the client picks per write, so the API can dedupe retries. The SDK sends one in the X-Strimz-Idempotency-Key header on every POST and PATCH. The API replays the first response for the same key for 24 hours. See Idempotency.

Indexer cursor

The bookmark that tracks "what block has the indexer projected up to". One row per (chainId, contractAddress) in the IndexerCursor table. Truncating it makes the indexer re-process from START_BLOCK, the block the contracts were deployed at.

KMS-backed signer

The pattern Strimz uses to sign relayer transactions on Arc. The relayer asks a signer provider for a signature instead of holding the key itself. KMS_PROVIDER picks the provider. The default, software, reads the key from KMS_SOFTWARE_PRIVATE_KEY in the environment and is meant for development. aws-kms keeps the key in AWS KMS, so it never appears in an environment variable or on disk. The relay section of the API reference covers the operator-side configuration.

Live mode and test mode

Two separate modes with their own API keys. Each Strimz deployment runs in one mode with its own contracts: test mode on Arc testnet, live mode on Arc mainnet. Every resource also carries a mode, and a resource created in one mode cannot be read or modified from the other. Live keys can't be created until Strimz runs on Arc mainnet.

Meta-tx

Short for "meta-transaction." The customer signs a structured message off-chain. A third party (Strimz's relayer) wraps that signature into a transaction and broadcasts it. The customer pays no gas. The relayer pays gas but cannot move funds on its own; the contract verifies the customer's signature on every call. payWithAuthorization and permitAndCreateSubscription are both meta-tx entrypoints.

Mode

A column on most resources (Subscription.mode, Transaction.mode, etc.) recording whether it was created in test or live mode.

On-chain merchant ID

A uint96 assigned by StrimzRegistry when a merchant first registers their payout wallet on-chain. Stored in Merchant.onchainMerchantId and exposed on session/plan payloads as chainMerchantId. The contracts use it (not the off-chain cuid) as the canonical merchant identifier.

Permit nonce

A per-owner monotonic counter that EIP-2612 tokens maintain. The current value goes into the signed permit; every successful permit increments it on-chain. A stale nonce reverts. Read it just before signing via tokens.permitNonce(token, owner).

Pull-based subscription

The customer signs once, granting the contract a multi-period allowance. The Strimz scheduler then "pulls" payment each period. The opposite is push-based, where the customer initiates each charge themselves.

Ref

A bytes32 identifier passed to StrimzPayments.pay() and payWithAuthorization(). The indexer uses it to join an on-chain payment back to its PaymentSession.id.

Relayer

The Strimz process that broadcasts payer-signed authorisations to the chain. It holds a KMS-backed signing key it uses only to pay gas. The contracts authorise the payer's signature, not the relayer's, so a relayer-key compromise costs Strimz some gas and nothing else. It cannot be used to move customer funds.

Sub-tenancy

The parentMerchantId field on StrimzRegistry. Lets a merchant register under another merchant for hierarchical billing arrangements: resellers, agency-of-record relationships, multi-brand orgs. Charges still settle to the child merchant's own payoutAddress. The parent field is metadata the reseller can reconcile against.

UUPS

Universal Upgradeable Proxy Standard (EIP-1822). Used by Strimz's policy contracts: Registry, FeeCollector, TokenWhitelist, AgentRegistry, AgentEscrow. StrimzPayments and StrimzSubscriptions are not UUPS. They are deliberately immutable. On-chain architecture covers why the line falls where it does.

Webhook delivery

One event sent to one endpoint, with up to 5 attempts. Persisted in the WebhookDelivery table, so you can see the latest attempt's response code and body in your dashboard.

Webhook signing secret

The HMAC key Strimz uses to sign outbound webhook deliveries. Generated when you create the endpoint and returned to you exactly once. Stored on the Strimz side as an AES-256-GCM ciphertext in Postgres so a database dump leaks nothing useful. The scheduler decrypts it into a Redis cache on startup; that cache is what the delivery worker reads on the hot path.