Evidence: application confirmation vs provider document
The application purchase confirmation communicates that the application accepted a signed provider event and observed the corresponding normalized payment plus credit or entitlement effect converge. It is delivered through the durable email outbox, but the email itself is not authoritative evidence. Use the provider's canonical records together with the normalized application state as the payment evidence. The confirmation is not an invoice, a tax receipt, or independent proof that the provider completed every fiscal obligation.
The commercial document depends on the provider selected during initialization:
| Provider model | Seller shown at checkout | Source of the official commercial document |
|---|---|---|
| Stripe payment service provider | The company configured in this application is the seller; Stripe acts as payment processor. | Use the seller's configured Stripe billing/invoicing records. The application confirmation remains only a purchase confirmation. |
| Lemon Squeezy Merchant of Record | Lemon Squeezy | Lemon Squeezy handles payment, taxes, official invoices or receipts, and refund requests. |
| Paddle Merchant of Record | Paddle | Paddle handles payment, taxes, official invoices or receipts, and refund requests. |
Do not promise a tax treatment, document type, refund outcome, response time, or legal classification from this runbook. Those are human decisions governed by the operator's commercial setup and the selected provider's current records.
Investigate an application mismatch
- Confirm which provider and test/live mode the installation uses. The customer cannot select a provider, and an existing installation must not change provider in place.
- For purchase evidence, distinguish the application's confirmation email from the provider-issued invoice or receipt before answering the customer.
- As an active platform admin, open
/admin-dashboard/billing/reconciliation. Filter by status, severity, issue type, or test/live mode, then correlate the bounded Account, local resource, external resource identifier, timestamps, and safe metadata shown by the page. - Compare those redacted application facts with the selected provider's canonical dashboard records. Record only the minimum support conclusion and the human decision; never paste provider payloads, API responses, secrets, signing material, full customer data, or raw
detailsJSON into the reason. - Escalate the business or engineering decision to the human owner identified in the matrix below. The reconciliation page does not execute a financial or subscription command.
The admin page intentionally exposes a safe projection. Routine support must not bypass it by querying or exporting raw provider-derived details.
Issue matrix
| Issue type | What the signal means | Human decision required | Resolve only when |
|---|---|---|---|
license_partial_refund_policy_required | A provider-confirmed partial adjustment reached a licence payment, but the application has no universal rule for the remaining licence entitlement. | The product/billing owner decides the applicable entitlement policy after support verifies the payment and licence identities. | The chosen follow-up has been completed through the appropriate owned process and its local outcome has been verified. |
affiliate_paid_conversion_clawback_required | A provider-confirmed payment adjustment affects an affiliate conversion already marked paid. | The finance/affiliate owner decides the accounting and partner follow-up; the admin page does not reverse a payout. | The decision and resulting records have been verified by the responsible human owner. |
plan_change_reconciliation_exhausted | A durable subscription plan-change command did not converge after its bounded observation attempts. | Billing/engineering compares the provider subscription with the redacted command facts and decides the next operational escalation. | The authoritative provider and normalized application states are understood and the required follow-up is complete. |
subscription_control_reconciliation_exhausted | A durable cancel, immediate-cancel, pause, resume, or end-trial command did not converge after its bounded observation attempts. | Billing/engineering determines whether provider state already reflects the intent or whether a separate controlled intervention is needed. | The command's authoritative outcome and the corresponding local state have been verified. |
Acknowledge and resolve
openmeans the application still needs operator attention.acknowledgedmeans an active platform admin has accepted ownership and recorded a required reason. It does not change payment, entitlement, subscription, affiliate, or provider state. A later observation updates the same unresolved issue without reopening or duplicating it.resolvedis available only after acknowledgement. It records that the required human decision or follow-up has been completed and verified; it does not perform that work. The transition requires billing step-up authentication, a reason, and the current issue version, and the application writes the transition and admin audit entry atomically.
If the issue changed while it was being reviewed, reload the page and reassess the latest redacted facts instead of overwriting another operator's work.
Actions outside this surface
The reconciliation page cannot initiate refunds, decide disputes or chargebacks, replay events, force synchronization, migrate an installation to another provider, or construct provider-dashboard links. Perform provider-owned financial and risk work in the configured provider's own controls, then let signed events and bounded reconciliation update application state. Any exceptional manual data repair is an engineering change with its own review and verification, not a support-page action.
For the billing architecture and provider setup, see Payments & Billing. For platform-admin access and page ownership, see Admin Dashboards.