Verify it. Don't just trust it.
orvacon keeps money out of its own path, signs every event with asymmetric keys, and treats the database as hostile by default. Here's exactly how each flow is secured — drawn out, not asserted.
Money never flows through orvacon.
Funds move on the cardyour gateway account path. orvacon only ever sits on the control path — coordinating the call, persisting state, signing events. It holds no balance and never custodies money.
Why it matters: because the money path never touches orvacon, it falls outside money-transmitter regulation and stays off your PCI-custody scope. A compromise of the orchestrator cannot move or divert funds — there's no balance to move.
A leaked key can't forge an event.
Outbound webhooks are signed with an Ed25519 private key that never leaves orvacon; your endpoint verifies with the public key. A shared secret can be replayed by anyone who reads it — an asymmetric signature can't.
Ed25519
RFC 8032Constant-time comparison
Every signature and token is compared in constant time — an attacker can't recover it byte-by-byte by timing how fast verification fails.
Both Iyzico's and PayTR's official samples compare with ==. orvacon never does.
Two signature worlds, never crossed
separate code paths · separate keysThe callback POST is never trusted.
After the 3DS challenge the browser POSTs back to your callback — but that request is attacker-controllable. orvacon ignores its body and re-reads the result from a signed finalize call to the gateway before committing.
Secure by default, not by checklist.
The safe choice is the one you get without configuring anything.
Default-deny RLS
The Supabase adapter generates a schema with row-level security on and everything denied until you grant it.
Hash-chained ledger
Every entry references the prior hash. The ledger is append-only and tamper-evident — edits break the chain.
Idempotency enforced
A database unique constraint — not application logic — guarantees a retried request can't double-charge.
No card data stored
Raw card details go straight to the gateway. orvacon persists references and state — never a PAN.
Secrets via environment
API keys and signing keys are read from the environment, never committed and never written to the database.
Runs in your runtime
No orvacon-hosted service sees your traffic. There is no third party in the request path to trust or breach.
Found something? Tell us privately.
orvacon is v0.3 and the API is still 0.x. If you find a vulnerability, please report it through the security policy rather than a public issue — we'll coordinate a fix and disclosure.
$ npx orvacon keys # generates an Ed25519 keypair
# prints ORVACON_WEBHOOK_SIGNING_KEY=…
# set it in your environment, never commit itRotating a key is config-only — no redeploy of application logic. The public verification key can be distributed freely.
Read the code,
not the promises.
Every boundary on this page is enforced in open source. Audit it, run it in your own runtime, and verify it yourself.