Financial Transparency in Church Giving
How Architecture Can Enforce Accountability in Church Financial Systems
The Bottom Line
Most church giving platforms add undisclosed margins to payment processing, bundle fees into opaque line items, and lock churches into platform-owned Stripe accounts that make switching painful. On $500,000 in annual giving, hidden processing markup alone can cost $3,500/year — money that could fund ministry. Kinship's financial architecture makes this structurally impossible: zero markup on donations, line-item settlement ledgers auditable by the church, and dual-path payment processing that gives churches full control over their Stripe relationship.
What you'll learn in this paper:
- Where margins hide in church giving software — processing fee spreads, Connect application fees, and bundled platform charges
- How the settlement ledger computes a verifiable, line-item breakdown of every financial flow — exportable as CSV, cross-referenceable with Stripe
- Dual-path processing: Connect through Kinship for speed, or bring your own Stripe account for full independence and portability
- Fair-share subscription pricing based on active engagement, not database size — including how tiers adjust downward
Introduction
Every dollar a church spends on software is a dollar that isn't feeding someone, housing someone, or funding ministry. This isn't a metaphor. It's a line item in a budget that a volunteer treasurer reviews, a finance committee approves, and a congregation trusts is being spent wisely.
Church giving is uniquely trust-dependent. When a member tithes, they aren't buying a product. They're expressing faith — in God, in their church's mission, and in the people stewarding those resources. The entire relationship depends on transparency: the congregation trusts the church to handle money honestly, and the church trusts its software vendor to handle money honestly.
The church management software industry has not earned that trust. Most platforms add undisclosed margins to payment processing fees, bundle giving tools into premium tiers, and make it structurally difficult for churches to see exactly what they're paying and why. The financial relationship between the platform and the church is opaque by design.
This paper describes an alternative approach: a financial architecture where transparency isn't a marketing claim but a structural constraint. Where the platform cannot add hidden fees because the settlement system makes every penny visible. Where churches aren't locked into a single payment processor because the architecture supports dual-path processing with provider portability.
The architecture described here is implemented in Kinship. The principles are applicable to any platform that handles money on behalf of mission-driven organizations.
The Problem: Hidden Margins in Church Software
The standard business model for church giving software follows a pattern that is well-understood in fintech but rarely examined in the church context:
The Processing Fee Markup
Stripe's published rate for card processing is 2.9% + $0.30 per transaction. Many church platforms charge 2.9% + $0.30 or slightly more, then present this as "Stripe's fee." What they don't disclose is that platforms processing significant volume negotiate rates well below Stripe's published schedule — often 2.2% + $0.25 or less. The difference between the rate the platform pays and the rate the church sees is pure margin, invisible to the church.
On $500,000 in annual giving — typical for a mid-size church — a 0.7% undisclosed margin represents $3,500 in hidden fees. That's not a processing cost. That's a revenue stream disguised as one.
Feature-Gated Giving
Several major platforms restrict giving features by tier. Text-to-give, recurring donations, custom funds, or donor management are locked behind premium plans. A church that needs its members to give online — a basic operational requirement — is forced into a higher-cost subscription to access what should be commodity functionality.
The Switching Cost Trap
When a platform owns the Stripe account on behalf of the church, the church's giving history, recurring donation schedules, and donor payment methods are locked inside that platform's infrastructure. Switching costs aren't just about data migration — they're about asking hundreds of donors to re-enter their payment information. This creates an artificial lock-in that has nothing to do with product quality.
Opaque Settlement
Most platforms deposit a net amount into the church's bank account with minimal line-item detail. The church sees money arrive. They do not see a transparent breakdown of gross donations, processing fees, platform fees, and communication costs. The absence of this visibility is not an oversight. It's a design choice that benefits the platform.
How Church Giving Fees Actually Work
To understand the transparency problem, it helps to understand what actually happens when a church member gives $100 online:
The Transaction Flow
The member's card is charged $100. Stripe takes its processing fee (2.9% + $0.30 at published rates = $3.20). The remaining $96.80 flows to whichever Stripe account received the charge — either the platform's or the church's, depending on the integration model.
If the platform owns the Stripe account, they receive $96.80 and decide how much to pass through to the church. If the church owns the Stripe account (via Stripe Connect), $96.80 goes directly to the church's bank account. The platform never touches the funds.
Where Margins Hide
Three places margins can be embedded without the church's knowledge:
- Processing fee spread — charging published Stripe rates while paying negotiated rates
- Application fee on Connect charges — Stripe Connect allows platforms to take a per-transaction cut before funds reach the church
- Bundled platform fees — combining processing, platform, and infrastructure costs into a single opaque line item
None of these are inherently wrong. Platforms need revenue. The problem is opacity — when a church cannot distinguish between actual processing costs and platform revenue, the trust relationship is undermined.
Donor Fee Coverage
Many platforms offer donors the option to "cover the processing fee." This is a generous and common practice. But if the fee being covered includes an undisclosed platform margin, the donor is unknowingly subsidizing the platform's revenue — not just the processing cost. The ethical implications of this are significant in a giving context.
"When a donor covers a processing fee that includes an undisclosed platform margin, they're unknowingly subsidizing revenue — not just processing costs. In a giving context, that's an accountability problem."
The Zero-Markup Architecture
Kinship's financial architecture is built on a single principle: the platform's revenue comes from subscriptions, not from giving. Processing fees are passed through at cost. Communication costs are passed through at cost. The platform adds zero margin to any transaction that involves a member's donation.
This isn't a pricing decision. It's an architectural constraint. The system is designed so that markup on donations is structurally impossible to add without modifying the settlement calculation — which is auditable by the church at any time.
How It Works
When a donation is processed, Kinship records the exact Stripe fee for that transaction. This is not estimated from published rates — it's the actual fee Stripe reports for that specific charge. The settlement ledger computes gross donations minus actual Stripe fees, with each line item visible to the church.
The platform's subscription fee appears as a separate, clearly labeled line item — never bundled with processing fees. Communication costs (email delivery, SMS) appear as their own line items at the exact per-unit cost the platform pays its providers.
Pass-Through Costs
- Payment processing: Stripe's actual per-transaction fee (2.9% + $0.30 at published rates, or the church's own negotiated rate if using bring-your-own Stripe)
- Email delivery: $0.0005 per email — the exact cost from the sending provider, no markup
- SMS delivery: $0.009 per segment — the exact cost from the carrier, no markup
Every cost the church incurs is either a flat subscription fee (visible on the pricing page) or an at-cost pass-through (visible in the settlement ledger). There is no third category.
Dual-Path Payment Processing
Kinship offers churches two distinct paths for accepting donations. Both are available at every pricing tier. Both carry zero markup from Kinship. The choice is about control and convenience, not about price.
Path 1: Connect through Kinship
The fastest way to start accepting donations. Kinship handles the Stripe setup through Stripe Connect. The church completes onboarding (identity verification, bank account linking) and can begin receiving donations within minutes.
In this model, each donation is charged directly to the church's connected Stripe account. Kinship never holds the funds. Stripe deposits directly to the church's bank account on their standard payout schedule. Processing fees are deducted by Stripe before deposit — Kinship adds nothing on top.
Churches using Connect through Kinship can optionally enable settlement: a feature where subscription and communication costs are deducted from incoming donations rather than charged to a separate card. This simplifies accounting — one deposit, all costs visible in one ledger.
Path 2: Bring Your Own Stripe
Churches that already have a Stripe account — or want complete independence over their payment relationship — can connect their existing Stripe account directly. They negotiate their own rates with Stripe, manage their own dashboard, and maintain full portability.
In this model, Kinship creates charges through the church's own Stripe account using standard API keys. The church sees every transaction in their own Stripe dashboard. If they ever leave Kinship, their Stripe account, donor payment methods, and recurring donation schedules stay with them.
This is the antithesis of platform lock-in. The church's financial infrastructure is theirs — Kinship is a interface layer, not a custodian.
Why Both Options Matter
A church plant with 30 members wants to start accepting online donations today, not spend a week configuring Stripe. Connect through Kinship gets them there in minutes. A 500-member church with an existing Stripe relationship and negotiated rates wants to keep that relationship. Bring-your-own gives them that control.
The architectural principle is the same in both cases: Kinship does not sit between the church and their money. Funds flow from donor to church. Kinship facilitates the transaction. It does not extract from it.
Connect through Kinship
Best for: New churches, fast setup, simplified accounting
Bring Your Own Stripe
Best for: Established churches, existing Stripe accounts, maximum control
The Settlement Ledger
The settlement ledger is the core accountability mechanism. It computes a complete, line-item breakdown of every financial flow for a given period — what came in, what was deducted, and what the church received.
The ledger is not a summary. It is a calculation derived from actual transaction records. Each line item corresponds to real Stripe charges, real provider costs, and real subscription amounts. The church can verify any line item against their own Stripe dashboard or provider invoices.
Interactive: Settlement Ledger Breakdown
Gross Tithes & Offerings
247 donations this period
+$12,450.00
Stripe Processing Fees
2.9% + $0.30 per transaction — actual Stripe cost
-$378.85
Subscription (Mid-Size Church)
251-800 active members — flat monthly fee
-$50.00
Communication Costs
12,400 emails ($6.20) + 890 SMS ($8.01) — at cost
-$14.20
Net Bank Deposit
Deposited directly to church account
$12,006.95
Every line item is verifiable. Exportable as CSV. No hidden fees, no bundled charges.
The settlement ledger serves multiple audiences:
- The church treasurer uses it for bookkeeping and reconciliation. Every deposit matches the ledger's net calculation.
- The finance committee uses it to understand total cost of the platform — subscription, processing, and communications in one view.
- The senior pastor can answer the question "what does our church software actually cost?" with a single exported report.
- An auditor can verify each line item against Stripe's own records and provider invoices.
The ledger is exportable as CSV with debit and credit columns, formatted for direct import into church accounting software. This is not a convenience feature — it's an accountability mechanism.
"A platform cannot claim zero markup if the settlement calculation is invisible. Transparency requires a ledger — and the ledger must be auditable."
Fair-Share Subscription Pricing
Kinship's subscription model is intentionally simple: every feature is included at every tier. The only variable is the number of active members. This eliminates the most common source of hidden cost in church software — feature-gating that forces churches into premium tiers to access basic functionality.
What Counts as an Active Member
An "active member" is defined by engagement, not by mere existence in the database. A member is billable if they meet any one of three criteria in the past 90 days:
- Attendance: Checked in to 2 or more events
- Financial: Made 2 or more donations
- Operational: Holds an active serving role, group leadership position, or staff designation
This definition is recalculated daily using a rolling 90-day window. Members who haven't engaged in 90 days automatically drop off the billable count. The church's tier adjusts accordingly — downward as well as upward.
The daily recalculation uses a dual strategy: real-time event handlers mark members billable when they check in, donate, or receive a role assignment, while a nightly batch reconciliation recalculates every member against actual records to ensure consistency. The two systems cross-check each other.
Interactive: Tier Calculator
Tier
Small Church
Monthly
$25
Every feature included. No add-ons. Tier adjusts automatically — including downward.
Tier Stabilization
Tier changes are subject to a 30-day stabilization window. When a church's active member count crosses a tier boundary upward, the new tier takes effect and is locked for 30 days. This prevents billing volatility from seasonal fluctuations — a church won't bounce between tiers during a mission trip or summer attendance dip.
Downward tier changes are applied only after the stabilization window expires. If a church's count drops below a boundary during the lock period, the downgrade is deferred — not denied. The system always catches up to reality.
Payment Failure & Service Continuity
Credit cards expire. Banks flag transactions. Payment failures happen. The question is: what happens to the church's operations when they do?
Most platforms immediately degrade service or begin aggressive dunning sequences. Kinship takes a different approach: the settlement fallback system.
The Settlement Fallback
When a subscription payment fails for a church that has settlement enabled (their Stripe Connect account receives donations), Kinship attempts a fallback: the subscription amount is deducted from the church's incoming donation stream instead.
This is not an automatic charge to a different card. It's a debit against the church's own connected Stripe account — funds they've already received. The church's service continues without interruption, and the cost appears transparently in their next settlement ledger.
Payment Failure Resolution Flow
Grace Period
If both the card charge and settlement fallback fail (or if settlement is not enabled), the church enters a 14-day grace period in "past due" status. During this period, all features remain fully operational. No degradation, no warnings to members, no public indication that there's a billing issue.
After 14 days without resolution, the account enters "suspended" status. New member additions are queued (not rejected), and the church is notified. Existing functionality remains accessible. The intent is never punitive — it's a circuit breaker that prevents unbounded debt accumulation while preserving the church's ability to operate.
The Member Queue Gate
The member queue gate is Kinship's solution to a common billing boundary problem: what happens when a church crosses from the free tier (50 active members) into paid territory without a payment method on file?
The industry standard is one of two extremes: either block the church from adding members (punitive), or allow unlimited growth and send increasingly aggressive billing notices (unsustainable). Kinship takes a third approach.
How the Queue Works
When a church has 50 or more active members and no payment method (neither a card on file nor a settled Stripe Connect account), new members are created with a status of "queued" rather than "active." Queued members exist in the system but don't count toward the billable total.
The moment the church sets up billing — by adding a card or completing Stripe Connect onboarding — all queued members are automatically activated. No data loss, no re-entry, no disruption. The queue drains itself.
Why This Matters
The queue gate respects both parties. The church isn't blocked from growing. The platform isn't exposed to unbounded cost. And the resolution is automatic — no manual intervention, no support tickets, no awkward conversations about overdue payments.
For a church running a membership drive or community event, this means new visitors can be added to the system in real-time without billing anxiety. The church handles payment when they're ready, and the queued members flow into active status seamlessly.
Audit Trail & Accountability
Financial transparency requires more than a settlement ledger. It requires a comprehensive audit trail that records who did what, when, and why — and that this trail is immutable.
Tier Change History
Every tier change — whether triggered by member count fluctuation, manual adjustment, or stabilization window expiration — is recorded with the previous tier, new tier, active member count at the time of change, and the reason for the change. This history is paginated and accessible to church owners and billing administrators.
A finance committee reviewing the church's annual technology budget can see exactly when and why each tier change occurred, correlate it with membership trends, and verify that the billing matched reality.
Billable Member Transparency
Church administrators can view which specific members are counted as billable and why — whether due to attendance, giving, or an operational role. This is not aggregate data. It's a named list with per-member justification.
If a church questions why they moved from the free tier to the Small Church tier, they can see exactly which 51st member triggered the change and which of the three billable criteria that member met. There is no black box.
Donation Audit Trail
Every donation — online and offline — is recorded with its full lifecycle: creation, processing, completion, and any refunds. Online donations include the exact Stripe charge ID, enabling cross-referencing with Stripe's own records. Offline donations (cash, check) include who recorded them and when.
Audit logs in Kinship are immutable by design. They cannot be edited, backdated, or deleted — not by administrators, not by platform staff, not by anyone. This is enforced at the database level.
Conclusion
The church giving software industry has a transparency problem. Not because every vendor is acting in bad faith, but because the default architecture — platform-owned Stripe accounts, bundled fee structures, feature-gated giving tools, and opaque settlement — makes opacity the path of least resistance.
The architecture described in this paper demonstrates that a transparent alternative is both technically feasible and commercially viable. Zero-markup payment processing is sustainable when the platform's revenue comes from fair-share subscriptions rather than transaction margins. Line-item settlement ledgers are achievable when the system tracks actual costs rather than estimated rates. Provider portability is possible when the architecture separates the giving experience from the payment infrastructure.
The mechanisms are straightforward: dual-path payment processing that gives churches control over their Stripe relationship, a settlement ledger that makes every penny visible, engagement-based member counting that bills only for active participants, stabilization windows that prevent billing volatility, and a queue gate that respects growth without enabling unbounded cost.
For churches, the financial relationship with their software vendor should be as transparent as the financial relationship they maintain with their congregation. The platform should be able to answer the question "what are we paying and why?" with a single exported report — no phone calls, no interpretation, no trust required.
Trust is earned through visibility. Visibility is earned through architecture.
"Trust is earned through visibility. Visibility is earned through architecture."
About Kinship
Kinship is a communication-first church management platform where every feature is included at every pricing tier. The financial architecture described in this paper — zero-markup payment processing, line-item settlement ledgers, fair-share subscription pricing, and dual-path payment processing — is available to every Kinship church from their first day.
Kinship is built by a solo engineer, not a venture-backed startup. There are no investors requiring margin extraction. There is no board pressuring for revenue growth at the expense of church trust. The platform's financial model is as simple as its settlement ledger: fair subscriptions, transparent costs, zero hidden fees.
Every dollar a church spends on software is a dollar not spent on ministry. We believe that conviction should be reflected in every line of code, every pricing decision, and every financial report we generate.
Transparency through architecture
Zero markup on donations. Line-item settlement ledgers. Fair-share pricing that adjusts downward as well as upward. See exactly what you're paying and why.
No credit card required. Every feature included at every tier.
© 2026 Kinship. This paper may be freely distributed for educational and evaluation purposes. The architectural concepts described herein are the intellectual property of Kinship. Technical implementation details are provided for transparency and to advance accountability standards in church financial technology.