orvacon
Architecture

A thin orchestrator over a strict core.

orvacon is a state machine wrapped around connectors. The core owns money typing, persistence, idempotency and signing; connectors only translate to a gateway. Here's how a payment moves through it.

01 — The layers
one boundary per concern
Your application
orva.authorize(order) · capture · refund
orchestrator core
state machine
Money typing
idempotency
ledger
Ed25519 signing
webhooks
Connector interface
IyzicoPayTRBank VPOS
Database adapter
SupabasePostgres
gateways settle funds to your account
02 — Request lifecycle

One payment, persisted at every step.

Each transition writes to the database before the next call. A crash or retry resumes from the last persisted state — never from a guess.

01
created
order recorded
02
authorized
cardgateway
03
requires_action
3DS · persisted
04
captured
finalize verified
05
reconciled
ledger committed
every transition is written to your database before the next call
03 — State machine

Invalid transitions don't type-check.

PaymentState is a discriminated union and the legal moves between states are encoded in the types. You can't capture a refunded payment — the compiler stops you before runtime does.

fig · PaymentState
created
authorized
requires_action
captured
refunded
voided
failed
04 — The ledger

Append-only, and it proves it.

Each ledger entry carries the hash of the entry before it. Change a past row and every hash after it stops matching — tampering is evident without trusting anyone.

entry #1 · created
hash a1f0…
prev — null
entry #2 · authorized
hash 9c4e…
prev a1f0…
entry #3 · captured
hash 5b71…
prev 9c4e…
tampered row
hash mismatch
chain breaks
State machine · ledger · connectors

See it in the source.

Every boundary on this page is a real module you can read, fork and run. No hidden services, no magic.