refactor: extract lit-billing-core from lit-api-server stripe.rs#358
Open
clawdbot-glitch003 wants to merge 3 commits into
Open
refactor: extract lit-billing-core from lit-api-server stripe.rs#358clawdbot-glitch003 wants to merge 3 commits into
clawdbot-glitch003 wants to merge 3 commits into
Conversation
Move Stripe HTTP client, customer-identity primitives, balance read,
and reporting helpers into a new lit-billing-core crate. lit-payments
(separate non-TEE service, coming in a follow-up PR) will depend on
the same crate so the customer-identity invariant
(metadata.wallet_address keys the Stripe customer) is shared.
What moves to lit-billing-core:
- StripeClient (creds + reqwest, no caching)
- parse_stripe_response + StripeResponse
- customer::find_or_create_by_wallet, set_email
- balance::fetch
- reporting::list_all_customers / list_balance_transactions_since /
aggregate_report_rows / Report{Customer,BalanceTx,Row}
- format::cents_to_display / unix_to_utc_date
What stays in lit-api-server/src/stripe.rs:
- StripeState (caches + publishable key)
- resolve_wallet_address (depends on on-chain accounts module)
- Cached wrappers: get_customer_by_wallet, get_credit_balance
- Charge flows: charge / charge_management / charge_lit_action_time
- PaymentIntent flow: create_payment_intent / confirm_payment_and_credit
- register_customer_email, invalidate_wallet_cache
- Reporting wrappers that take &StripeState
Pure refactor: no behavior change. lit-api-server's public stripe API
is unchanged; callers in lit_api_server::stripe::* still compile and
pass tests as before. cargo check + cargo test --lib (211 tests) +
cargo test --bin stripe_report (14 tests) + clippy -D warnings all
clean.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
StripeClient already redacts its own secret_key in its manual Debug impl, so StripeState can derive Debug directly instead of carrying a manual impl whose only job was to skip the (already-safe) inner field. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
- Add lit-billing-core to the rust-ci.yml crate matrix so its 15 unit tests (moved from lit-api-server/src/stripe.rs) actually run in CI. - Add lit-billing-core/ to deploy-staging.yml DEPLOY_PATHS so future changes scoped to the shared billing crate don't get skipped. - Pin lit-billing-core's toolchain to 1.91 to match siblings and commit Cargo.lock so the new crate's CI build is reproducible.
5 tasks
clawdbot-glitch003
pushed a commit
that referenced
this pull request
May 19, 2026
New ops-facing billing service. Deploys to Railway, outside the TEE.
This PR ships the crate skeleton + magic-link auth + login UI; the
admin credit portal endpoints come in a follow-up PR.
What's here:
- Rocket binary crate at lit-payments/, sibling to lit-billing-core.
- Postgres migrations for operators + sessions tables.
- Seed migration with chris@litprotocol.com (admin) +
Salamiademola73@gmail.com (mod).
- HMAC-signed magic-link tokens (15-min expiry), verified at
/auth/verify with constant-time signature compare.
- Resend integration for sending magic-link emails.
- Session cookies (private/HttpOnly/Secure/SameSite=Lax, 7-day).
- Operator request guard so future protected routes just take
`operator: Operator`.
- Vanilla HTML/JS login page + signed-in landing page.
- Multi-stage Dockerfile for Railway (build context = repo root).
- README covering local dev + Railway deploy + Resend setup.
Stacked on glitch003/lit-billing-core (PR #358). Targets that branch
so it can land cleanly once the extraction merges.
cargo check + cargo test --lib + cargo clippy -D warnings + cargo fmt
all clean. Tests cover the token issue/verify roundtrip + the
expired/tampered/wrong-key failure modes.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
lit-billing-corecrate owns the Stripe HTTP client, customer-by-wallet lookup, balance reads, reporting helpers, and pure formatters.lit-payments(coming separately) will depend on it so the customer-identity invariant —metadata.wallet_addresskeys the Stripe customer — is single-source-of-truth.lit-api-server/src/stripe.rskeeps its public API unchanged (caches, charge flows, PaymentIntent flow,resolve_wallet_address) and now delegates HTTP + customer/balance primitives tolit-billing-core.cargo check,cargo test --lib(211 passing),cargo test --bin stripe_report(14 passing), andcargo clippy -D warningsare all clean.See
plans/lit-payments-app.md(PR #354) for the bigger picture.Test plan
cargo checkclean in both cratescargo test --lib— 211 lit-api-server tests passcargo test --bin stripe_report— 14 tests passcargo testinlit-billing-core— 15 tests pass (moved from stripe.rs)cargo clippy --all-targets -- -D warningsclean in both cratescargo fmt --checkclean