> ## Documentation Index > Fetch the complete documentation index at: https://docs.unprice.dev/llms.txt > Use this file to discover all available pages before exploring further. # How Unprice Works > A high-level architecture view of where Unprice fits in your product. Unprice sits between your product, your payment provider, and the paid work your customer triggers. Your app still owns the product experience and workload execution. Your payment provider still captures payment. Unprice owns the customer money path between them: pricing rules, entitlement decisions, usage evidence, wallet credits, billing state, and the trail that explains why work was allowed, denied, or billed. A paid action flows through plan version, entitlement, budget, and wallet checks, then is allowed or denied before work runs while invoice evidence is preserved. ## The Three Boundaries Owns the user experience, workload execution, and the moment a paid action is about to run. Owns pricing rules, entitlement decisions, budgets, wallet credits, billing state, and evidence. Captures or simulates payment through Stripe, Sandbox, or a custom provider adapter. ## The Money Path | Stage | What happens | Why it matters | | ---------------- | ------------------------------------------------------------------------------------ | --------------------------------------------------------------------------- | | Paid action | Your app is about to run work that can create cost | The money question happens before the cost exists | | Pricing model | Unprice resolves the plan version, feature, meter, and entitlement | Pricing logic stays out of product branches | | Runtime decision | Unprice checks entitlement, budget, wallet credits, and meter rules | The request can be allowed or denied immediately | | Evidence trail | Usage facts, wallet movement, ledger entries, and invoice evidence are kept together | Support, analytics, replay, and invoices share one explanation | | Payment capture | The provider adapter captures or simulates money movement | The payment rail can change without moving pricing logic back into your app | ## The Payment-provider Boundary Unprice is not a Stripe wrapper. Stripe is the built-in production adapter today, and Sandbox is available for testing. The important boundary is the provider interface: invoice creation, invoice items, payment methods, checkout/setup sessions, payment collection, and webhooks are provider operations. That means the pricing and evidence path can stay in Unprice while the payment-capture system can change. A team running its own deployment can implement another provider adapter without moving entitlement, metering, wallet, billing, or invoice-evidence logic back into product code. ## The Runtime Paths Use `access.check` when your app only needs to know whether a customer can use a feature. Use `usage.consume` when known usage should be blocked if the customer is over limit, budget, or credits. Use `usage.record` when the request should not wait for Unprice to decide. Use `runs.start`, `runs.consume`, and `runs.end` for jobs, workflows, tool chains, and agents. ## What Unprice Does Not Own Unprice does not run your product workload. Your application still decides when to call the LLM, start the job, send the API request, or execute the workflow. Unprice also does not replace your payment provider. Stripe, Sandbox, or another provider adapter still captures or simulates money movement. Unprice owns the pricing logic and evidence path that explains what should be charged, credited, denied, or replayed.