Legal
Subscription / Payment Terms
These Subscription / Payment Terms are incorporated into the Order Form and Master Services Agreement between Sites (“Sites”) and the customer identified in the applicable Order Form (“Customer”). They 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.
1. Role Of These Terms
2.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.
2.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.
2.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.
2.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.
2.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.
2.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
3.1 “Signup Payment” means the first monthly plan payment collected at signup. It is not a setup fee.
3.2 “Recurring Billing” means the ongoing monthly billing cycle for the selected plan after Launch and Approval evidence is recorded.
3.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.
3.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.
3.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.
3.6 “Term Start” means the Launch Approval date unless the Order Form expressly states another term-start rule.
3.7 “Payment Method” means the card, bank account, wallet, or other payment method provided through Stripe or another approved payment processor.
3.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.
3.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, Authority Challenge, 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.
3.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.
3.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.
3.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, Authorization Revocation, manual processor cancellation, subscription pause or deletion, collection-setting change, post-cancellation attempted charge, or similar cancellation-related communication or processor event. The review record must identify the intake channel, requester, request date, customer status, Launch Approval status, Term Start if any, affected Payment Method if any, payment status, automatic-billing status, open invoices, disputed and undisputed amounts if any, refund/credit request, default status, ownership-transfer status, customer-owned access or offboarding issue if any, customer-visible notice status, decision owner, customer communication, and outcome.
3.13 “Authority Challenge” has the meaning stated in the Payment Authorization and includes a plausible challenge to signer authority, billing authority, payment-method authority, authorized payer authority, Launch Approval authority, or requester authority for the affected payment, approval, cancellation, refund, default-resolution, settlement, or transfer action.
3.13A “Agency / End-Client Role Matrix” has the meaning stated in the Payment Authorization and should identify the named contracting Customer, any agency or representative, any end client or site owner, billing party, Payment Method owner or authorized payer, Launch Approval approver, and cancellation, refund, default-resolution, settlement, transfer, and offboarding requester roles for the transaction.
3.14 “Launch Delay Review” means the review process triggered when Customer plausibly claims a missed launch target, missed customer event window, lost client, lost revenue, billing-trigger issue, Sites-side delay, customer-side delay dispute, or similar launch-timing issue. The review record should identify the launch target basis, target start event, dependency ledger, customer-delay status, Sites-side delay status, third-party or platform-delay status, Launch Approval status, Term Start status, affected invoices or service periods, refund or credit request, default status, and customer-visible communication.
3. Core Payment Structure
4.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.
4.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.
4.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.
4.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. A launch target, delayed launch, or Launch Delay Review does not by itself authorize Recurring Billing before Launch Approval is recorded.
4.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.
4.6 Selected plan price. The monthly plan price is the price listed in the Order Form for Essential, Professional, or Premium.
4.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
5.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.
5.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.
5.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.
5.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
6.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.
6.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.
6.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.
6.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
7.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.
7.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.
7.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.
7.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.
7.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.
7.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.
7.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.8 Authority and payment-method records. Payment records should identify signer identity, signer authority basis, billing authority basis, Payment Method owner or authorized payer if known, payer relationship to Customer if different, Agency / End-Client Role Matrix reference if applicable, saved-method consent record, Off-session authorization basis, processor customer reference if used, processor payment method reference if used, and any Authority Challenge status.
7.9 Different payer or payment-method owner. If the Payment Method or payer is different from Customer, Sites should record the payer name, payer relationship, authority basis, customer-visible authorization record, Agency / End-Client Role Matrix reference if applicable, and affected invoices or charge categories before relying on the Payment Method for later Off-session charges.
7.10 Agency / end-client payment authority. If an agency, end client, third-party payer, domain/account owner, or similar role split is involved, the payment record should identify whether end-client acceptance, agency authority certificate, direct Customer authorization, third-party payer authorization, or manual review is required before payment capture, saved-method setup, Off-session use, Recurring Billing, payment-method replacement, cancellation, refund, default-resolution, settlement, transfer, or offboarding reliance.
7. Launch, Approval, And Recurring Billing Trigger
8.1 Launch record required. Sites must not start Recurring Billing until a Launch record and Approval record exist.
8.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, approver role or authority basis, timestamp, channel, approved launch scope, known deferred items, recurring-billing trigger, next expected charge date, and record owner.
8.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.
8.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.
8.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.
8.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.
8.7 Term-start record. The Term Start must be recorded with the Launch date, Approval date, customer ID, Order Form ID, subscription ID if applicable, Launch Approval authority basis, and recurring-billing start status.
8.8 Launch Approval authority challenge. If Customer plausibly challenges whether the Launch Approval approver had authority, or if the Agency / End-Client Role Matrix does not identify who may approve Launch Approval for the transaction, Sites must route the affected recurring-billing trigger, Term Start, disputed amount, and service status to review before applying ordinary default, suspension, collections, or ownership-transfer consequences for the disputed amount, unless urgent fraud, security, processor, platform-risk, unauthorized-access, or chargeback-abuse conditions are separately recorded.
8. Taxes, Fees, And State Tracking
9.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.
9.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.
9.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.
9.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.
9.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.
9.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-processor tax setup if tax automation is used.
9.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 ID, remittance workflow, refund/credit status, and reconciliation record.
9.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
10.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.
10.2 Required record fields. Payment records should include:
customer ID;
customer legal/business name;
signer name, title, email, and authority basis if applicable;
billing authority basis if applicable;
Payment Method owner or authorized payer if known;
payer relationship to Customer if different;
Agency / End-Client Role Matrix reference if applicable;
end-client acceptance or agency authority certificate status if applicable;
saved-method and Off-session consent by role if applicable;
agency/end-client Launch Approval role designation if applicable;
customer state;
billing address;
service-received location if different;
business-use confirmation;
excluded-use screening status;
regulated-vertical flag if applicable;
selected plan;
Order Form ID;
Stripe customer ID if used;
invoice ID if used;
payment intent ID if used;
charge ID if used;
subscription ID if used;
invoice category;
billing phase;
term month number;
service period start;
service period end;
payment authorization version;
document version reference;
Signup Payment flag;
no-setup-fee flag;
Launch status and date;
Approval status and date;
Launch Approval approver identity, role, and authority basis if applicable;
Recurring Billing start status;
Term Start date;
service period or performance-period reference;
payment processor product, price, tax setting, and subscription identifiers if used;
service category;
add-on category;
tax status;
exemption certificate status if any;
refund/credit reason code;
Authority Challenge status if any;
dispute/chargeback status;
default status;
ownership-transfer eligibility status.
10.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.
10.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.
10.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
11.1 Default posture. The Signup Payment is not refundable by default after Sites has dated objective evidence that it reserved production capacity or began 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.
11.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.
11.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;
Customer plausibly asserts a missed launch target, missed event window, Sites-side delay, or Launch Delay Review issue that affects a refund, credit, first recurring invoice, billing-trigger, default, or settlement position;
Customer plausibly asserts a support-response, Priority, severity, escalation, repeated-ticket, or support-proof issue that affects a refund, credit, make-good, billing, default, transfer, or settlement position;
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.
11.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.
11.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.
11.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. If Sites cannot identify dated objective evidence for the asserted rationale, Sites must decide any refund, credit, settlement, no-credit, default, or ownership-transfer position through the exception-review record rather than relying on that rationale.
11.7 Duplicate, mistaken, unauthorized, authority-challenged, or processor-error hold. If Customer plausibly reports a duplicate charge, mistaken charge, unauthorized charge, Authority Challenge, 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.
11.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.
11.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. A credit or make-good tied to a Launch Delay Review should identify the affected service period or invoice, whether it is a service credit, first-cycle adjustment, refund, settlement, no-credit outcome, or other recorded accommodation, and whether the record includes release, closure, or non-waiver language.
11.10 Support-related credit or billing review. A support ticket, support-response dispute, Priority or severity dispute, escalation dispute, repeated-ticket complaint, or support-credit request does not by itself approve a refund, credit, make-good, billing hold, payment waiver, cancellation, default defense, transfer right, or ownership-transfer outcome. The review record should identify the accepted support-policy version, support window, first-response calculation, ticket source of truth, native ticket export or audit record if available, severity or Priority classification, escalation or no-escalation rationale, closure or reopen status, repeated-issue ledger if any, affected invoice or service period if any, disputed and undisputed amounts if any, customer-visible notice version, and approval owner.
11.10A Access/export/token-related credit or billing review. An access, export, token, credential, customer-owned data, residual-access, revocation, rotation, replacement, reconfiguration, or privacy/security/platform incident dispute does not by itself approve a refund, credit, make-good, billing hold, payment waiver, cancellation, default defense, transfer right, or ownership-transfer outcome. If the issue is tied to a payment, refund, credit, cancellation, default, transfer, or offboarding item, the review record should identify the access/export/token incident packet, affected systems and accounts, export manifest, credential or token remediation record, customer-owned preservation effect, disputed and undisputed amounts if any, customer-visible notice version, and approval owner.
11.10B Service-impact event credit or billing review. An outage, partial outage, failed event, missing submission, missed booking, delayed routing, unavailable surface, vendor limitation, platform limitation, DNS issue, customer-account issue, or mixed-cause service-impact dispute does not by itself approve a refund, credit, make-good, billing hold, payment waiver, cancellation, default defense, transfer right, or ownership-transfer outcome. If the issue is tied to a payment, refund, credit, cancellation, default, transfer, or offboarding item, the review record should identify the service impact and event-level causation review record, affected event window, affected system or surface, vendor or platform status, customer dependency status, Sites-controlled configuration or support status, per-event reconciliation where available, export or missing-item explanation if any, affected invoice or service period, disputed and undisputed amounts if any, customer-visible notice version, and approval owner.
11.11 Credit / cancellation / default resolution record. If the same issue involves a credit, make-good, no-credit outcome, settlement, Cancellation Resolution Review, Good-Faith Dispute Hold, manual invoice, default pause or release, corrected notice, transfer effect, or offboarding effect, Sites should preserve a single resolution record or linked record set. The record should identify the trigger event, affected invoice or service period, affected Payment Method if any, disputed amount, undisputed amount, allocation basis, automatic-billing status, manual-invoice status, requested outcome, approved outcome if any, account-standing effect, default effect, transfer effect, customer-owned access or offboarding effect, release or closure status, no-waiver status, customer-visible notice version, approval owner, payment action reference if any, and tax/accounting review status. A credit, make-good, no-credit outcome, settlement, manual invoice, corrected notice, or hold release does not by itself waive, settle, release, default, transfer, or close any other item unless the customer-visible resolution record states that effect.
11. Cancellation Requests
12.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.
12.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.
12.3 Cancellation record. Cancellation records must identify:
request date;
requester;
requester role or authority basis;
reason;
customer status;
Launch Approval status;
Term Start date if any;
Authorization Revocation status if any;
affected Payment Method if any;
payment status;
automatic-billing status;
unpaid invoices;
disputed amount and undisputed amount if any;
refund/credit request;
service pause/suspension status;
ownership-transfer request if any;
customer-owned account, data, domain, or offboarding issue if any;
customer-visible notice version or correction status if any;
Authority Challenge status if any;
Credit / Cancellation / Default Resolution Record reference if any;
Good-Faith Dispute Hold release criteria and owner if any;
manual resolution decision.
12.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 records workflow.
12.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.
12.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.
12.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.
12.8 Post-cancellation charge control. After a cancellation request, Authorization Revocation, Authority Challenge, 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, authority-challenged without review, processor-only, or applied to the wrong service period. The record should identify the affected Payment Method, charge amount, service period, authorization basis, requester or approver authority basis if applicable, disputed or undisputed status, customer-visible notice, and payment path.
12.9 Post-cancellation automatic-billing review. A cancellation request, portal cancellation event, support cancellation request, billing email, card-network inquiry, dashboard cancellation request, Authorization Revocation, manual processor cancellation, subscription pause or deletion, collection-setting change, open-invoice retry, or post-cancellation attempted charge must trigger review of automatic billing status. Future automatic recurring charges using the affected Payment Method must be placed on hold, converted to manual invoice or resolution review, or otherwise handled under the signed cancellation/default workflow unless an approved process permits continued automatic charges for the exact situation.
12.10 Disputed and undisputed amount handling after cancellation. Cancellation Resolution Review must separate disputed amounts from undisputed amounts before Sites applies ordinary default, service impact, suspension, collections, or ownership-transfer consequences. A disputed amount, including an amount tied to a plausible Authority Challenge, should remain in Good-Faith Dispute Hold or another applicable review status unless the review record identifies unpaid status, fraud or security risk, chargeback abuse, processor risk, platform risk, or another signed-document basis for escalation. Any undisputed unpaid amount must have its own notice, cure path, payment path, service-impact path, and customer communication before ordinary default consequences are applied to that amount.
12.10A Agency / end-client dispute handling. If cancellation, refund, payment-method replacement, default-resolution, settlement, transfer, or offboarding is requested or disputed by an agency, end client, third-party payer, domain/account owner, or other non-identical role, the review should identify the named contracting Customer, requester identity, requester role, authority basis, affected invoices or service periods, disputed and undisputed amounts, customer-owned access/offboarding carveout, and any end-client acceptance or agency authority certificate before applying ordinary default, collection, transfer-hold, post-cancellation charge, or offboarding consequences to the disputed item.
12.10B Manual invoice clarity after cancellation or dispute. A manual invoice, payment link, or invoice email after a cancellation request, Authorization Revocation, Good-Faith Dispute Hold, Authority Challenge, or support dispute should identify whether the requested payment is for an undisputed amount, approved settlement amount, approved default-resolution amount, replacement-method arrangement, or continued obligation after Cancellation Resolution Review. The record should identify automatic-billing status, affected invoice or service period, disputed and undisputed amounts, customer-visible notice version, due date or cure path if any, and whether the invoice changes any cancellation, credit, waiver, default, or transfer status.
12.10C Source-of-truth and preservation review. If a cancellation, Authorization Revocation, payment dispute, manual invoice, billing hold, default notice, transfer hold, or offboarding issue depends on conflicting records, unavailable native exports, processor status, account logs, support notes, or customer-owned account/data status, Sites should identify the source-of-truth record, corrected notice status if any, customer-owned access/offboarding effect, preservation or restoration action if any, and reviewer before applying ordinary payment, default, transfer, or offboarding consequences to the disputed item.
12.10D Access/export/token incident review after cancellation or dispute. If a cancellation, Authorization Revocation, payment dispute, manual invoice, billing hold, default notice, transfer hold, or offboarding issue also involves blocked or lost access, incomplete export, missing customer-owned data, residual access, credential/token failure, failed revocation, failed rotation, failed replacement, failed reconfiguration, or incident triage, Sites should identify the access/export/token incident packet before applying ordinary payment, default, transfer, or offboarding consequences to the disputed item.
12.11 Customer-owned access and offboarding boundary. A cancellation request, Authorization Revocation, payment dispute, or transfer hold does not by itself authorize Sites to block customer-owned domains, customer-owned accounts, customer business data, required billing/default notices, required security/privacy communications, or required offboarding access. Any restriction affecting those items must be supported by the applicable access, security, privacy, default, or offboarding record.
12. Failed Payments, Retry, Dunning, And Cure
13.1 Failed Payment record. Each Failed Payment must create or update a Sites payment-status record.
13.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.
13.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.
13.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.
13.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.
13.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.
13.7 Suspension. If payment remains unresolved after notice and cure, Sites may suspend services under the Default / Nonpayment Terms.
13.8 Restoration. Restoration must require payment resolution, payment-method update, default-status update, and restoration record.
13.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.
13.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
14.1 Customer communication. Customer must promptly notify Sites about billing questions, suspected errors, duplicate charges, unauthorized charges, Authority Challenges, payment-method misuse, or refund/credit requests.
14.2 Dispute triage categories. Sites must classify payment issues as billing inquiry, good-faith dispute, Authority Challenge, 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.
14.3 Dispute record. If a dispute, chargeback, reversal, or processor inquiry occurs, Sites must record:
payment ID;
invoice ID;
customer ID;
dispute date;
reason code;
authority challenge type if any;
signer, billing, payment-method, payer, Launch Approval, or requester authority record if implicated;
lead-capture technical evidence record if the dispute involves a form, booking flow, CRM connection, webhook, script, notification, inbox, or lead-routing issue;
evidence submitted;
customer communications;
service status;
refund/credit status;
default status;
outcome;
accounting impact.
14.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.
14.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.6 Resolution record controls. If Customer disputes whether a credit, make-good, no-credit decision, settlement, hold, manual invoice, default notice, corrected notice, or payment response waived an obligation or closed an issue, the applicable customer-visible resolution record controls the stated effect. If no such record states the effect, the item remains limited to the recorded payment, service period, invoice, dispute, or accommodation identified in the records and does not automatically amend the Order Form, shorten the term, waive payment, approve cancellation, create Account Standing, or trigger ownership transfer.
14.7 Lead-capture-linked payment status. A lead-capture complaint, failed form test, missing submission allegation, booking issue, CRM or webhook routing issue, notification or inbox delivery issue, script issue, or alleged lost-lead issue does not by itself revoke payment authorization, approve a refund or credit, create a billing hold, waive an invoice, shorten the term, create Account Standing, or decide default status. If a lead-capture issue is tied to a payment item, Sites should route the affected item to the lead-capture technical evidence record, Subscription / Payment Terms review workflow, Default / Nonpayment Terms workflow, and Credit / Cancellation / Default Resolution Record before ordinary payment-default treatment is applied to the disputed amount.
14. Add-Ons, Extra Time, Migration, And Exception Path Billing
15.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.
15.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.
15.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.
15.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.
15.5 Exception Path charges. Exception Path charges must not be billed until the scope, price, approver, due date, and payment category are recorded.
15.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.
15.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
16.1 Written approval. Upgrades, downgrades, add-on changes, scope changes, billing adjustments, discounts, credits, and plan substitutions require a written approval record.
16.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.
16.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.
16.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
17.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.
17.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.
17.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.
17.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;
ensuring the billing contact, payment-flow user, Payment Method owner, authorized payer, Launch Approval approver, and requesters for payment-related actions have authority for the affected action;
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;
notifying Sites of any signer, billing, payment-method, payer, requester, or Launch Approval authority concern;
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;
record signer, billing, payment-method, authorized payer, requester, and Launch Approval authority where relevant;
maintain refund/credit/dispute reason codes;
maintain failed-payment and cure records;
maintain service pause/suspension records;
maintain lead-capture technical evidence records where a payment, refund, credit, default, transfer, access, or offboarding issue is tied to a form, booking flow, CRM connection, webhook, script, notification, inbox, or lead-routing issue;
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 processor-to-bank reconciliation, processor fee tracking, payout records, bank deposit IDs, payment reporting references, customer ledger tie-out, collected-tax reconciliation if applicable, refund/credit reconciliation, dispute/chargeback reconciliation, approved adjustment records, exception tracking, and ordinary accounting support.
19. B2B, Customer Location, And Regulated-Use Controls
20.1 Business-use confirmation. Customer must confirm business-use status before the Signup Payment.
20.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.
20.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.
20.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.
20.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 nonrefund 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