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
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
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.
Keep schedules, payment state, failures, retries, donor questions, and contact-level recurring giving context visible.
Track refund requests, processor state, notices, gift impact, and staff review without erasing the original gift.
Generated receipts, templates, delivery history, reissues, voids, and downloadable files stay close to the payment record.
Bring in payment files, Sapling Pay batches, external references, donor matches, and exception states so finance can reconcile without losing the donor story.
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
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.
Sponsor-covered giving
When a sponsor underwrites processing costs for a program, campaign, or giving path, Sapling Pay can model that coverage so neither the donor nor the charity has to carry that specific fee burden.*
Read about Sapling Pay sponsorshipsThe donor can give without being asked to add processing fees.
The nonprofit can receive the gift without absorbing that sponsored fee burden.
The sponsor relationship stays visible for reporting, stewardship, and audit context.
*No-fee giving depends on an active sponsor coverage arrangement, eligible transaction scope, and the payment rails available for that gift. Sapling should still show the underlying economics for audit, reporting, and sponsor stewardship.
Fee structure
Sapling Pay should make Sapling’s fee categories visible instead of burying them inside payment jargon. The payment rail cost sits 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 for event payments and registration-linked giving flows.
Political contributions
To be announced
Political and campaign-finance giving may require a separate payment and compliance structure.
Memberships and dues
To be announced
Membership payments may need different receipt, benefit, deductibility, and renewal treatment.
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.
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.
Online gifts should land with campaign, fund, donor, receipt, recurring, attribution, and communication context ready for stewardship, finance review, and reporting.
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
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.
Sapling Pay versus payment side tools
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