Legal
Subscription / Payment Terms
These Subscription / Payment Terms describe payment timing, signup payment treatment, recurring billing, payment authorization alignment, taxes, invoices, refunds, credits, disputes, failed payments, cancellation requests, add-ons, portal controls, and related payment records for the applicable Sites customer relationship.
1. Role Of These Terms
1.1 Payment lifecycle document. These Terms describe the payment lifecycle for Sites subscriptions, including the signup payment, saved payment method, recurring billing, invoices, add-ons, taxes if applicable, refunds, credits, disputes, failed payments, cancellation requests, and related records.
1.2 Relationship to Order Form. The Order Form controls the selected plan, customer-specific price, add-ons, scope, launch destination, payment amounts, and customer-specific terms. These Terms govern payment mechanics unless the Order Form expressly states a customer-specific payment term.
1.3 Relationship to Payment Authorization. The Payment Authorization controls Customer's authorization for Sites and its payment processor to charge the Payment Method. These Terms identify payment categories, timing, and records that must align with that authorization.
1.4 Relationship to Default / Nonpayment Terms. The Default / Nonpayment Terms govern staged consequences for failed payments, unresolved disputes, chargebacks, nonpayment, suspension, termination, settlement, write-off, and ownership-transfer withholding.
1.5 Relationship to Ownership Transfer Terms. Ownership transfer eligibility depends on the applicable transfer terms, full-term completion or approved resolution, Account Standing, no unresolved payment default, and platform/transfer records.
1.6 No expansion by operational materials. Checkout screens, invoices, payment links, portal labels, dashboard notices, Help Center articles, sales messages, and onboarding materials do not expand or override the signed documents unless the signed documents expressly incorporate them.
2. Defined Payment Terms
2.1 "Signup Payment" means the first monthly plan payment collected at signup. It is not a setup fee.
2.2 "Recurring Billing" means the ongoing monthly billing cycle for the selected plan after Launch and Approval evidence is recorded.
2.3 "Launch" means the new Sites-built website is published or live on the customer domain or other approved launch destination, the core launch scope is complete, required launch approvals are received or recorded, and the site is ready for public use under the signed scope.
2.4 "Approval" means a customer-visible, timestamped launch or payment-trigger approval by an authorized Customer representative through signature, dashboard approval, email approval, project-management approval, payment/launch confirmation, or another written approval record that identifies the approver, approval channel, approved launch scope, known deferred items, recurring-billing trigger, and next expected charge date.
2.5 "Launch Approval" means Launch and Approval together when those concepts are used as the combined trigger for Recurring Billing, Term Start, launch records, and post-launch service status.
2.6 "Term Start" means the Launch Approval date unless the Order Form expressly states another term-start rule.
2.7 "Payment Method" means the card, bank account, wallet, or other payment method provided through Stripe or another approved payment processor.
2.8 "Approved Add-on" means an add-on, extra-time request, migration extension, scoped service, or Exception Path item approved in the Order Form, signed add-on scope, dashboard workflow, email approval, invoice approval, or another written approval record accepted by Sites.
2.9 "Failed Payment" means any declined charge, unpaid invoice, expired payment method, payment reversal, payment-processing failure, or other unpaid amount due under the signed documents after payment review confirms unpaid status. A good-faith billing inquiry, plausible duplicate-charge issue, suspected erroneous charge, customer support request, or documented good-faith dispute is not a default-triggering Failed Payment unless the payment review process confirms unpaid status, default status, fraud/security risk, chargeback abuse, or another signed-document default trigger.
2.10 "Cure Period" means the payment-resolution period stated in the Default / Nonpayment Terms, Order Form, payment notice, or other applicable payment record after a Failed Payment.
2.11 "Account Standing" means Customer has paid amounts due or resolved them under an approved payment, credit, settlement, write-off, or restoration record, with no unresolved payment default, chargeback, dispute, suspension condition, or transfer-blocking issue.
2.12 "Cancellation Resolution Review" means the review process triggered by a cancellation request, portal cancellation event, dashboard cancellation request, support cancellation request, billing email, invoice-email response, card-network inquiry, or similar cancellation-related communication. The review record must identify the intake channel, requester, request date, customer status, Launch Approval status, Term Start if any, payment status, automatic-billing status, open invoices, refund/credit request, default status, ownership-transfer status, decision owner, customer communication, and outcome.
3. Core Payment Structure
3.1 First month due at signup. Customer pays the first month of the selected plan at signup. The Signup Payment is collected before project kickoff, onboarding, planning, platform setup, production scheduling, or other initial work.
3.2 No setup fee. Sites does not charge a setup fee. The amount due at signup is the first monthly plan payment, plus any approved signup add-ons, taxes if applicable, or other approved charges shown in the Order Form or payment flow.
3.3 Separate tracking. The Signup Payment must be separately identified in payment, accounting, customer-service, refund, launch, and lifecycle records. It must not be merged into Recurring Billing records in a way that hides its timing, purpose, or refund/credit status.
3.4 Recurring Billing after Launch Approval. Recurring Billing begins only after Launch Approval is recorded. Any statement that only says recurring billing begins at launch is incomplete unless it also preserves the first-month-at-signup rule and the Launch Approval trigger.
3.5 24-month managed-service commitment. The standard structure uses a 24-month managed-service commitment. Term Start is Launch Approval unless the Order Form states another term-start rule.
3.6 Selected plan price. The monthly plan price is the price listed in the Order Form for Essential, Professional, or Premium.
3.7 Add-ons and scoped work. Approved Add-ons, Extra Managed Time, Extra Growth Time, Migration Expansion, Migration Plan, Complex Migration, custom work, and Exception Path work are charged only if approved under the signed scope, Order Form, add-on approval, or other written approval record.
4. Payment Schedule And Commitment Economics
4.1 Required payment schedule. Before the Signup Payment is collected, the Order Form or payment record should identify:
selected plan;
monthly plan price;
Signup Payment amount;
whether the Signup Payment counts toward the 24-month commitment, a pre-launch service period, a credit against the first post-Launch invoice, or another stated treatment;
number of post-Launch recurring plan payments;
base 24-month commitment total, excluding taxes and add-ons;
first post-Launch recurring charge date or trigger;
first post-Launch invoice term-month number;
no-duplicate-period check;
cancellation/default economic consequence cross-reference.
4.2 Total plan payment math. The payment record must show the signup amount, Signup Payment treatment, number of post-Launch recurring invoices, total plan payments, base plan total excluding taxes/add-ons, first recurring invoice date or trigger, Signup Payment service period, first recurring invoice service period, and any unresolved arithmetic issue.
4.3 No duplicate month without written basis. The Signup Payment and first post-Launch recurring invoice must not charge the same service period twice unless the record identifies a separate service period or performance obligation, a customer-visible payment approval record, invoice/service-period evidence, and the reason the charge is not an accidental duplicate.
4.4 First-month treatment. If the Signup Payment is described as the first monthly plan payment while Term Start is Launch Approval, the payment record must identify whether that payment applies to a pre-launch/onboarding service period, term month 1, a credit against the first post-Launch invoice, or another stated treatment.
5. Amounts Due
5.1 Amount due at signup. The total due at signup includes only the amounts shown in the Order Form, payment flow, or approved payment record, which may include:
first monthly plan payment;
approved signup add-ons, if any;
approved one-time or scoped charges due at signup, if any;
taxes or processor-supported tax amounts if applicable and configured.
5.2 Monthly recurring amount. The recurring monthly amount after Launch Approval includes only the amounts shown in the Order Form, approved add-on record, approved adjustment record, or invoice, which may include:
selected monthly plan fee;
approved recurring add-ons;
applicable taxes or processor-supported tax amounts if configured;
approved recurring adjustments, discounts, credits, or plan changes.
5.3 Separately approved charges. The following must not be charged unless approved and recorded:
Extra Managed Time;
Extra Growth Time;
Migration Expansion;
Migration Plan if not included in the selected plan;
Complex Migration;
photography, video, brand identity, content writing, custom applications, custom workflows, or other separately scoped work;
Exception Path work;
restoration, settlement, or default-resolution amounts if applicable.
5.4 Invoice controls. Each invoice or payment record should identify the payment category, plan, add-on if any, customer, customer state, billing address, service-received location if different, Order Form ID, service period or milestone, tax status if applicable, document version reference, and approval record where applicable.
6. Payment Authorization And Saved Payment Method
6.1 Payment Authorization required. Customer must complete or accept the Payment Authorization before Sites collects the Signup Payment or saves a Payment Method for future charges.
6.2 Authorized charge categories. Customer authorizes Sites and its payment processor to charge the Payment Method only for the charge categories identified in the Payment Authorization, including the Signup Payment, Recurring Billing, Approved Add-ons, approved scopes, taxes if applicable, failed-payment retries, unpaid invoices, approved settlement/restoration/default-resolution amounts, and other expressly authorized charges.
6.3 Non-plan charge confirmation. Any non-plan charge that is not already fixed in the Order Form must have an amount or cap, charge category, invoice or approval ID, timing, payment method to be charged, and separate customer confirmation before Sites charges a saved Payment Method. This includes default-resolution amounts, restoration amounts, settlement amounts, add-on charges, extra-hour charges, migration charges, and Exception Path charges.
6.4 Saved Payment Method. Sites may use Stripe or another approved payment processor to store the Payment Method for future charges, invoice payments, retries, and subscription management consistent with the Payment Authorization and signed documents.
6.5 Customer duty to maintain payment method. Customer must maintain a valid Payment Method and accurate billing information during the subscription term and while any payment, refund, dispute, chargeback, settlement, transfer, or default issue remains open.
6.6 Processor alignment. Stripe checkout, subscriptions, invoices, customer portal settings, refunds, disputes, chargebacks, tax settings if used, and payment-method storage must align with the Order Form, these Terms, the Payment Authorization, the Default / Nonpayment Terms, tax/accounting records, and payment records.
6.7 Processor is not the legal, tax, or accounting source. Stripe or another processor may process payments and generate operational records, but processor settings, labels, invoices, emails, portal buttons, or payment screens do not replace the signed payment terms or decide legal, tax, or accounting treatment.
7. Launch, Approval, And Recurring Billing Trigger
7.1 Launch record required. Sites must not start Recurring Billing until a Launch record and Approval record exist.
7.2 Approval evidence. Approval must be recorded by customer-visible signed launch approval, dashboard approval, email approval, project-management approval, payment/launch confirmation, or another written approval record that identifies the authorized customer approver, timestamp, channel, approved launch scope, known deferred items, recurring-billing trigger, next expected charge date, and record owner.
7.3 Launch-ready conditions. Launch and Approval require a record showing:
the site is published or live on the customer domain or approved destination;
core launch scope is complete;
required content and access dependencies are resolved or deferred by approved record;
required migration and redirect decisions are recorded if migration applies;
required customer approvals are received or documented;
required payment setup and recurring-billing trigger records are complete or approved to proceed.
7.4 Customer delay. Customer-side delay in content, access, approvals, domain/DNS readiness, feedback, platform access, migration inputs, or launch readiness pauses or extends affected launch targets, migration timelines, support targets, Move-in Complete timing, and related service expectations. Customer-side delay does not automatically make the Signup Payment refundable.
7.5 Customer abandonment or indefinite non-response. If Customer does not provide required content, approvals, access, domain/DNS readiness, migration inputs, or launch decisions after recorded follow-up, Sites must classify the status before taking payment, default, refund/credit, launch, or transfer action. The record must identify follow-up attempts, missing dependency, last customer response, work performed, capacity reserved, payment status, proposed next step, and refund/credit status.
7.6 Sites delay. If Sites delays Launch for reasons within Sites' control, Sites must record the cause, affected timeline, proposed remedy, customer communication, and payment effect. Possible responses may include timeline adjustment, service credit, first recurring cycle adjustment, or another bounded make-good recorded in writing.
7.7 Term-start record. The Term Start must be recorded with the Launch date, Approval date, customer account reference, Order Form reference, subscription or billing reference if applicable, and recurring-billing start status.
8. Taxes, Fees, And State Tracking
8.1 Tax tracking from day one. Sites must capture customer legal name, billing address, primary business address, customer state, service location, business-use confirmation, selected plan, invoice category, service category, tax status, and exemption/resale documentation if accepted.
8.2 Tax treatment not decided by these Terms. These Terms do not determine whether a transaction is taxable, exempt, subject to sales/use tax, subject to digital-services tax, subject to SaaS-like treatment, or subject to registration in any state.
8.3 Stripe Tax if used. Stripe Tax or any processor tax tool may support calculation and collection only if configured for the applicable transaction. It is not a taxability decision, tax registration decision, accounting conclusion, or legal conclusion.
8.4 Tax amounts. If taxes are charged, the invoice or payment record must identify the tax category, customer-location basis, exemption status if any, and tax calculation basis if any.
8.5 Exemption records. If Sites accepts an exemption certificate, resale certificate, or similar tax document, the record must identify the document, customer, state, effective date, expiration if any, transaction category, and acceptance status.
8.6 State-specific taxability caution. Sites must not assume that website development, managed website service, hosting, dashboard access, migration, analytics, reporting, extra hours, or add-ons receive the same tax treatment in every state. Each plan and charge category may require separate tax classification and payment tax setup if tax automation is used.
8.7 Collected-tax handling. Any tax amount collected through Stripe, invoice, or another processor must be traceable to customer location, transaction category, registration/tax status, invoice or receipt reference, remittance workflow, refund/credit status, and payment record.
8.8 Tax collection and refund fields. If tax is collected, refunded, credited, adjusted, or reversed, the payment/tax record must capture tax amount collected, tax amount refunded or credited, jurisdiction or location code if used, registration status at charge, filing period if applicable, remittance status if applicable, refund tax reversal status, and exemption status.
9. Invoices, Receipts, And Payment Records
9.1 Required payment records. Sites must maintain records for:
Signup Payment;
Recurring Billing;
Approved Add-ons;
Extra Managed Time;
Extra Growth Time;
migration-related charges;
Exception Path work;
taxes if applicable;
refunds;
credits;
disputes;
chargebacks;
settlements;
write-offs;
failed-payment retry events;
service pause/suspension events;
ownership-transfer eligibility events.
9.2 Record categories. Payment records may include Customer identity, business-use confirmation, customer location, selected plan, Order Form, invoice and receipt information, payment authorization, payment method status, service period, Signup Payment, Launch Approval, Recurring Billing, taxes if applicable, refunds, credits, disputes, chargebacks, failed-payment events, default status, and ownership-transfer-related account standing.
9.3 Accounting categories. Payment records must separate at least the following categories:
Signup Payment;
recurring plan billing;
recurring add-ons;
hourly add-ons;
migration/scoped work;
tax if applicable;
refunds;
credits;
disputes;
chargebacks;
settlements;
approved adjustments;
ownership-transfer events.
9.4 Record conflicts. If payment processor records and Sites records conflict, Sites must preserve both records, identify the conflict, and resolve it before making customer-service, default, ownership-transfer, tax, or accounting decisions.
9.5 Tax and accounting neutrality. These Terms require payment categories and records, but they do not decide taxability, tax income inclusion, book accounting treatment, settlement accounting, bad-debt treatment, or allocation among plan, add-on, migration, tax, and transfer events.
10. Refunds, Credits, And Signup Payment Review
10.1 Default posture. The Signup Payment is not refundable by default after Sites reserves production capacity or begins onboarding, review, planning, project setup, platform setup, production scheduling, or production work, subject to the exception-review process in this Section. This is an operational rationale for first-month treatment, not a separate setup fee or additional setup charge.
10.2 No absolute nonrefund rule. Sites must not treat the Signup Payment as nonrefundable without exception. Refund or credit review must exist for the categories listed in this Section.
10.3 Required exception review. Sites must review refund or credit treatment if:
Sites rejects the customer during intake;
Sites cannot serve the customer because of excluded use, platform constraint, regulated-use issue, legal-sensitive workflow, operational fit, or state/customer-location issue;
Sites materially fails before meaningful work or capacity reservation begins;
the charge is duplicate, mistaken, unauthorized, fraudulent, or processor-confirmed as erroneous;
refund, reversal, or credit is required by applicable law;
a payment processor, card network, bank, or dispute process requires action;
Sites approves a customer-service accommodation, settlement, credit, or written exception.
10.4 Stage review for pre-Launch cancellation. If Customer requests cancellation before Launch, Sites must record:
signup date;
Signup Payment amount;
intake status;
whether Sites accepted or rejected the customer;
capacity reserved;
onboarding started;
planning started;
project setup started;
production work started;
dated capacity/work-start record;
stage category;
objective evidence of work, scheduling, platform setup, review, or capacity reservation;
nonrecoverable-cost rationale if used;
customer content/access/approval status;
customer delay status;
Sites delay status;
payment status;
exception category if any;
proposed refund, credit, settlement, or no-credit outcome;
approval owner and date.
10.5 Rejection or inability-to-serve presumption. If Sites rejects the customer, cannot serve the customer, or determines the customer is outside launch scope before meaningful work or documented capacity reservation begins, the refund/credit review should first evaluate refund or credit treatment rather than defaulting to no-credit treatment.
10.6 Objective evidence requirement. A capacity-reservation, work-start, planning-start, platform-setup, or production-scheduling rationale must be supported by dated objective evidence before it is used to support a no-credit, partial-credit, settlement, default, or ownership-transfer position.
10.7 Duplicate, mistaken, unauthorized, or processor-error hold. If Customer plausibly reports a duplicate charge, mistaken charge, unauthorized charge, processor-confirmed error, or payment-method misuse, Sites must place default, suspension, ownership-transfer block, collections, and post-cancellation charge action on hold for the disputed amount until the payment process identifies the issue as resolved, unpaid, fraudulent, abusive, or otherwise default-triggering under the signed documents.
10.8 Refund method. Refunds must be issued through the original processor/payment method when feasible and properly recorded. Credits, settlements, or manual accommodations must be documented separately from processor refund mechanics.
10.9 Credits and make-goods. Service credits, first recurring cycle adjustments, partial credits, or other make-goods must be bounded, recorded, and tied to a reason code. Credits do not modify the term, ownership transfer, or payment obligations unless the written credit record expressly says so.
11. Cancellation Requests
11.1 Cancellation before Launch. A pre-Launch cancellation request triggers the stage review and exception-review process in Section 10. It does not automatically create a refund or credit.
11.2 Cancellation after Launch. A post-Launch cancellation request during the 24-month managed-service commitment does not automatically end payment obligations, default obligations, ownership-transfer conditions, or Account Standing requirements. It must first be routed to Cancellation Resolution Review. Default review applies only if nonpayment, breach, unpaid balance, settlement, remedy analysis, suspension, collections, write-off, or ownership-transfer withholding is actually implicated.
11.3 Cancellation record. Cancellation records must identify:
request date;
requester;
reason;
customer status;
Launch Approval status;
Term Start date if any;
payment status;
unpaid invoices;
refund/credit request;
service pause/suspension status;
ownership-transfer request if any;
manual resolution decision.
11.4 Portal limitation. Customer portal cancellation, downgrade, refund, payment-plan, or term-change features must be disabled or restricted unless the portal workflow matches the signed documents and the service-record workflow.
11.5 Cancellation request intake. A portal, dashboard, support, or billing workflow may allow clear cancellation-request intake, acknowledgement, and status tracking if it does not create unilateral term-shortening, automatic refund/credit approval, payment waiver, transfer right, or default-resolution outcome.
11.6 No self-service override. Customer use of a payment portal, invoice email, card dispute, dashboard request, support request, or Help Center workflow does not by itself amend the Order Form, shorten the 24-month term, waive amounts due, approve refund/credit treatment, or trigger ownership transfer.
11.7 Cancellation friction control. Cancellation intake must be recorded, routed, and acknowledged without misleading Customer about the status of the request. A retention discussion, support ticket, billing review, or default review must not be used to obscure whether the request was received, what review path applies, or what payment/default/ownership-transfer issues remain open.
11.8 Post-cancellation charge control. After a cancellation request or resolution record, any later charge must be tied to an authorized category, invoice, default-resolution record, settlement record, approved recurring obligation, or other signed-document basis. Sites must preserve evidence that the charge was not accidental, duplicate, unauthorized, or processor-only.
11.9 Post-cancellation automatic-billing review. A cancellation request, portal cancellation event, support cancellation request, billing email, card-network inquiry, or dashboard cancellation request must trigger review of automatic billing status. Future automatic recurring charges must be placed on hold, converted to manual invoice/resolution review, or otherwise handled under the signed cancellation/default workflow unless an approved process permits continued automatic charges for the exact situation.
12. Failed Payments, Retry, Dunning, And Cure
12.1 Failed Payment record. Each Failed Payment must create or update a Sites payment-status record.
12.2 Payment rail and stage classification. Payment failures must be classified by stage and payment rail before service impact, default, retry, or customer notice decisions. Required categories include signup authorization failure, Signup Payment capture failure, saved-payment-method failure, card decline, ACH/bank return, wallet failure, expired payment method, customer authorization revocation, processor-required authentication, processor risk hold, manual invoice nonpayment, and post-cancellation attempted charge.
12.3 Retry/dunning. Sites may use Stripe or another approved processor's retry, invoice-reminder, and dunning workflows. Exact retry timing must match the applicable processor settings and customer notice process.
12.4 Notice. Sites must send or record payment notice after a Failed Payment unless fraud, security risk, chargeback, or processor rules require different action. Payment notices should identify the invoice or payment event, the amount, payment category, cure path, service impact risk, and support contact or billing-contact route.
12.5 Cure Period. Sites must provide a Cure Period before ordinary service impact unless documented fraud, security risk, excluded-use activity, unauthorized access, chargeback abuse, platform-risk conditions, or similar urgent issues require faster action. The Cure Period must match the Order Form, Default / Nonpayment Terms, payment notice, and any processor retry/dunning settings that affect customer notice or service status.
12.6 Service impact. If payment remains unresolved, Sites may pause non-critical work, support, updates, dashboard access, Managed Time, Growth Time, migration work not needed to preserve data, add-ons, or other services under the Default / Nonpayment Terms.
12.7 Suspension. If payment remains unresolved after notice and cure, Sites may suspend services under the Default / Nonpayment Terms.
12.8 Restoration. Restoration must require payment resolution, payment-method update, default-status update, and restoration record.
12.9 Default linkage. Default consequences, settlement, write-off, collections review, termination, and ownership-transfer withholding are governed by the Default / Nonpayment Terms and related records.
12.10 No automatic aggressive remedy. These Terms do not automatically authorize acceleration, remaining-term collection, liquidated damages, attorney-fee recovery, collections placement, or ownership-transfer denial. Those outcomes require the staged review, authority, proportionality, evidence, and approval records described in the Default / Nonpayment Terms.
13. Disputes, Chargebacks, And Reversals
13.1 Customer communication. Customer must promptly notify Sites about billing questions, suspected errors, duplicate charges, unauthorized charges, or refund/credit requests.
13.2 Dispute triage categories. Sites must classify payment issues as billing inquiry, good-faith dispute, processor chargeback, fraud/security issue, platform-risk issue, or actual nonpayment before applying service impact, suspension, default, or ownership-transfer consequences, except where urgent fraud, security, chargeback abuse, unauthorized access, or platform-risk conditions require faster action.
13.3 Dispute record. If a dispute, chargeback, reversal, or processor inquiry occurs, Sites must record:
payment or invoice reference;
customer account reference;
dispute date;
reason code;
evidence submitted;
customer communications;
service status;
refund/credit status;
default status;
outcome;
accounting impact.
13.4 Service impact during dispute. If a dispute or chargeback creates actual unpaid status, unresolved nonpayment, documented fraud concern, security risk, platform risk, documented chargeback abuse, or default condition, Sites may pause or suspend affected services under the Default / Nonpayment Terms while preserving reasonable records and security obligations. A good-faith billing inquiry, plausible duplicate-charge issue, or documented good-faith dispute must be triaged before ordinary service impact unless urgent fraud, security, processor, or platform-risk conditions apply.
13.5 No waiver. Responding to a dispute, providing evidence, issuing a credit, or accepting a settlement does not waive other rights, duties, or ownership-transfer conditions unless the written resolution record says so.
14. Add-Ons, Extra Time, Migration, And Exception Path Billing
14.1 Approval required. Add-ons, Extra Managed Time, Extra Growth Time, Migration Expansion, Migration Plan, Complex Migration, custom work, and Exception Path work require approval before charge unless the Order Form or signed scope already authorizes the charge category and amount.
14.2 Recurring add-ons. Recurring add-ons must identify price, billing interval, start date, relation to the main plan term, cancellation treatment, downgrade treatment, tax handling if applicable, and whether they are coterminous with the main 24-month commitment.
14.3 Hourly add-ons. Hourly add-ons must identify rate, approval record, time category, work request, time entry, invoice category, and tax handling if applicable.
14.4 Migration and scoped work. Migration Expansion, Migration Plan, Complex Migration, photography/video, brand identity work, custom applications, custom workflows, and other scoped work must identify scope, price, payment timing, approval record, delivery dependency, and refund/credit treatment.
14.5 Exception Path charges. Exception Path charges must not be billed until the scope, price, approver, due date, and payment category are recorded.
14.6 Line-item classification. Add-ons and scoped charges must be classified separately from the base plan where needed for tax, accounting, payment processor setup, service-period tracking, refund/credit review, and dispute evidence. Bundled charges should not hide separately approved migration, content, custom, hourly, tax, or default-resolution amounts where separate tracking is operationally required.
14.7 Bundled charge allocation. If a bundled price, discount, credit, concession, package, or settlement covers more than one category, the record must allocate or flag for allocation the base plan, add-ons, migration/scoped work, custom work, recurring service period, one-time service period, taxable component, non-taxable or exempt component, credit, discount, refund, and revenue category before tax, accounting, refund, default, or invoice decisions are made.
15. Upgrades, Downgrades, Plan Changes, And Adjustments
15.1 Written approval. Upgrades, downgrades, add-on changes, scope changes, billing adjustments, discounts, credits, and plan substitutions require a written approval record.
15.2 Effective date. The approval record must state the effective date, payment impact, term impact, scope impact, add-on impact, tax impact if applicable, and payment item impact if applicable.
15.3 Downgrade limits. A downgrade may reduce future scope, time allowances, integrations, reporting, support channel, migration scope, or add-on access only if the downgrade is recorded and does not conflict with the signed term or unpaid obligations.
15.4 No retroactive change by default. Plan changes must not retroactively alter completed work, consumed time, unpaid invoices, past-due balances, ownership-transfer eligibility, or refund/credit treatment unless the written approval record expressly says so.
16. Customer Portal And Self-Service Controls
16.1 Allowed portal functions. The customer portal may allow payment-method updates, invoice access, receipt access, billing-contact updates, or similar billing-support functions if enabled.
16.2 Restricted portal functions. The customer portal must not allow cancellation, downgrade, refund request approval, payment plan approval, ownership transfer, term shortening, add-on removal, or default resolution unless the portal workflow matches the signed documents and service records.
16.3 Customer-type and location gating. Portal settings must be reviewed against applicable customer-location, customer-type, B2B, consumer, mixed-use, and transaction-type cancellation decisions. If a specific online or simple cancellation path is required for a customer or jurisdiction, portal restrictions must be replaced with an approved process for that customer or transaction type.
16.4 Portal settings check. Portal settings must be checked before first payment and again before Launch to confirm they match the Order Form, Payment Authorization, these Terms, Default / Nonpayment Terms, tax/accounting categories, and customer-support workflow.
17. Customer Payment Responsibilities
Customer is responsible for:
providing accurate billing information;
maintaining a valid Payment Method;
ensuring the signer has authority;
confirming business-use status;
confirming customer state, billing address, and service location;
reviewing invoices and payment notices promptly;
notifying Sites of billing errors or suspected unauthorized charges;
providing exemption/tax documents if applicable and accepted;
keeping billing contact information current;
resolving Failed Payments within the Cure Period;
preserving payment and approval records needed for Launch, billing, default, and ownership-transfer review.
18. Sites Payment Records And Responsibilities
Sites must maintain service records that:
identify each payment category accurately;
maintain customer and payment records;
record Launch and Approval before Recurring Billing;
maintain refund/credit/dispute reason codes;
maintain failed-payment and cure records;
maintain service pause/suspension records;
maintain add-on and Exception Path approval records;
keep payment processor behavior aligned with signed documents;
escalate tax, privacy, legal, default, and customer-location issues when needed.
Sites' payment records must support payment review, refund/credit review, dispute or chargeback review, approved adjustments, exception tracking, and ordinary accounting support.
19. B2B, Customer Location, And Regulated-Use Controls
19.1 Business-use confirmation. Customer must confirm business-use status before the Signup Payment.
19.2 Customer-location capture. Customer state, billing address, primary business address, and service location must be captured before or at signup for legal, tax, payment, and operational review.
19.3 B2B does not eliminate review. B2B status may reduce some customer-protection concerns but does not eliminate subscription, payment, cancellation, tax, advertising, privacy, accessibility, or state-specific review.
19.4 Regulated-use intake. Health, wellness, medspa, dental, medical, legal, accounting, financial, real estate, or other regulated/sensitive customers may require additional intake, claim controls, privacy/security review, or specialist review before acceptance or Launch.
19.5 Location-change duty. Customer-location changes, billing-address changes, service-location changes, business-use changes, or regulated-use changes must be recorded and reviewed for payment, tax, subscription/cancellation, privacy, accessibility, claim, and operational effects before they are used to support billing, launch, default, or transfer decisions.
20. Rejected Payment And Billing Positions
These Terms reject the following positions unless a signed amendment or other approved written record expressly provides otherwise:
statements that Customer owes nothing at signup;
statements that payment is delayed until launch;
standalone wording that recurring billing begins at launch without also explaining the first-month-at-signup rule and Approval trigger;
statements that all work is included without defined limits;
automatic customer self-cancellation that bypasses the signed 24-month commitment, payment obligations, default workflow, or ownership-transfer conditions;
absolute non-refund treatment with no exception-review process;
treating Stripe Tax as a taxability decision;
treating payment processor invoice text as the complete payment disclosure;
treating customer portal settings as a contract amendment.
Related Documents