Skip to content

szTheory/accrue

Accrue

Billing state, modeled clearly.

Accrue is an open-source billing library for Elixir, Ecto, and Phoenix. Your app owns the billing facade, routes, auth boundary, and runtime config; Accrue owns the billing engine behind them.

Start one Fake-backed subscription. Post one signed webhook. Inspect and replay the result in admin. Run the focused proof suite.

Proof path (VERIFY-01)

Fake-first evaluation runs from examples/accrue_host (no live Stripe keys). Pull requests are merge-blocked on GitHub Actions job host-integration (see .github/workflows/ci.yml). Job docs-contracts-shift-left runs bash scripts/ci/verify_package_docs.sh, bash scripts/ci/verify_v1_17_friction_research_contract.sh, bash scripts/ci/verify_verify01_readme_contract.sh, bash scripts/ci/verify_production_readiness_discoverability.sh, bash scripts/ci/verify_adoption_proof_matrix.sh, and bash scripts/ci/verify_core_admin_invoice_verify_ids.sh. Job host-integration runs bash scripts/ci/accrue_host_uat.sh (which delegates to cd examples/accrue_host && mix verify.full), with bash scripts/ci/accrue_host_hex_smoke.sh on eligible runs. Use mix verify for a faster bounded Fake slice that is not CI-complete. Stripe test-mode parity uses job id live-stripe on manual runs and the daily schedule; that lane is advisory and not merge-blocking on PRs.

For a fixture-only Playwright smoke on accrue_admin (not the merge-blocking VERIFY-01 host contract), see .github/workflows/accrue_admin_browser.yml.

Hex vs main: This repository’s mix.exs @version values are the numeric SSOT for the accrue / accrue_admin pair on the branch you are reading. Hex.pm lists published artifacts when you are consuming from Hex rather than main.

.planning/ milestone labels (v1.14, v1.15, …): those names track maintainer shipping cadence in Git + planning docs only. They are not the public package major line (today’s releases are still 0.x on Hex). See RELEASING.md and accrue/guides/upgrade.md.

Maintenance posture

The pre-1.0 line treats the public façade, Fake-backed proofs, and merge-blocking CI contracts as the stability boundary: new work is intake-gated (security, correctness, linked Hex publishes, or sourced friction in the maintainer inventory), not open-ended feature expansion. Read accrue/guides/maturity-and-maintenance.md for stop rules and revisit triggers. Second processor (PROC-08) and app-owned finance exports (FIN-03) remain explicitly out of scope until a future milestone reopens them — see .planning/PROJECT.md non-goals.

# CI-equivalent local gate
cd examples/accrue_host && mix verify.full

Merge-blocking proof, VERIFY-01 commands, and Playwright entry points.

Start here

Packages

  • accrue is the core billing library. Start there for generated MyApp.Billing, webhook wiring, test helpers, and upgrade guidance.
  • accrue_admin is the mounted LiveView admin UI. Add it after the core billing and signed-webhook path is in place.

Stable first-time setup surface

Supported public setup surfaces for first-time integration:

  • MyApp.Billing
  • use Accrue.Webhook.Handler
  • use Accrue.Test
  • AccrueAdmin.Router.accrue_admin/2
  • Accrue.Auth
  • Accrue.ConfigError

Generated files are host-owned after install. Accrue may refresh pristine stamped files on installer reruns, but user-edited generated files are left alone. Internal schemas, webhook/event structs, reducer modules, worker internals, and demo-only helpers are not app-facing APIs.

Validation modes

  • Canonical local demo: Fake keeps the front door deterministic and credential-free.
  • Provider parity: Stripe test mode proves hosted Checkout behavior, signed Stripe webhook delivery, SCA/3DS branches, and response-shape drift that Fake does not cover.
  • Advisory/manual: live Stripe is for final app-specific confidence before shipping your own product, not for evaluating Accrue or passing the normal release lane.

Where to go next