Preview guidance. Review the decisions and proposed changes before applying them to your product.
Trace usage and application decisions
Inspect native signup and organization creation, usage emitters, delayed jobs, contract setup, balance or quota reads, callbacks and billing screens. Determine whether your application uses provider information to grant access, limit consumption or display charges. Inventory required local reference data and remote identifiers. An application can require a local plan row or customer-to-contract mapping before a user can create ordinary application data. Infrastructure and migration success alone do not prove that bootstrap is complete. Keep metering, rating, payment collection and application entitlements distinct. Decide which of these functions belongs in the customer product and define the behavior of any replacement.If you retain Metronome
Choose the account owner and a supported setup procedure. Reconcile the application’s expected metrics, products, rate cards, customers and contracts with that account. Metronome’s API token selects sandbox or production, so verify the intended environment before testing. See its API quickstart. Preserve event identity and the mapping to the intended customer or ingest alias when retrying usage. Metronome usestransaction_id for deduplication; see sending usage events. Keep usage data and credentials within the agreed customer/vendor ownership and data-handling arrangement.
If Metronome sends invoices to Stripe, review both customer and contract billing-provider configuration and the mapped Stripe account/customer. Changing either provider’s credential does not establish those relationships. See Metronome’s Stripe invoicing guide.
Where the application consumes notifications, authenticate the notification or retrieve authoritative provider state before acting. Handle retries and duplicates without applying a business change twice. Follow Metronome’s webhook guidance.