Answers to the hard questions. With the math shown.
Not just what the number is, but how it is computed, what events changed it, and how to verify it independently. For founders, finance teams, and auditors.
⚲
Metrics & formulas
MRR (Monthly Recurring Revenue) is the sum of normalized monthly amounts from all active subscriptions at a given point in time. We derive it from Stripe subscription objects, not from charge amounts.
MRR= Sigma monthly_amount for all active subscriptions
MRR does not include one-time charges, failed payments, or pending invoices. It reflects the contracted recurring amount, not the collected amount. For collected revenue use Net Revenue.
MRR is a point-in-time metric. It reflects what is contracted right now, not what was billed or collected in a period.
MRR is what customers are contracted to pay. Net Revenue is what was actually collected in a period, minus refunds and Stripe fees.
gross_revenue= Sigma succeeded charges in period
refunds= Sigma refund amounts in period
stripe_fees= Sigma balance_transaction.fee for charges
Net Revenue can be lower than MRR in a month if some invoices failed, there were large refunds, or Stripe fees were high. It can be higher than MRR if annual subscriptions were charged in that month.
In Dnoise, LTV is deterministic, not a predictive model. It is the average total amount paid across all paying customers based on actual payment history.
customer_lifetime_paid= Sigma succeeded charges for customer
This is not a forward-looking prediction. It tells you what the average customer has paid historically, useful for understanding cohort value and recovery ROI, not for forecasting future revenue.
LTV with usage and CRM data requires the Client Data plan and your data upload.
Failed payment rate is the percentage of payment attempts that did not succeed in the selected period.
total_attempts= count(all charges in period)
failed_attempts= count(charges where status !="succeeded")
A healthy failed payment rate is 2-4%. Above 5% indicates a systemic issue. Dnoise breaks this down by failure reason (card_declined, do_not_honor, insufficient_funds) and by processor so you know where the problem actually is.
Revenue at Risk is the total amount of expected revenue that may not collect, composed of failed payments that can still be retried, pending invoices past due, and active retries not yet resolved.
failed_recoverable= Sigma failed charges within retry window
pending_collection= Sigma open invoices past due date
active_retries= Sigma charges in pending/processing state
Revenue at Risk is not confirmed loss. It is the upper bound of what could still go wrong. Confirmed losses are tracked separately in the Losses report.
Dnoise separates churn into two categories because they require different responses.
Voluntary churn tells you about product-market fit. Involuntary churn tells you about payment infrastructure. Mixing them gives you a misleading signal.
Refund rate is calculated on a volume basis, refunded amount vs total charged amount, not on a count basis.
total_charged= Sigma succeeded charge amounts in period
A refund rate below 1% is normal. Above 2% is worth investigating. Above 5% can affect your Stripe account standing. Chargebacks are tracked separately and carry more risk to your merchant account than voluntary refunds.
ARR is simply MRR multiplied by 12. It is a projection, not a sum of past payments.
ARR=MRR*12
ARR is useful for communicating scale to investors and boards. It should not be confused with actual annual revenue collected, which depends on payment success rates, refunds, and churn during the year.
Security & access
No. This is technically impossible with a restricted read-only key, not just a policy. A Stripe restricted key created with only read permissions cannot create charges, issue refunds, update subscriptions, or move money in any direction. Stripe enforces this at the API level.
Even if Dnoise servers were compromised, no financial action could be taken with a read-only key.
Yes, we store it encrypted at rest using AES-256 in order to run scheduled syncs. The key is never logged in plaintext, never transmitted in URLs, and is only decrypted in memory during sync jobs. You can delete or rotate it from your account settings at any time.
Two ways, either works immediately:
1. Go to Stripe Dashboard -> Developers -> API Keys and delete the restricted key you created for Dnoise. We immediately receive auth errors and stop syncing.
2. Go to Dnoise Settings -> Stripe Connection and remove the key. This removes it from our system and stops all syncs.
Revoking access does not automatically delete your historical report data. To delete all data, go to Settings -> Account -> Delete all data.
No. Stripe never exposes full card numbers (PAN), CVV, or full expiry dates through the API, regardless of permissions. The most sensitive card data Dnoise can ever see is the last 4 digits and card brand (for example "Visa ****4242"), which Stripe exposes for display purposes only.
Report freshness metadata is always shown. If a sync is pending, the report shows an explicit freshness warning rather than silently showing stale data.
Every metric change in Dnoise is backed by an append-only event trail. Use the Explain a Metric panel on the Overview page to see the exact chain of events.
Mar 6, 18:15 UTCMRR-$200SUBSCRIPTION_CANCELLED · evt_sub_1
Mar 6, 19:05 UTCMRR-$100SUBSCRIPTION_UPDATED · evt_sub_2
Mar 6, 21:12 UTCMRR-$50SUBSCRIPTION_PAUSED · evt_sub_3
Total: -$350 · 3 events · Export to CSV
Stripe processes payments asynchronously. A charge can appear as "succeeded" but the payout may not yet be settled. Some payment methods (ACH, SEPA, BACS) have multi-day settlement windows.
Revenue is not final until all pending payments are settled and the webhook queue is empty. Dnoise shows both in real time so you do not publish incorrect end-of-month numbers.
Stripe webhook delivery is at-least-once, the same event can be delivered multiple times. Dnoise deduplicates all incoming events by their Stripe event ID before they reach the metric ledger. Out-of-order events are handled by timestamp-based ordering during ingestion.
Your metric history is stable and consistent even if Stripe delivery is noisy. Corrections in our system are always new events, we never silently edit historical data.
When you cancel, data is retained for 30 days during which you can export everything. After 30 days, all your data is permanently deleted: metric ledger, report cache, and any uploaded CRM/usage files. We do not sell or transfer your data.
To delete data immediately: Settings -> Account -> Delete all data. This is irreversible and takes effect within 24 hours.
Billing & plans
This almost always means your Stripe key does not have all the permissions required for your plan. Advanced requires payment_intents and subscription_items in addition to Core permissions. Add those two permissions to your existing key in Stripe Dashboard -> Developers -> API Keys.
The plan you purchase determines what Dnoise can show you. The Stripe key permissions determine what data we can read. Both must match for all reports to work.
Yes. Upgrading takes effect immediately after payment confirmation. Downgrading takes effect at the end of your current billing period. When downgrading, features that require a higher plan become locked, but your historical data is preserved.
We currently use a crypto payment request flow for the live public checkout. After registration you are shown a payment page with the exact plan amount, the supported currencies currently available from the payment provider, a wallet address, a QR code, and step-by-step instructions. You must pay the exact amount shown for that request.
The currently live public checkout is Source Core only and follows a strict full-payment-only policy. Partial or fragmented transfers do not activate access. Traditional payment providers may be added later. If you need an invoice for accounting purposes, contact us at admin@dnoise.online.
Trust & audit
Every report includes three reproducibility fields:
contract_version->which metric definitions were used
payload_fingerprint->SHA hash of the input data used
If we update how MRR is calculated, your old reports do not change retroactively. A report from March 6th always shows March 6th MRR by the exact formula that computed it. This is what makes our reports defensible in audits.
Yes. From any report you can export the metric trace (every delta with reason code and Stripe event ID), the report payload with formula version and fingerprint, and the underlying data aggregates as CSV.
Dnoise reports are operational analytics, not GAAP/IFRS financial statements. They are useful as supporting evidence and reconciliation tools, not as primary accounting records.
No. Every metric in Dnoise is computed from deterministic formulas applied to Stripe billing events. There is no machine learning model, no AI inferring customer intent, and no benchmarking against external data.
When Dnoise shows "recovery probability 70%" it means: historically, charges with this failure reason and this retry timing have succeeded 70% of the time in your own data. It is a historical rate, not a prediction model.
We deliberately do not sell churn prediction, pricing advice, or growth strategy. These require assumptions about your product and market that we refuse to make without data you have not given us.