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.

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.

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.

Sponsor-covered giving

On top of it all, fees can be covered by a sponsor.

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 sponsorships

The 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

Clear fees, with coverage options when the giving path supports them.

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.

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.

  1. 1Donor gives through a Sapling Pay page or recurring schedule.
  2. 2Sapling records the payment, gift, fund, campaign, attribution, and receipt context.
  3. 3Staff can review failures, refunds, recurring changes, delivery history, and donor questions from CRM workflows.
  4. 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

See payments, receipts, gifts, and donor records in one flow.

Schedule a demo