Legal
Partner Terms
Version 1.0 · White-Label Payroll Deduction Donation Service · Effective 26 August 2026 · Incorporated by reference into each Partnership Order, together with Schedules A–C below (commercial terms sit in each Order and stay confidential).
These Partner Terms are incorporated into the Order signed by Roster Giving Inc. (“Roster”) and the partner identified in it (“Partner”). Each is a “Party”. Capitalized terms used and not defined here have the meaning given in the Order.
1. Definitions
1.1 “Roster Service” or “Service” means Roster’s payroll deduction donation program, including Donor enrollment flows, the API, and the configuration of settlement and fee allocation with the Banking Provider.
1.2 “Banking Provider” means the regulated financial institution through which for-benefit-of (“FBO”) accounts are maintained and Donations settle. Roster may change the Banking Provider at any time, provided the flow in Section 3 continues and Roster gives at least sixty (60) days’ notice of any change requiring Partner to modify its integration, with migration support under Schedule B.
1.3 “Church”, “Donor”, “Donation”, “Settled Donation”, “Deposit Split”, “White-Label Flow” and “API” have the meanings given in the Order. “Donation Volume” means the aggregate gross amount of Donations in a period.
1.4 “Donor Data” means personal information of Donors exchanged between the Parties, including name, contact details, employer and Donation amounts.
1.5 “Church Data” means the information Partner delivers about a Church under Schedule A.
2. Scope
2.1 Roster appoints Partner as a non-exclusive distributor of the Service, solely to Churches and solely through the Partner Platform. Partner shall integrate the API per Roster’s documentation and present the functionality as native functionality of the Partner Platform.
2.2 Roster is responsible for Donor enrollment, configuration of the settlement and fee split with the Banking Provider, and Donor-side compliance under Section 7. Partner is responsible for the commercial relationship with Churches, pricing communication, first-line support to Churches, and Church data submission under Schedule A. Roster provides first-line support to Donors — enrollment, payroll connection, changes, cancellation and deduction issues — through the White-Label Flow under Partner’s brand, and technical support to Partner under Schedule B. Each Party refers to the other any matter outside its scope.
2.3 The Parties are independent contractors. Neither may bind the other. Churches and Donors are not third-party beneficiaries.
3. Funds Flow; No Custody
3.1 Payroll splits are executed at the Donor’s employer payroll per the Donor’s instructions. Donation funds flow directly to FBO accounts at the Banking Provider and are disbursed by it to the Church designated by the Donor.
3.2At no time does Roster or Partner receive, hold, take possession of, or exercise control over Donation funds. Neither Party shall represent otherwise to any Church, Donor or third party.
3.3 Fees become the revenue of the receiving Party only once disbursed to that Party’s operating account under Section 4.
4. Fees and Settlement
4.1 The Roster Fee. The Roster Fee is the percentage of each Settled Donation set out in the Order, retained in full by Roster and not shared with Partner. No setup, license, subscription or minimum fees apply unless separately agreed in writing.
4.2 Collection at source. At each settlement, the Banking Provider simultaneously disburses the net Donation to the Church, the Roster Fee to Roster, and any amount the Church owes Partner under Partner’s own terms with the Church directly to Partner. Neither Party invoices the Church for the Roster Fee; the Deposit Split is the exclusive collection mechanism. The Deposit Split is applied in two layers: the Church’s instruction reflects only its single fee and net settlement; the allocation between Roster and Partner is recorded separately with the Banking Provider and is not disclosed to Churches or Donors by either Party.
4.3 Reversals. Fees accrue only on Settled Donations. If a Donation is returned, reversed or charged back, the corresponding fees are reversed and netted against the next settlement cycle.
4.4 Holds. Disbursement to a Church may be paused where required by the Banking Provider’s compliance rules (for example, enhanced due diligence thresholds or repeated ACH returns). Roster shall notify Partner, and no fee accrues to either Party while funds are held.
4.5 Reporting. Roster shall make a transaction report available to Partner by the fifth (5th) business day of each month, itemized per Church: Donation Volume, number of Donations, fees collected and amounts disbursed. Partner may dispute a report within thirty (30) days; agreed adjustments are applied in the next settlement cycle.
4.6 Standing authorization. The Church’s netting authorization (the single fee and settlement net of that fee) is a standing instruction that remains in effect while the Service is enabled for that Church, and may be revoked only by disabling the Service for that Church. Partner’s terms with Churches shall so provide.
4.7 Tax characterization. The Parties intend that each Donor’s contribution be characterized at its gross amount: the Church’s receipt to the Donor reflects the full Donation, and the fees are an operating expense of the Church, consistent with the treatment of card processing fees today. Any Donation record either Party generates or displays shall state the gross amount, and neither Party shall represent the net amount as the deductible amount. Each Party bears its own taxes and neither provides tax advice to Donors or Churches beyond language approved by both Parties in writing.
4.8 Deduction corrections. If a Donation is deducted in an amount or at a time inconsistent with the Donor’s authorization, Roster shall correct it in the next settlement cycle and, where funds were already disbursed, coordinate the correction with the Church. Fees on the incorrect portion are reversed under Section 4.3.
4.9 Fee adjustment on renewal. Roster may adjust the Roster Fee effective on any renewal term by giving at least sixty (60) days’ written notice before the end of the then-current term. If Partner does not accept the adjusted fee, Partner may elect not to renew by notice within thirty (30) days of Roster’s notice, and this Agreement ends at the close of the then-current term with the wind-down in Section 10.2 applying.
4.10 Notice of fee changes to Churches. Partner shall give Roster at least thirty (30) days’ written notice before any change to the fee it charges Churches for the Service, stating the new percentage (and any per-transaction amount) and the intended effective date. Roster shall reconfigure the Deposit Split with the Banking Provider by that date, subject to the minimum notice period.
5. Integration and Start of Operations
5.1 Roster provides sandbox credentials and integration documentation upon execution of a mutual non-disclosure agreement, which may occur before the Effective Date. Access to the sandbox before the Effective Date is governed by the Sandbox Access Terms and conveys no right to enroll Churches or Donors or to process Donations.
5.2 Partner will integrate the API per the documentation and complete Roster’s integration certification before enrolling any Church or Donor in production (the “Go-Live”). Production credentials are released upon certification.
5.3 The service level in Section 6.1 is measured from the Go-Live. For the first ninety (90) days after the Go-Live, the termination right in Section 6.2 does not apply, though Roster shall report actual availability monthly.
6. Roster Service Levels and Obligations
6.1 Roster shall maintain the API with monthly uptime of at least 99.5%, excluding scheduled maintenance announced at least forty-eight (48) hours in advance, force majeure, failures of third-party payroll or financial institutions, and issues caused by Partner.
6.2 If monthly uptime falls below 99% in three (3) consecutive months, Partner may terminate on written notice without the cure period in Section 10.1(a).
6.3 Roster shall provide the API, documentation, sandbox, MCP server and reasonable integration support as described in Schedule C, and shall maintain a designated technical contact for escalations.
6.4 Roster shall give at least thirty (30) days’ notice of API changes requiring Partner to modify its integration, except for emergency security or legal changes, where notice shall be as soon as practicable. Changes that break compatibility with Partner’s integration are subject to the ninety (90) days’ notice and supported migration window set out in Schedule B.
6.5 Roster shall administer the program, including its supplier arrangements, in accordance with its BSA/AML/OFAC compliance program and applicable law.
6.6 Roster shall return Donation-level data to Partner as described in Schedule C, so that a Donor’s full giving history is available inside the Partner Platform.
7. Partner Obligations; Compliance
7.1 Partner shall: (a) integrate the API per Roster’s documentation and complete integration certification before launch; (b) describe the Service accurately and make no representations beyond the documentation or Roster’s written approval — in particular, no representation that either Party holds Donation funds or acts as a financial institution; (c) not modify, reverse engineer, sublicense or resell the Service or API; (d) keep API credentials confidential and notify Roster within twenty-four (24) hours of any suspected compromise; and (e) meet the Partner Deliverables set out in the Order, including display on giving pages and in the app, the rollout period, and delivery of the Church onboarding data and evidence under Schedule A.
7.2 Roster is responsible for sanctions screening of Donors and of Churches, for verification of each Church’s eligibility, and for monitoring of Donation activity, using the data Partner submits under Schedule A and evidence Roster derives from authoritative sources. Partner’s own onboarding of Churches is supplementary risk input and does not substitute Roster’s controls. Partner is responsible for the accuracy of the data it submits and for its lawful collection and sharing. Roster may decline or suspend any Church.
7.3 Partner shall deliver the change events described in Schedule A §3 (identity, account, officers) within twenty-four (24) hours, and shall notify Roster within five (5) business days when a Church leaves the Partner Platform, loses its exempt status, or is suspected of fraud.
7.4 Each Party shall retain auditable records of its activities under this Section for five (5) years and make them available to the other Party or its regulators on reasonable request.
7.5 Each Party shall promptly notify the other of any regulatory inquiry or enforcement action materially relating to the Service, to the extent legally permitted. Roster may suspend any Donation, Donor, Church, or the Service as reasonably necessary to comply with law, sanctions, or a directive of the Banking Provider or a regulator.
7.6 Partner shall ensure that each Church’s use of the Service is subject to terms that incorporate the minimum flow-down provisions reasonably specified by Roster (including any required by the Banking Provider or applicable law), drafted so as to preserve the white-label presentation in Section 9 to the maximum extent permitted by applicable law.
7.7 Registration and disclosures in Partner’s jurisdiction. Partner is responsible for identifying and complying with the registration, licensing and disclosure obligations applicable to its activity and to its principal place of business, including any relating to charitable fundraising. Roster shall cooperate reasonably by providing the information about the Service necessary for that compliance.
8. Data Protection and Security
8.1 Each Party shall process Donor Data and Church Data solely to perform this Agreement and in compliance with applicable law, shall not sell it, use it for advertising or profiling, or use it to train third-party models, and shall store and process it exclusively within the United States.
8.2 Each Party shall notify the other of any confirmed security breach affecting Donor Data without undue delay and within seventy-two (72) hours of confirmation, and shall cooperate in investigation, remediation and any required notifications.
8.3 Each Party shall maintain a written information security program including, at minimum: role-based least-privilege access with multi-factor authentication for administrative and remote access; access revocation within twenty-four (24) hours of personnel departure; TLS 1.2+ in transit and AES-256 (or stronger) at rest; separation of production from non-production environments with no live Donor Data in non-production; centralized logging of access to Donor Data retained at least twelve (12) months; documented vulnerability management; an annual independent penetration test; and a tested incident response plan. PCI DSS applies to each Party to the extent applicable to its scope.
8.4 Once per calendar year, and following any security breach affecting Donor Data, each Party shall evidence compliance with Section 8.3 by providing a current SOC 2 report, an ISO/IEC 27001 certificate, or a completed standard security questionnaire. A Party shall notify the other without undue delay of any lapse, qualified opinion or material control failure, and shall remediate any deficiency within thirty (30) days or per a written plan with interim compensating controls.
8.5 Each Party remains responsible for the subprocessors it uses to handle Donor Data. On termination and after any transition period, each Party shall delete or return the other’s Donor Data within sixty (60) days, excluding records retained under Section 7.4 or applicable law.
8.6 The data each Party sends the other, and what is never sent, are set out in Schedule C. Each Party is an independent controller of the data it collects.
9. Branding
9.1 The Service shall be presented as native functionality of the Partner Platform. Roster’s name, marks and branding shall not appear in any Church-facing or Donor-facing interface, except where identification of Roster or a provider is required by law, by the Banking Provider, or by a regulator in terms, disclosures, notices or receipts. The Parties shall cooperate to draft any such required disclosure so as to minimize its impact on the white-label presentation, and neither Party shall remove, obscure or reword a disclosure that is legally required.
9.2 Neither Party shall use the other’s name, logo or marks in marketing materials, press releases, customer lists or public statements without the other’s prior written consent, except that either Party may identify the other factually as a partner in investor or financing materials shared under confidentiality obligations.
10. Term, Termination and Transition
10.1 The Term is stated in the Order. Either Party may terminate: (a) for material breach uncured within fifteen (15) days of notice; (b) immediately on insolvency or material violation of Section 7; or (c) for convenience on thirty (30) days’ notice. Roster may terminate if a banking or payroll relationship necessary to the structure in Sections 3 and 4 ends and cannot be replaced on commercially reasonable terms, or if performance would violate law or a regulatory directive. Either Party may also terminate upon written notice given within sixty (60) days of a change of control of the other Party (a merger, or a sale of control or of substantially all assets), with the effects of Section 10.2 applying.
10.2 Wind-Down Period. On expiration or termination (other than a termination required by law, by a regulator or by the Banking Provider, where a shorter period may apply), Donations authorized before termination continue to be processed and settled for ninety (90) days, under the fee terms then in force, and Sections 4, 7 and 8 continue to apply to that processing. Partner shall enroll no new Churches or Donors from the termination date. Neither Party shall interrupt a Donor’s giving during the Wind-Down Period, and neither Party shall solicit the other’s Churches or Donors to migrate during the notice period or the Wind-Down Period, other than through the joint notice in Section 10.4.
10.3 After the Wind-Down Period. For each Church, the Parties shall follow that Church’s own instruction: (a) if the Church elects to continue receiving Donations through the Service, whether directly with Roster or through another platform, Roster shall continue to process them, and no further amount accrues to Partner on those Donations; (b) if the Church elects to stop, Roster shall cancel the standing instructions and notify each affected Donor at least thirty (30) days in advance; (c) absent instruction from the Church by the end of the Wind-Down Period, clause (b) applies.
10.4 The Parties shall agree on a joint notice to affected Churches and Donors, sent no later than thirty (30) days into the Wind-Down Period.
10.5 At the end of the Wind-Down Period, Partner shall remove the API integration and cease all use of the API and credentials. All fees accrued through that date are settled through the mechanism in Section 4.2, followed by a final reconciliation under Section 4.5.
10.6 Sections 1, 3.2, 4.3–4.9, 7.4, 8, 10.2–10.5, 11, 12, 13 and 14 survive termination.
11. Intellectual Property
11.1 Each Party retains all right, title and interest in its own technology, platform, marks and intellectual property. No rights are granted except as expressly stated.
11.2 Roster grants Partner a limited, non-exclusive, non-transferable, non-sublicensable, revocable license, during the Term only, to access and use the API and documentation solely to make the Service available within the Partner Platform as contemplated here.
11.3 Partner grants Roster a perpetual, irrevocable, royalty-free license to use any suggestions or feedback regarding the Service, without obligation or attribution.
12. Confidentiality
12.1 “Confidential Information” means non-public information disclosed by a Party that is marked or reasonably understood to be confidential, including the terms of this Agreement, the Roster Fee and the fee allocation, volume projections, the identity of Roster’s suppliers and the architecture connecting them, API credentials and transaction data. It excludes information that is public without breach, already lawfully known, lawfully received from a third party, or independently developed.
12.2 Each Party shall use the other’s Confidential Information solely to perform this Agreement, protect it with at least reasonable care, and disclose it only to personnel and advisors bound by comparable obligations. These obligations apply during the Term and for three (3) years thereafter, and for trade secrets so long as they remain such. Disclosure compelled by law is permitted with prompt notice where legally allowed. Any mutual non-disclosure agreement between the Parties remains in force; where it conflicts, the more protective term governs.
12.3 Architecture. The design of the Service — including the FBO and sub-account structure, the two-layer Deposit Split mechanics, the enrollment and verification patterns, and related know-how — constitutes a trade secret of Roster under applicable law, developed at material expense and maintained under reasonable measures to preserve its secrecy. Partner shall not use it, or knowingly permit its use, to design, build or commission a service that replaces or substitutes for the Service, during the Term and for twelve (12) months after termination. This Section does not restrict Partner from competing generally, nor its use of information that becomes public through no fault of Partner or that is independently developed without reference to Roster’s information.
13. Liability and Indemnification
13.1 NEITHER PARTY IS LIABLE FOR INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL OR PUNITIVE DAMAGES, OR FOR LOST PROFITS, REVENUE OR GOODWILL. EACH PARTY’S AGGREGATE LIABILITY SHALL NOT EXCEED THE TOTAL FEES IT RECEIVED UNDER THIS AGREEMENT IN THE TWELVE (12) MONTHS PRECEDING THE EVENT GIVING RISE TO THE CLAIM.
13.2 Section 13.1 does not apply to breach of Section 12, the indemnities in Section 13.3, gross negligence, fraud or willful misconduct, or Partner’s breach of the license restrictions in Sections 7.1(c) and 11.2.
13.3 Roster shall defend and indemnify Partner against third-party claims that the Service, used as permitted, infringes intellectual property rights, and against claims arising from a security breach of Roster’s systems caused by Roster’s failure to meet Section 8.3. Partner shall defend and indemnify Roster against third-party claims arising from Partner’s representations beyond those permitted under Section 7.1(b), the Partner Platform itself, Partner’s relationship with Churches, the data Partner submitted under Schedule A, the terms Partner issued to Churches, or Partner’s breach of Sections 7.1(c), 7.2 or 11.2. The indemnified Party shall give prompt notice, reasonable cooperation and control of the defense; no settlement imposing obligations on the indemnified Party may be made without its consent, not unreasonably withheld.
13.4 Data-breach cap. Notwithstanding Section 13.2, each Party’s aggregate liability for claims arising from a security breach of its systems shall not exceed one million US dollars (US$1,000,000). This Section does not limit liability for fraud or willful misconduct.
14. General
14.1 Governing law. This Agreement is governed by the laws of the State of Delaware, without regard to conflict of laws rules, and the state and federal courts located in Delaware have exclusive jurisdiction. EACH PARTY WAIVES ANY RIGHT TO A JURY TRIAL.
14.2 Notices. Notices must be in writing, delivered by email with confirmation of receipt and by courier or certified mail, to Roster at 1152 S Van Ness Ave, San Francisco, CA 94110, and by email to rafael@rostergiving.com (Attn: Rafael Rodeiro, CEO; compliance notices copied to security@rostergiving.com) and to Partner at the address in the Order.
14.3 Assignment. Neither Party may assign without the other’s written consent, except to an affiliate or in a merger or sale of substantially all assets, on notice.
14.4 Miscellaneous. Neither Party is liable for delays beyond its reasonable control other than payment obligations. This Agreement, the Order and the Schedules are the entire agreement and supersede prior understandings; amendments must be signed by both Parties. If any provision is unenforceable it shall be narrowed to the minimum extent necessary or severed, and the remainder continues in effect. Waivers must be written. This Agreement may be executed in counterparts, including electronically.
Schedule A — Church Onboarding (Split Intake)
1. Model. Following the terms update in the Order, Partner submits Church data to Roster server-to-server, per the Integration Guide: the existing base in bulk (backfill), no later than the end of the rollout period, and each new Church as it onboards — without waiting for a Church-initiated request. Roster pre-processes each Church (derivations, sanctions screening, and account pre-verification by zero-dollar prenote where possible) so that the only remaining step is the Church’s own confirmation: a short hosted, white-labeled flow (confirmation of entity data, signatory and attestation, account confirmation, consent), presented when the Service is offered to the Church or when its first Donor enrolls, whichever comes first. Disbursement to a Church begins only after its gate is complete. Partner submits identifiers; the Church signs; Roster derives the evidence. Partner does not collect tax-exemption documents, government IDs, SSNs or dates of birth from Churches for the Service.
2. What Partner submits per Church (in bulk for the existing base; on onboarding for new Churches):
| Block | Content | Required |
|---|---|---|
| A — Identity | Legal name, DBA names, EIN, formation state, physical address (no P.O.-box-only), website, denomination / group ruling if known | Yes (website/denomination optional) |
| B — Receiving account | Routing and account number (tokenized by Roster on receipt), name on the account (must be an organization, not an individual), how and when Partner last verified it | Yes; if unavailable, the Church supplies it in the hosted flow |
| C — Operational signals | Date onboarded to Partner, first donation date, volume band, active recurring donors, Partner’s own KYC method, known officers (name + role) | Optional — accelerates processing |
| D — Contact | Name, email, phone and role of a person with authority to sign for the Church | Yes |
3. Ongoing updates (delta feed). Partner notifies Roster of any change to Blocks A, B or C — including officers and the receiving account — within twenty-four (24) hours of the change in Partner’s system, and delivers a monthly full-file reconciliation by the fifth (5th) business day. Three (3) missed events in ninety (90) days give Roster the right to suspend new Church activations for Partner until resolved.
4. Status codes. Roster returns only sanitized statuses (active, pending review, information required, ineligible). Roster does not disclose underlying eligibility or screening reasons, and Partner shall not request them or represent reasons to a Church. This is a regulatory constraint, not a courtesy.
5. No reliance. Partner’s own onboarding of a Church is supplementary risk input; it does not substitute Roster’s controls, and Roster’s decision is final. Roster may decline or suspend any Church.
6. Evidence of the terms update. Partner delivers records sufficient to show, for each Church, (a) which version of Partner’s updated terms the Church accepted and when, and (b) that notice of the update was sent. Records may be in whatever form Partner already maintains, provided they identify the Church, the terms version and the dates.
7. Data handling. Partner represents that it collected the data it submits lawfully and is authorized to share it with Roster (including Church bank account data). Roster tokenizes account numbers on receipt. All data under this Schedule is handled per Section 8 and Schedule C.
Schedule B — Technical Integration, API, MCP and Support
- API. REST endpoints for: church enablement; donor enrollment and payroll connection; donation authorization (percentage per paycheck); schedule changes; cancellation; donation and settlement status; reversals; and webhooks for every state change.
- Documentation and sandbox. Public-style docs, OpenAPI spec, test data, integration examples.
- MCP server. A Model Context Protocol server exposing the state of the Service to Partner’s own agents and tools.
- White-Label Flow. Embeddable button and hosted steps, styleable by Partner. The flow pre-fills the name and phone Partner already captured, so the Donor supplies only date of birth and confirms with two verification codes.
- Large-paycheck rule. When a paycheck is materially above the Donor’s trailing average, the excess is excluded from the Donation unless the Donor opts in.
- Reporting. Donation-level feed into the Partner Platform dashboard, plus the monthly report in Section 4.5.
- Support. Named contacts on both sides and a shared channel. Response targets: P1 (service down) one (1) business hour; P2 (degraded) one (1) business day; P3 two (2) business days.
- Change management. Per Section 6.4; breaking changes with ninety (90) days’ notice and a supported migration window.
Schedule C — Data Sharing
| Direction | Data | Purpose |
|---|---|---|
| Partner → Roster | Church onboarding data per Schedule B, including Church bank account data (tokenized by Roster on receipt); Donor name, phone, email, selected Church, selected percentage | Open and operate the Church and the Donation |
| Roster → Partner | Donation ID, amount, date, status, Church, Donor identifier, change/cancellation and failure events; sanitized Church onboarding statuses | Giving history in the Partner Platform; reconciliation |
| Never to Partner | Payroll credentials, employer, salary, SSN, Donor bank account, identity documents, screening/eligibility reasons | Not needed; increases everyone’s risk |
Each Party is an independent controller of the data it collects. Neither sells the other’s data, uses it for unrelated marketing, or trains third-party models on it. Retention, deletion requests, breach notification (72 hours) and applicable state privacy law are handled under each Party’s own program.