Separated merchant collections and Noxtill SaaS billing, payment-provider control, commerce/returns/tax responsibilities and receipts.
Noxtill SaaS subscription payments are different from a merchant’s sales to its customers. Merchant payments and disputes remain governed by the merchant’s connected payment provider, unless a separately signed platform payments agreement explicitly changes responsibilities. Noxtill does not automatically take a fee from ordinary merchant sales.
Pricing/tax entries, order acceptance, SKU/catalog accuracy, merchant returns, discounts, customer credit records, receipts, auditability and local fiscal invoicing. Noxtill does not guarantee a credit account, collect a debt, create a banking relationship or warrant legal tax classification. Merchant owes customer-facing obligations and must configure taxes/returns.
Noxtill SaaS subscription payments are different from a merchant’s sales to its customers. Merchant payments and disputes remain governed by the merchant’s connected payment provider, unless a separately signed platform payments agreement explicitly changes responsibilities. Noxtill does not automatically take a fee from ordinary merchant sales.
Functional scope: transactions, payment links, failed payment recovery, refunds, disputes, settlements, recurring collections and routing.
Primary public legal pages: Terms; Refund & Cancellation; Privacy; Security.
Legal position: Provider/Merchant-of-Record rules govern money movement. Noxtill must not claim success before provider confirmation. Refund execution follows canonical return decision and mandatory rights.
Mandatory product controls: Provider state; idempotency; dispute evidence; payout/reconciliation roles; refund reason/approval; test/live separation.
Required UI disclosures and backlinks
- Link to the relevant public policy from the action that creates the legal risk, not only from the global footer.
- Show the acting business/branch, relevant provider or source-of-truth record, and a clear status before a consequential action is confirmed.
- Where a consent, permission, approval, signature, payment, message or provider result is required, the server must validate it at execution time. Client-side visibility alone is not sufficient.
- High-impact actions must create an audit event containing actor, role, entity, timestamp, reason/approval reference, correlation ID and external provider result where applicable.
- Data exports and bulk actions must enforce the same field-level permissions as the interactive UI and must not silently widen access.