Giving channels in one place
Donation pages, event gifts, recurring giving, sponsorship coverage, refunds, imports, reconciliation, and receipts can all feed the same CRM record instead of becoming separate systems to reconcile.
Sapling Pay
Nonprofit payments that stay connected to the donor record.
Sapling Pay is Sapling CRM's connected payments layer: as many giving channels as Sapling can connect, in one place. Donation pages, recurring giving, refunds, receipts, sponsor-covered fees, payment references, easy imports, data reconciliation, donor questions, campaign context, and CRM history stay tied together.
What Sapling Pay covers
Payments are not a side quest. They are part of gift operations.
Recurring gift management
Keep schedules, payment state, failures, retries, donor questions, and contact-level recurring giving context visible.
Refunds without lost history
Track refund requests, processor state, notices, gift impact, and staff review without erasing the original gift.
Receipts tied to the gift
Generated receipts, templates, delivery history, reissues, voids, and downloadable files stay close to the payment record.
Easy imports and reconciliation
Bring in payment files, Sapling Pay batches, external references, donor matches, and exception states so finance can reconcile without losing the donor story.
Sponsor-covered fee paths
Layer sponsor-funded coverage on top of donation flows so the donor and the nonprofit can experience no-fee giving when a sponsor is underwriting the cost.*
Why it matters
A payment processor can say a charge succeeded. Your CRM has to explain what happened.
Nonprofit teams do not only need a checkout. They need to know who gave, why the gift belongs to a campaign or fund, whether a receipt was generated, whether the gift recurs, whether a refund changed the record, and what staff should do next.
Sapling Pay is designed to keep that payment context close to contacts, gifts, events, emails, receipt files, sponsor coverage, recurring management, and donor support so finance and development do not need to reconcile separate stories.
- Payment IDs and processor state stay visible for review.
- Refund and recurring queues connect back to donor and gift records.
- Receipt generation and reissue history remain part of gift operations.
- Donation pages and events enrich CRM history instead of creating side data.
- Sponsor-covered fees can be tracked alongside the donor, gift, and sponsor relationship.
Introducing sponsored fees
No-fee giving can be funded by a sponsor when the giving path supports it.
Sponsored fees are Sapling Pay's coverage layer. A sponsor can fund eligible fees for a donation page, event, campaign, or program while Sapling keeps the donor gift, processor cost, sponsor context, receipt impact, and reimbursement trail connected.
Explore sponsored feesSponsorship purchase coming soon
A no-fee giving experience when covered
A sponsor can fund eligible processing costs so the donor is not asked to add fees and the nonprofit does not absorb that specific covered cost.
Sponsor context stays attached
Sapling keeps sponsor, program, gift, receipt, reimbursement, and stewardship context together for review later.
Alignment before donor-facing placement
Sponsor coverage can be reviewed against nonprofit acceptance, program fit, and sponsor-client alignment before it appears in checkout.
*No-fee giving depends on an active sponsor coverage arrangement, eligible transaction scope, and the payment rails available for that gift. Sapling Pay still shows the underlying economics for audit, reporting, and sponsor stewardship.
Fee structure
Clear fees, with coverage options when the giving path supports them.
Sapling Pay keeps fee categories visible instead of burying them inside payment jargon. Payment rail costs sit underneath this structure, and coverage rules can decide who carries which part.
Regular donations
1.5% + $0.05
Sapling Pay fee for standard donation charges processed through Sapling Pay.
Event registrations and event gifts
2.0% + $0.05
Sapling Pay fee shown for event payments and registration-linked giving flows.
Stripe card processing
2.9% + $0.30
Underlying Stripe card rail fee, separate from Sapling Pay’s fee category.
Political contributions
Separate treatment
Political and campaign-finance giving can require different payment, receipt, and compliance handling.
Memberships and dues
Separate treatment
Membership payments can carry benefit, deductibility, renewal, and receipt context.
Sponsor-covered fee paths
Program-specific
When active, a sponsor can cover eligible fees so the donor and nonprofit are not asked to carry that specific burden.
On top of Sapling’s fee, Stripe’s standard card processing fee is currently 2.9% + $0.30. Subsequent payment rail fees are to be announced. Final rates can vary by agreement, payment rail, sponsor program, Stripe updates, refunds, disputes, and special pricing arrangements.
Processor truth where staff need it
Sapling Pay keeps processor IDs, payment status, payout context, refunds, exceptions, and review state visible from CRM surfaces instead of forcing staff into a separate dashboard.
Donation pages that enrich the CRM
Online gifts should land with campaign, fund, donor, receipt, recurring, attribution, and communication context ready for stewardship, finance review, and reporting.
Channels that can keep expanding
Sapling Pay is built around connecting as many giving paths as Sapling can support over time: cards, ACH, recurring, events, donation pages, sponsor-funded coverage, and future payment channels without splitting the donor story.
How it works
From giving page to gift record to receipt history.
Sapling Pay is designed around the record your team needs after the payment succeeds, fails, recurs, refunds, imports, reconciles, or needs support. The point is not just collecting the gift. The point is keeping the gift understandable.
- 1Donor gives through a Sapling Pay page or recurring schedule.
- 2Sapling records the payment, gift, fund, campaign, attribution, and receipt context.
- 3Staff can review failures, refunds, recurring changes, delivery history, and donor questions from CRM workflows.
- 4Finance keeps processor references and operational history close to the gift record.
Sapling Pay versus payment side tools
The difference is what happens after the checkout.
A standalone processor tells you money moved. Sapling Pay shows how that money belongs to the donor relationship.
A donation page tool can optimize checkout. Sapling Pay is designed for the operational work after checkout: receipts, refunds, recurring support, reconciliation, and stewardship.
A CRM integration can sync a transaction. Sapling Pay keeps payment state native to the record so staff do not have to reconcile side systems by hand.
A sponsorship layer can cover processing costs when a sponsor funds that program, while Sapling keeps the gift, sponsor, and donor records explainable.
Sapling CRM