Payment Authorization

This Payment Authorization is incorporated into the Order Form, Master Services Agreement, Subscription / Payment Terms, Default / Nonpayment Terms, Ownership Transfer Terms, and any signed add-on, amendment, upgrade, downgrade, renewal, settlement, credit, or Exception Path scope between Sites (“Sites”) and the customer identified in the applicable Order Form (“Customer”). It records Customer’s authorization for Sites and its approved payment processor to collect the Signup Payment, save a Payment Method, charge authorized recurring amounts after Launch Approval, charge approved add-ons and scopes, process failed-payment retries, and maintain related payment records.

1. Purpose And Relationship To Other Documents

2.1 Authorization role. This Payment Authorization records Customer’s authorization for Sites and its payment processor to collect the Signup Payment, save a Payment Method, charge authorized recurring amounts after Launch Approval, charge Approved Add-ons and approved scopes, process failed-payment retries, and maintain payment records.

2.2 Incorporated payment terms. This Payment Authorization works together with the Order Form, Subscription / Payment Terms, Default / Nonpayment Terms, Ownership Transfer Terms, and any signed add-on, amendment, upgrade, downgrade, renewal, settlement, credit, or Exception Path scope.

2.3 Order Form controls amounts. The Order Form controls the selected plan, customer-specific monthly price, total amount due at signup, recurring monthly amount, selected add-ons, tax status, launch destination, and customer-specific payment entries.

2.4 Subscription / Payment Terms control payment lifecycle. The Subscription / Payment Terms control payment timing, payment categories, payment records, refund and credit review, cancellation request treatment, portal limits, failed-payment linkage, and payment processor alignment.

2.5 No processor override. Stripe or another payment processor may process payments, save the Payment Method, send invoices or receipts, and maintain payment records. Processor screens, invoices, emails, portal labels, settings, or payment links do not override the signed documents.

2.6 Issue-specific priority. This Payment Authorization controls authorization categories, saved-payment-method consent, and payment-record authorization. The Order Form controls customer-specific amounts and commercial entries. The Subscription / Payment Terms control payment lifecycle, cancellation and refund review, recurring billing trigger, payment processor alignment, and payment records. The Default / Nonpayment Terms control default, cure, service impact, suspension, settlement, write-off, and collections-review workflow. The Ownership Transfer Terms control transfer eligibility and transfer withholding. This Payment Authorization does not decide economics, tax treatment, accounting treatment, cancellation outcome, refund outcome, default consequence, or ownership-transfer outcome by itself.

2. Defined Authorization Terms

3.1 “Authorized Charges” means the payment categories Customer authorizes under this Payment Authorization, the Order Form, Subscription / Payment Terms, and approved scopes.

3.2 “Signup Payment” means the first monthly plan payment collected at signup. It is not a setup fee.

3.3 “Payment Method” means the card, bank account, wallet, or other payment method Customer provides through Stripe or another approved payment processor.

3.4 “Saved Payment Method” means the Payment Method stored by Stripe or another approved payment processor for later Authorized Charges, invoice payments, retries, and subscription management.

3.5 “Recurring Billing” means the ongoing monthly billing cycle for the selected plan after Launch Approval is recorded.

3.6 “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.7 “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 or 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.8 “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.9 “Term Start” means the Launch Approval date unless the Order Form expressly states another term-start rule.

3.10 “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 customer-visible written approval record that identifies the amount or cap, category, timing, payment method to be charged, and required customer confirmation.

3.11 “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 or security risk, chargeback abuse, or another signed-document default trigger.

3.12 “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.13 “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, 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 or credit request, default status, ownership-transfer status, decision owner, customer communication, and outcome.

3.14 “Off-session” means a processor-supported charge attempt using a Saved Payment Method when Customer is not actively completing the payment flow. Off-session processor capability does not itself authorize the charge.

3.15 “Authorization Revocation” means a customer communication, portal action, processor action, card-network action, bank action, or other documented instruction that withdraws, limits, replaces, or questions saved-payment-method authorization or later Off-session use.

3.16 “Customer-visible approval or resolution record” means a signed document, Order Form, amendment, add-on approval, invoice approval, dashboard approval, email approval, settlement record, restoration record, default-resolution record, or other written record visible to Customer that identifies the approver, amount or cap, category, timing, payment method, service period or milestone if applicable, and approval date.

3.17 “Authority Challenge” means a plausible customer communication, processor inquiry, card-network inquiry, bank inquiry, chargeback, reversal, or account event claiming that the signer, billing contact, Payment Method owner, authorized payer, Launch Approval approver, cancellation requester, refund requester, payment-method replacement requester, settlement approver, or transfer requester lacked authority for the affected action.

3.18 “Agency / End-Client Role Matrix” means the Order Form, customer order snapshot, or supporting authority record identifying the named contracting Customer, any agency or representative, any end client or site owner, billing party, Payment Method owner or authorized payer, domain/account/content owner, Launch Approval approver, and cancellation, refund, default-resolution, settlement, transfer, and offboarding requester roles for the transaction.

3. Customer Authorization

4.1 Authorization to charge. Customer authorizes Sites and its payment processor to charge the Payment Method for Authorized Charges under this Payment Authorization and the signed documents.

4.2 Authorization to save Payment Method. Customer authorizes Stripe or another approved payment processor to store the Payment Method as a Saved Payment Method for later Authorized Charges, invoice payments, payment retries, payment-status updates, and subscription management.

4.3 Saved-method consent record. The payment flow or acceptance record should identify the customer-visible consent language, consent timestamp, acceptance method, signer or authorized user, signer authority basis, billing authority basis if different, payment method owner or authorized payer if known, agency/end-client role if applicable, payment method type, processor customer ID if used, processor payment method ID or token reference if used, purpose of storage, Off-session charge categories, Authorization Revocation route, and authentication or mandate status if applicable.

4.4 Off-session charge boundary. A Saved Payment Method must not be charged Off-session unless the charge category, amount or cap, timing, payment method, invoice or approval ID, service period or milestone if applicable, tax status if applicable, and customer authorization basis are recorded. Processor ability to charge Off-session does not replace Customer authorization or signed-document limits.

4.5 Payment method type. Card, ACH, bank debit, wallet, and other payment method types may have different authentication, mandate, timing, return, retry, revocation, notice, and dispute behavior. The payment records should identify which payment method types are accepted for the transaction.

4.6 Authorization revocation handling. If Customer revokes, limits, replaces, or disputes saved-payment-method authorization, Sites must record the revocation channel, date, requester, requester role basis, affected Payment Method, affected charge categories, open invoices, scheduled retries, active subscription or invoice settings, automatic Off-session charge status, replacement-method request, customer communication, disputed and undisputed amounts if any, authority challenge status if any, default status, customer-owned access or offboarding issue if any, and cancellation-review outcome. Later Off-session charges using the affected Payment Method must be placed on hold, converted to manual invoice or resolution review, or otherwise handled under the signed payment and default workflow unless the signed documents and payment records support a different result for the specific situation.

4.7 Authorization and records scope. This authorization and the related payment records apply to the customer account, Order Form, plan, approved add-ons, approved scopes, invoices, payment retries, refunds, credits, disputes, chargebacks, settlements, write-offs, and account-standing records connected to the signed documents. Processor and accounting events are not separate charge authorizations unless they create a charge category expressly authorized by the Order Form, Subscription / Payment Terms, or a separate customer-visible approval record.

4.8 Authority to bind Customer. The person accepting or signing this Payment Authorization represents that they have authority to authorize payment on behalf of Customer and to bind Customer to the payment obligations in the signed documents.

4.9 Billing and payment-method authority. Customer must ensure that the signer, billing contact, payment-flow user, and any person providing or replacing a Payment Method have authority to act for Customer for the affected payment action. If the Payment Method is owned or controlled by a person or entity different from Customer, the payment record should identify the payer, payer relationship to Customer, authority basis, and any separate customer-visible authorization or approval record.

4.10 Launch Approval and requester authority. Launch Approval, recurring-billing activation, add-on approvals, payment-method replacement, cancellation, refund, settlement, default-resolution, and ownership-transfer requests should identify the authorized requester or approver, role or authority basis, approval channel, affected amount or action, and customer-visible record.

4.10A Agency / end-client authority. If an agency, reseller, affiliate, franchise, parent/subsidiary, third-party payer, end client, or similar multi-party structure is involved, the payment record should identify the Agency / End-Client Role Matrix, end-client acceptance or agency authority certificate status if applicable, payer role, Payment Method owner role, saved-method and Off-session consent by role, authorized charge categories by role, Launch Approval role, requester authority, disputed and undisputed amounts if any, and any customer-owned access or offboarding item implicated by the payment action.

4.11 Authority Challenge review. If Customer plausibly raises an Authority Challenge, Sites must route the affected payment, approval, request, or charge to payment review, Cancellation Resolution Review, Good-Faith Dispute Hold, or another applicable review workflow before applying ordinary default, suspension, collections, transfer withholding, or post-cancellation charge action to the disputed amount, unless urgent fraud, security, processor, platform-risk, unauthorized-access, or chargeback-abuse conditions are separately recorded.

4.12 Business-use confirmation. Customer confirms the purchase is for business use and not personal, family, household, or consumer use.

4.13 Business-use and customer-location fallback. Business-use confirmation is an intake control. It does not eliminate federal, state, customer-location, consumer, mixed-use, cancellation, refund, tax, privacy, accessibility, payment, or operating-record review. If consumer, mixed-use, unsupported-state, regulated-use, or location-gating issues appear, payment collection and recurring billing must route to the applicable review workflow.

4. Authorized Charge Categories

Customer authorizes Sites and its payment processor to charge the Payment Method for the following charge categories:

• Signup Payment;

• recurring monthly plan charges after Launch Approval is recorded;

• approved recurring add-ons;

• approved signup add-ons;

• approved and recorded Extra Managed Time;

• approved and recorded Extra Growth Time;

• approved and recorded Migration Expansion;

• approved and recorded Migration Plan if not included in the selected plan;

• approved and recorded Complex Migration;

• approved and recorded photography, video, brand identity, content writing, custom applications, custom workflows, or other separately scoped work;

• approved and recorded Exception Path charges;

• approved and recorded upgrades, plan changes, add-on changes, adjustments, or amendments;

• taxes or processor-supported tax amounts if applicable, configured, and customer-visible;

• approved settlement, restoration, or default-resolution amounts that require a customer payment and have a customer-visible approval or resolution record;

• failed-payment retries and unpaid invoice recovery for previously authorized charge categories, subject to the retry, notice, cure, and dispute-triage workflow;

• other charges expressly authorized by the Order Form, Subscription / Payment Terms, signed add-on scope, invoice approval, settlement record, or written payment record.

Separate from charge authorization, Sites and its payment processor may create records for permitted refunds, credits, reversals, adjustments, disputes, chargebacks, settlements, write-offs, and related payment events when those actions are permitted by the signed documents, processor rules, or an approved payment record. These processor and accounting actions are not separate customer charge categories unless they create an expressly authorized amount due from Customer.

Each non-plan charge not already fixed in the Order Form must identify the amount or cap, category, invoice or approval ID, timing, payment method to be charged, service period or milestone if applicable, tax status if applicable, refund or credit treatment if applicable, and separate customer confirmation before Sites charges a Saved Payment Method.

This Payment Authorization does not authorize late fees, interest, attorney fees, collection costs, acceleration, remaining-term amounts, liquidated damages, chargeback penalties, or similar remedies unless separately stated in a signed customer-visible document or resolution record.

5. Signup Payment Authorization

6.1 First month at signup. Customer authorizes Sites and its payment processor to charge the Signup Payment at signup.

6.2 Not a setup fee. The Signup Payment is the first monthly plan payment and is not a setup fee.

6.3 Total due at signup. The amount due at signup is the amount shown in the Order Form, payment flow, invoice, or approved payment record. It may include the Signup Payment, approved signup add-ons, approved one-time or scoped charges due at signup, and taxes if applicable.

6.4 Separate tracking. Customer authorizes Sites to record the Signup Payment separately from Recurring Billing for accounting, payment lifecycle, refund and credit review, launch, customer-service, and account-standing records.

6.5 Refund and credit review. Refund or credit treatment for the Signup Payment is governed by the Subscription / Payment Terms, including the required exception-review process. Authorization to collect the Signup Payment does not by itself decide refund, credit, earned-status, service-period, accounting, default, or ownership-transfer treatment after a pre-Launch cancellation request.

6.6 Refund exception categories. This authorization does not approve absolute nonrefund treatment. Sites rejection, inability to serve, Sites delay, customer abandonment, duplicate or mistaken charge, unauthorized charge, processor error, chargeback, tax reversal, and approved customer-service accommodation require the Subscription / Payment Terms exception-review record before refund, credit, settlement, no-credit, default, tax, or accounting treatment is decided.

6.7 Signup Payment record. The payment record should identify the Signup Payment amount, approved signup add-ons if any, tax amount if any, total due at signup, Signup Payment treatment, service period if applicable, first post-Launch invoice trigger, first post-Launch invoice term-month number if applicable, no-duplicate-period check, and cancellation or default economic cross-reference.

6. Recurring Billing Authorization

7.1 Recurring Billing trigger. Customer authorizes Recurring Billing only after Launch Approval is recorded.

7.2 Monthly recurring charges. After Launch Approval is recorded, Customer authorizes Sites and its payment processor to charge the Payment Method for the recurring monthly amount shown in the Order Form, invoice, approved add-on record, or approved adjustment record.

7.3 Term connection. The standard structure uses a 24-month managed-service commitment beginning at Launch Approval unless the Order Form states another term-start rule. The Order Form and payment records should identify the Term Start, Signup Payment treatment, number of post-Launch recurring payments, total plan payments, first recurring service period, and whether the Signup Payment is term month 1, a pre-launch service-period payment, a credit, or another stated treatment.

7.4 No early recurring activation. Sites must not start Recurring Billing before Launch Approval is recorded. A launch target, delayed launch, customer event date, or launch-delay dispute does not authorize early Recurring Billing without the Launch Approval and payment records required by the signed documents.

7.5 Subscription records. Sites may create or activate processor subscription records, invoice records, and payment schedules only when consistent with the Launch Approval record, Order Form, Subscription / Payment Terms, Payment Authorization, and payment records.

7.6 No duplicate period. Sites must not use this authorization to charge the Signup Payment and first post-Launch recurring invoice for the same service period unless the record identifies a separate service period or performance obligation, a customer-visible payment approval record, invoice or service-period evidence, and the reason the charge is not an accidental duplicate.

7.7 First recurring invoice controls. Before the first post-Launch recurring charge, the payment record should identify subscription creation timing if applicable, collection method, billing cycle anchor if applicable, first invoice expected status, customer action path if authentication is required, invoice service period, term-month number, no-duplicate-period status, and next expected charge date.

7.8 Launch-delay payment review. If Customer disputes a charge, invoice, first recurring billing event, or payment status based on a missed launch target, delayed Launch, missed customer event window, or Sites-side delay allegation, Sites should route the affected payment item to the Subscription / Payment Terms review workflow before treating the disputed amount as an ordinary failed payment, default, collection, suspension, or transfer-hold matter.

7. Add-On, Extra Time, Migration, And Exception Path Authorization

8.1 Approval condition. Customer authorizes charges for add-ons, extra time, migration extensions, scoped work, and Exception Path work only if the charge is approved and recorded.

8.2 Approval records. Approval may be recorded in the Order Form, signed add-on scope, signed amendment, dashboard workflow, email approval, invoice approval, project-management approval, or another customer-visible written approval record that identifies the authorized approver, timestamp, approval channel, amount or cap, category, timing, payment method to be charged, service period or milestone if applicable, and tax status if applicable.

8.3 Required charge records. Each add-on or scoped charge should identify the scope, price, payment timing, approval record, service category, invoice category, service period or milestone, tax status if applicable, payment processor product or price reference if applicable, accounting category, and refund or credit treatment reference if applicable.

8.4 No implied expansion. A payment authorization for an add-on or scoped charge does not expand plan scope, time allowances, migration coverage, support levels, ownership-transfer rights, cancellation rights, or refund or credit treatment unless the written approval record expressly says so.

8. Taxes, Processor Tax Tools, And State Records

9.1 Customer-location records. Customer authorizes Sites to collect and record Customer’s legal name, billing address, primary business address, customer state, service location, business-use confirmation, selected plan, invoice category, service category, and tax status.

9.2 Tax amounts if applicable. Customer authorizes charges for taxes or processor-supported tax amounts only if the applicable tax workflow has been configured, the processor or invoice configuration matches the applicable records, and the tax amount is customer-visible in the Order Form, invoice, payment flow, or approved payment record. A tax amount appearing in a form, invoice, payment flow, or payment record does not by itself decide tax treatment.

9.3 No tax conclusion. This Payment Authorization does not determine whether a transaction is taxable, exempt, subject to sales or use tax, subject to digital-services tax, subject to SaaS-like treatment, or subject to registration in any state.

9.4 Processor tax tools if used. Stripe Tax or another processor tax tool may support calculation or collection only if configured for the applicable transaction. It is not a taxability decision, tax registration decision, accounting conclusion, or legal conclusion.

9.5 Exemption documents. If Customer provides an exemption certificate, resale certificate, or similar tax document, Customer authorizes Sites to record and review that document for the applicable customer, state, transaction category, and review outcome.

9.6 Tax collection records. If tax is collected, refunded, credited, adjusted, or reversed, Customer authorizes Sites to maintain records showing 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. Failed Payments, Retries, Dunning, And Default Linkage

10.1 Failed Payment authorization. If a payment fails, Customer authorizes Sites and its payment processor to retry the Payment Method, request a new Payment Method, send or record payment notices, and update Customer’s account status.

10.2 Retry and dunning workflow. Customer authorizes Stripe or another approved processor to use retry, invoice-reminder, and dunning workflows consistent with the Subscription / Payment Terms, Default / Nonpayment Terms, and applicable payment records.

10.3 Payment notice and cure. Failed Payments may trigger payment notices, a Cure Period, service pause, suspension, restoration requirements, default review, settlement, write-off, or other resolution under the Default / Nonpayment Terms. Notices should identify the invoice or payment event, amount, payment category, cure path, service impact risk, and support or billing-contact route.

10.4 Service impact. If payment remains unresolved after required triage, notice, and cure, Sites may pause or suspend 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. Urgent fraud, security, processor, chargeback abuse, unauthorized access, or platform-risk issues may require faster action.

10.5 Restoration. Restoration after a Failed Payment requires payment resolution, Payment Method update if needed, default-status update, and internal restoration record.

10.6 No automatic aggressive remedy. This authorization does 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.

10. Disputes, Chargebacks, Refunds, Credits, And Reversals

11.1 Billing questions. Customer must promptly notify Sites about billing questions, suspected errors, duplicate charges, unauthorized charges, authority concerns, payment-method misuse, refund or credit requests, disputes, chargebacks, or reversals.

11.2 Refunds and credits. Refunds, credits, adjustments, settlements, and make-goods are governed by the Subscription / Payment Terms and must be recorded with reason codes and approval records.

11.3 Dispute records. Customer authorizes Sites to maintain records for disputes, chargebacks, reversals, processor inquiries, Authority Challenges, support-related payment disputes, evidence submissions, authority-basis records, customer communications, service status, refund or credit status, default status, outcome, and accounting impact.

11.4 Payment status during dispute. Sites must classify payment issues as billing inquiry, good-faith dispute, processor chargeback, Authority Challenge, fraud or security issue, platform-risk issue, or actual nonpayment before applying ordinary service impact, suspension, default, or ownership-transfer consequences. A dispute, chargeback, reversal, Authority Challenge, or processor inquiry may create actual unpaid status, unresolved nonpayment, documented fraud concern, documented security risk, documented platform risk, documented chargeback abuse, or default condition after triage. Sites may pause or suspend affected services under the Default / Nonpayment Terms while preserving reasonable records and security obligations, but a good-faith billing inquiry, plausible duplicate-charge issue, plausible authority challenge, or documented good-faith dispute must be triaged before ordinary service impact unless urgent fraud, security, processor, or platform-risk conditions apply.

11.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.

11.6 Support-linked payment status. A support request, support-response dispute, Priority or severity dispute, escalation dispute, repeated-ticket complaint, or support-credit request does not by itself revoke payment authorization, approve a refund or credit, create a billing hold, waive an invoice, or decide default status. If a support issue is tied to a payment item, Sites should route the affected item to the Subscription / Payment Terms and Default / Nonpayment Terms review workflow before ordinary payment-default treatment is applied to the disputed amount.

11.6A 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 link the payment record to the lead-capture technical evidence record and route the affected item through the Subscription / Payment Terms and Default / Nonpayment Terms review workflow before ordinary payment-default treatment is applied to the disputed amount.

11.7 Credit / cancellation / default resolution record. If a payment issue also involves a credit, make-good, no-credit outcome, settlement, cancellation request, Good-Faith Dispute Hold, manual invoice, corrected notice, default pause or release, transfer effect, or offboarding effect, Sites should link the payment record to the Credit / Cancellation / Default Resolution Record described in the Subscription / Payment Terms. The linked record should identify the affected Payment Method, invoice, charge, subscription, service period, disputed amount, undisputed amount, automatic-billing status, manual-invoice status, payment action reference, customer-visible notice version, no-waiver status, default effect, transfer effect, and tax/accounting review status.

11.7A Source-of-truth and preservation record. If a payment issue also involves conflicting processor records, internal summaries, screenshots, support notes, native exports, corrected notices, access restriction, transfer hold, offboarding, customer-owned account status, or customer-owned data status, Sites should link the payment record to the Source-of-Truth / Customer-Owned Preservation Record described in the Default / Nonpayment Terms. Processor status, invoice labels, payment links, portal events, dashboard labels, screenshots, or internal notes do not by themselves decide default, transfer, customer-owned access, or offboarding status unless the signed documents and required records support that result.

11.7B Access/export/token-linked payment status. If a payment issue also involves blocked access, lost access, incomplete export, missing customer-owned data, residual Sites access, failed revocation, failed rotation, failed replacement, failed reconfiguration, credential misuse, token misuse, or incident triage, Sites should link the payment record to the access/export/token incident packet before ordinary payment-default treatment is applied to the disputed amount. Payment authorization, processor status, or invoice status does not by itself decide whether access, export, token remediation, customer-owned preservation, incident notice, transfer, or offboarding treatment is complete.

11.7C Service-impact-linked payment status. If a payment issue also involves 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, Sites should link the payment record to the service impact and event-level causation review record before ordinary payment-default treatment is applied to the disputed amount. Payment authorization, processor status, invoice status, vendor status, screenshot, or support note does not by itself decide causation, credit, make-good, default, transfer, access, export, deletion, or offboarding treatment.

11. Customer Portal And Self-Service Controls

12.1 Allowed portal functions. Customer may use the payment portal for payment-method updates, invoice access, receipt access, billing-contact updates, or similar billing-support functions if enabled.

12.2 Restricted portal functions. Customer portal features 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.

12.3 No portal override. Customer use of the portal, invoice email, payment link, support request, dashboard request, or Help Center workflow does not amend the Order Form, shorten the term, waive amounts due, approve refund or credit treatment, approve plan changes, or trigger ownership transfer.

12.4 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 or credit approval, payment waiver, transfer right, or default-resolution outcome.

12.5 Cancellation-event billing-status review. 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 deletion, pause or collection-setting change, open-invoice retry, post-cancellation attempted charge, or similar cancellation-related communication or processor event must trigger Cancellation Resolution Review. Future automatic recurring charges must be placed on hold, converted to manual invoice or resolution review, or otherwise handled under the signed cancellation and default workflow unless the signed documents and payment records support continued automatic charges for the specific situation.

12. Payment Method Updates And Authorization Revocation

13.1 Payment Method updates. Customer is responsible for keeping a valid Payment Method on file and for updating billing information when the existing Payment Method expires, fails, is revoked, is replaced, or can no longer be used for Authorized Charges.

13.2 Replacement Payment Method. If Customer provides a replacement Payment Method, Customer authorizes Sites and its payment processor to save and use that replacement Payment Method for Authorized Charges under this Payment Authorization and the signed documents.

13.3 Revocation does not waive amounts due. Authorization Revocation does not by itself waive amounts due, cancel the Order Form, shorten the term, approve a refund or credit, create ownership-transfer rights, or resolve open invoices. Revoked or disputed authorization must be handled through the applicable payment, cancellation, dispute, and default workflow.

13.4 Open invoice handling. If Authorization Revocation occurs while invoices, retries, disputes, cancellation requests, or default issues remain open, Sites must record the affected amounts, affected Payment Method, payment status, proposed resolution path, customer communication, and any replacement payment arrangement.

13.5 Post-revocation charge control. Authorization Revocation must trigger review of automatic billing, scheduled retries, collection settings, open invoices, customer portal events, manual processor actions, and any future Off-session charge using the affected Payment Method. Future automatic charges using the affected Payment Method must be placed on hold, converted to manual invoice or resolution review, or handled under an approved exception record unless the signed documents, payment records, and payment-review workflow support a different treatment for the exact situation.

13.6 Disputed and undisputed amount allocation. If Authorization Revocation is connected to a billing dispute, cancellation request, chargeback, processor inquiry, Authority Challenge, or customer claim that a charge was unauthorized, mistaken, or approved by a person without authority, Sites must separate disputed amounts from undisputed amounts before applying ordinary default, service impact, suspension, collections, or ownership-transfer consequences. Each undisputed amount must have its own invoice or payment basis, notice or cure path if required, customer communication, and payment route.

13.7 Replacement method and manual invoice records. If Customer provides a replacement Payment Method or Sites offers a manual invoice path after Authorization Revocation, the record must identify the new authorization or payment basis, affected invoices, service periods, disputed and undisputed status, processor references if used, customer-visible resolution record if any, automatic-billing status, due date or cure path if any, and whether the manual invoice changes any cancellation, credit, waiver, default, or transfer status. A manual invoice path does not by itself restore Off-session authorization for an affected Payment Method or approve default consequences for a disputed amount unless the signed documents and payment-review record support that result.

13. Payment Records And Record Authorization

14.1 Required records. Customer authorizes Sites and its payment processor to create and maintain payment records, processor records, invoice records, subscription records, payment-method records, customer ledger records, and account-standing records.

14.2 Required record fields. Payment and processor records should include, as applicable:

• internal customer ID;

• processor customer ID if used;

• invoice ID if used;

• payment intent ID if used;

• charge ID if used;

• subscription ID if used;

• customer legal or business name;

• signer name, title, email, and 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;

• end-client acceptance or agency authority certificate status if applicable;

• saved-method and Off-session consent by role if applicable;

• Launch Approval role designation for agency/end-client structures 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;

• invoice category;

• accounting category;

• billing phase;

• term month number;

• service period start;

• service period end;

• Payment Authorization version;

• signed 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;

• 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;

• collected-tax reconciliation status if any;

• refund or credit reason code;

• Authority Challenge status if any;

• dispute or chargeback status;

• default status;

• ownership-transfer eligibility status.

14.3 Accounting categories. Payment records must separate Signup Payment, recurring plan billing, recurring add-ons, hourly add-ons, migration and scoped work, tax if applicable, refunds, credits, disputes, chargebacks, settlements, write-offs, and ownership-transfer events.

14.4 Record conflicts. If processor records and service records conflict, Sites must preserve both records, identify the conflict, and resolve it through the payment and accounting review workflow before making customer-service, default, ownership-transfer, tax, or accounting decisions.

14.5 Tax and accounting neutrality. This authorization permits payment processing and records, but it does not decide tax income timing, accounting treatment, settlement treatment, write-off treatment, or allocation among plan, add-on, migration, tax, and transfer events.

14.6 Reconciliation support. Sites’ payment records must support processor-to-bank reconciliation, processor fee tracking, payout records, bank deposit IDs, payment export references, customer ledger tie-out, collected-tax reconciliation if applicable, refund or credit reconciliation, dispute or chargeback reconciliation, write-off records, accounting classification if applicable, exception tracking, and accounting support.

14. Customer Payment Responsibilities

Customer must:

• provide accurate billing information;

• maintain a valid Payment Method;

• ensure the signer has authority to authorize payments;

• ensure the billing contact, payment-flow user, Payment Method owner, authorized payer, and any replacement-method provider have authority for the affected payment action;

• confirm business-use status;

• confirm customer state, billing address, primary business address, and service location;

• review invoices and payment notices promptly;

• promptly notify Sites of billing errors or suspected unauthorized charges;

• promptly notify Sites of any signer, billing, payment-method, payer, requester, or Launch Approval authority concern;

• provide exemption or tax documents if applicable and accepted;

• keep billing contact information current;

• resolve Failed Payments within the Cure Period;

• preserve payment and approval records needed for Launch, billing, default, and ownership-transfer review.

15. Rejected Authorization Positions

This Payment Authorization rejects 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;

• treating the Signup Payment as a setup fee;

• treating a Saved Payment Method as authorization for any charge category, amount, timing, or service period not supported by the signed documents or a customer-visible approval record;

• automatic customer self-cancellation that bypasses the signed term, payment obligations, default workflow, or ownership-transfer conditions;

• absolute nonrefund treatment with no exception-review process;

• treating a processor tax tool as a taxability decision;

• treating payment processor invoice text as the complete payment disclosure;

• treating customer portal settings as a contract amendment.