Rust product and compliance-integration engineer2026Public detailed

KsefPay

A Rust product for Polish e-invoicing: official XML generation/validation, workspaces, company tax-ID accounts, encrypted certificates, and KSeF sandbox flows.

Reading frame

Official invoices with typed custody boundaries

KSeF integration needs schema accuracy, session handling, certificate custody, tenant isolation, permissions, audit trails, and operational hygiene.

`ksef-core` owns domain/integration logic; `ksef-server` wraps it with Axum routes, workspace tenancy, account scopes, encrypted certificate storage, CSRF, rate limits, audit logs, and sandbox flows.

Boundary note: The project should be presented as a side project and product/compliance chapter, not as a replacement for the blockchain systems narrative.Certificate encryption depends on preserving the configured storage key; losing that key means stored certificate material cannot be decrypted.
Evidence path: Official invoice XSD validation / Generated invoice model / KSeF session integrationPublic product evidence: typed invoices, KSeF sessions, tenant/account scope, certificate custody, and guardrails.
What it proves: Shows serious Rust product engineering outside blockchain with typed boundaries and security posture
Adds breadth: compliance integration, tenancy, and operational security

System Model

How the data moves through the system

First read the data path. Then use the code hooks as pointers to the mechanisms that make the claim inspectable.

Data path

01

Schema-backed invoice generation

Generated structures and XSD validation make official invoice XML reviewable and testable.

02

Workspace-first tenancy

Workspaces and tax-ID accounts scope access, permissions, invoice history, exports, and membership.

03

Certificate and access boundary

Authentication, certificate storage, invites, capabilities, and controls stay explicit.

Code hooks

01

Generated invoice model

Generated types and validation tests keep the official schema as source of truth.

02

KSeF sandbox integration path

Tests cover challenge, certificate auth, session open, invoice send, and session close.

03

Sealed account scope

Operations bind to selected workspace and tax-ID account, not ambient user identity.

04

Encrypted certificate custody

Company certificates are stored through an encrypted path keyed by application config.

05

Operational guardrails

CSRF, rate limits, audit events, invites, SMTP mode, and production checks are explicit.

Execution Flow

How the system progresses

A short staged view of the system from start to final output.

#01

Stage 01KsefPay

Create workspace and company account

The user works inside a workspace and selected company tax-ID account.

#02

Stage 02KsefPay

Prepare identity and access

The app prepares certificates, permissions, invites, and account scope before KSeF operations.

#03

Stage 03KsefPay

Generate, validate, and send invoices

Invoice data becomes official XML, validates against XSD, sends through KSeF, then enters history/export paths.

Code evidence

Public product evidence: typed invoices, KSeF sessions, tenant/account scope, certificate custody, and guardrails.

Official invoice XSD validationGenerated invoice modelKSeF session integrationWorkspace-first tenancyEncrypted tax-ID certificatesScoped account permissions

What to inspect in public code

Inspect `ksef-core` for domain split, generated invoice bindings, KSeF session code, and account-scope modeling.
Inspect `ksef-server` for Axum routes, workspace/account flows, invites, CSRF/rate-limit/audit integration, and production checks.

KsefPay Repo

Reading mode

This chapter stands on architecture and public evidence.