Charity payment processing for events, appeals and recurring giving
Built for how charities actually take money
Phone appeals, gala nights, telethons, post-event pledge chase, regular giving sign-ups — one platform, one PCI attestation, every channel covered.
TL;DR
Charity payment processing means taking donations on phone, web, SMS and at live events without card data ever touching your charity's systems. With Paytia, the donor's card goes straight from their phone or browser into our PCI DSS Level 1 environment and on to your gateway — your fundraisers don't hear it, your CRM doesn't store it, your call recordings don't contain it. The compliance posture drops to SAQ A (22 controls), Gift Aid declarations are captured alongside every gift, pledges convert at materially higher rates because the follow-up is a single tap on a payment link, and most charities are live in under a week.
Why charity payment processing is different from retail card acceptance
Last updated: 29 May 2026
Most off-the-shelf payment platforms are built around a single shape of transaction — a customer adds something to a basket, taps a card on a reader, and the sale closes. Charity income doesn't look like that. A donor commits £500 at the auction on Saturday night, pledges another £200 by the end of the evening, signs up for £20 a month on the way out, sponsors a fundraiser through a JustGiving link the following week, and rings the office on Wednesday to upgrade the monthly amount after a thank-you letter lands. Every one of those touchpoints is a different channel, with different compliance pressure, and a different risk of leaking either money or data.
The compliance pressure is what trips most charities up first. The Charity Commission's expectations on donor data, the FCA's rules where the charity also offers regulated services, and PCI DSS 4.0.1 itself all converge on the same point: if you can keep cardholder data out of your environment, do. The standard retail answer — read the digits aloud, type them into the office laptop, log a record on the CRM — is exactly the workflow PCI DSS 4.0.1 is designed to make uneconomic. The 4.0.1 rules on call recording are explicit: any audio that captures sensitive authentication data after authorisation is an explicit control failure. Pause-and-resume on the recording layer was a weak control under previous versions; under 4.0.1, a single missed pause is a finding.
The money-leak side is just as costly, and most charities undercount it. Pledges are the obvious example — supporters commit generously at the moment of the appeal, the team writes them down on a clipboard, and a week later the development office has to chase by email. Charities we've worked with report pledge-conversion rates as low as 30% on legacy chase processes, against 70%+ when a personalised payment linkwith the amount pre-filled goes out within 24 hours of the event. The difference isn't the supporter's intent — they meant the pledge — it's the friction between intent and payment. Every step you add to the post-event flow is a step where the supporter loses momentum.
Charity payment processing done well solves both problems together. Card data routes through a single PCI-validated environment regardless of channel, so the compliance scope collapses to the minimum SAQ A control set. The donor-facing experience uses the channel the supporter is already in — keypad on the phone, link on the SMS, QR on the gala menu, app sign-up on the website — so the friction between intent and payment disappears. The rest of this page walks through what that looks like in practice, channel by channel.
Phone appeals — the volunteer stays in conversation, the card never reaches the recording
A phone fundraising call is a relationship, not a transaction. The volunteer or paid fundraiser is making the case for the appeal, answering questions, and reading the supporter's mood — when to push for a larger gift, when to switch to a monthly ask, when to back off and ask for a smaller one-off. Putting a payment step in the middle of that conversation without breaking it is the whole point of DTMF masking.
The mechanics are simple. When the donor commits, the fundraiser presses one key on their agent screen — usually 729 — and the masking layer engages. The donor hears a short prompt asking them to enter their card on their handset. From that moment, every keypad tone the donor generates gets intercepted by our platform, decoded into the digit, and forwarded over an encrypted channel to your payment gateway. The fundraiser's leg of the call hears a flat replacement chirp instead of the real tone — same on every digit, carrying no information. The call recording captures that same flat chirp. So does any QA platform pulling audio from the trunk. The voice channel stays open the whole time, so if the donor asks “is this the same card I used last time?” or “is this going on the cancer research appeal or the general fund?”, the fundraiser answers normally — they just can't hear the digits being keyed.
For the donor that solves a real awkwardness. Reading a card number aloud in a quiet office, on a train platform, in a hospital waiting room or anywhere within earshot of another human is one of the most cited reasons people decline to give on the phone. We've had charities tell us the same fundraisers, taking the same calls with the same scripts, captured noticeably more cards after masking went live — the only difference being that the donor no longer had to recite their digits to a stranger over the line.
For the charity it solves the PCI side at an architectural level. Without masking, a phone-payment workflow puts the fundraiser's headset and workstation, the call recording server, the QA platform, the CRM where the digits are pasted, the network connecting all of those, and the office firewalls into PCI scope — the SAQ D path, 329 controls, an annual QSA engagement. With masking on, card data never reaches any of those systems, so none of them are in scope. The compliance work drops to SAQ A — 22 controls, mostly about validating us as the certified service provider and keeping your own organisational policies in order. The PCI Council's information supplement Protecting Telephone-Based Payment Card Data recognises DTMF masking as the method that takes the telephony, agent and CRM environments out of scope.
Event nights — no queues, no clipboards, no card data on event laptops
A gala, auction or charity dinner generates spontaneous giving — but it also generates spontaneous friction. The auction lots close and the winners need to pay. The matched-giving moment lands and three quarters of the room reaches for a phone. The closing pledge from the chair lifts the room and you've got 20 minutes to capture that energy before the cabs arrive. Every minute the process takes is a minute the energy drains away, and every paper form is a record someone's holding overnight.
Payment linksare the workhorse here. Generate one campaign page per event in the dashboard — branded with the charity's logo, the event name, the appeal target, a running total if you want one — and you get a single URL that maps to a QR code printed on the back of the menu, displayed on screens between auction lots, and dropped into the post-event SMS. The supporter scans, the page opens on their own phone, they pay with Apple Pay or Google Pay or a card, and the donation lands in your account in real time. No volunteer touches a card, no laptop on the registration desk stores one, no clipboard goes home in someone's bag.
For the auction specifically, the workflow runs slightly differently. The winning bidder confirms the amount with the auctioneer, the event team sends the bespoke link by SMS to the number on the bidder's registration card, and the bidder pays from their seat while the next lot is being introduced. The auctioneer moves on without a payment-related pause. Settlement on the lot is matched to the supporter record automatically, so the catalogue reconciliation that used to consume two days of the development office's following week is done before the lights come up.
The PCI side stays clean because no card data crosses your event infrastructure. The supporter's phone talks to our hosted payment page, the page talks to your gateway, and the only thing that returns to your CRM is the result — donor name, amount, time, lot reference. The event Wi-Fi, the volunteer iPads, the registration laptops and the venue's guest network are all outside the cardholder data environment because cardholder data never visits them. That same logic applies to peer-to-peer fundraising platforms you might be running alongside the night — JustGiving, Enthuse, GoFundMe — the in-room capture isn't competing with them, it's catching the supporters who would otherwise have left without paying.
Recurring giving — converting the event donor into the monthly supporter without a second call
Most charity development teams know the maths: a £20 monthly regular giver is worth more over five years than a single £500 one-off. The challenge is the conversion path. A donor who's just given £500 at an event is in the best possible frame of mind to commit to monthly support, but the standard ask requires them to come back to a website later, fill in a Direct Debit form, and authorise a mandate days after the high has worn off. By the time the form lands the answer is “not this month, thanks.”
With Paytia, the regular giving sign-up happens on the same call or in the same payment flow. The donor keys their card once, the system tokenises it, and the fundraiser sets the schedule on the spot — “perfect, I've got you down for £20 a month, first collection on the 1st of next month, do you want the receipt by email or post?” The token is stored against the donor record; the original PAN is never in your environment. Subsequent collections run automatically against the token without the donor needing to authorise each one. If the card expires or fails, our system retries on the configurable cadence, then escalates to a recovery email with a re-auth payment link — the development office only sees the cases that genuinely need a phone call.
Gift Aid runs through the same layer. The donor's declaration is captured before the card entry step — full name, home address, the tax-payer confirmation — and bound to the donation record at the gateway level. At quarter-end, the HMRC submission is an export from the dashboard, not a reconciliation project. If a regular giver later asks to cancel the declaration (they've stopped paying UK tax, for example), the cancellation is logged and applied to future gifts only — past claims aren't affected and the audit trail is preserved.
For charities with international donors, the tokenisation model means a single supporter record can hold tokens from multiple cards and currencies. A US-based monthly giver paying in USD can sit alongside the UK Gift-Aided supporter base without forcing the development office onto two systems. The PCI scope stays the same — none of those tokens are PANs, and the actual cards never enter your environment.
Every channel a supporter actually uses
One platform, one PCI attestation, every donation path covered — without the development office having to learn five different tools.
DTMF masking on inbound and outbound calls
Donor keys the card on their handset, fundraiser stays in conversation, masking layer drops the tones from the recording. Works on every major CCaaS, PBX and SIP trunk, and integrates with your existing CRM in a few hours.
Payment links over SMS and email
One campaign page, infinite distribution. Branded to the appeal, amount pre-filled or open, Apple Pay and Google Pay on the page by default, donation reconciled to the supporter record on settlement.
QR codes on event collateral
The same campaign page becomes a QR on the menu, the screen behind the stage, the back of the auction catalogue. Supporters scan, pay from their seat, and the lot reconciliation is done before the cabs arrive.
Tokenised recurring giving
Sign up regular donors on the same call or web flow they used for the one-off gift. Token stored against the donor record, retries handled automatically, expired-card recovery on an SMS payment link.
Gift Aid declaration capture
Name, address and declaration captured before the card step on every channel. Donation record stores both together, HMRC export is one click, cancellations preserve the audit trail.
Real-time campaign dashboards
Live fundraising totals visible on the dashboard and projectable on event screens. Track conversion by channel, donor segment and appeal — and brief trustees with a single export.
PCI scope, Charity Commission expectations and the volunteer problem
Charities run on volunteers, and volunteers are the single highest-risk part of any payment flow that handles card data directly. Not because volunteers are dishonest — most charity volunteers are deeply trusted within their communities — but because the controls that would normally surround a paid contact-centre agent (formal training, background checks, supervised workstations, audited call recordings, locked-down devices) are difficult or impossible to apply consistently to a rolling pool of unpaid helpers. A standard PCI auditor walking into that environment is going to find issues, because the standard PCI control set wasn't designed for it.
The architectural answer is the same as in any other contact-centre context: make sure card data simply never reaches the volunteer's environment. The volunteer can hear the call, talk to the donor, hold the relationship — but the digits travel a separate path. With masking on the phone leg and payment links on the digital legs, the volunteer's device, the laptop on the registration desk, the iPad at the entry table and the office workstation back at the charity all stay out of scope because none of them ever sees a card number. The PCI compliance burden drops to SAQ A and most of the controls you'd otherwise be designing for a volunteer pool simply disappear.
The Charity Commission's wider expectations on donor data and trustee oversight align with this directly. Trustees are personally liable for the charity's financial controls; a data architecture that keeps card data structurally out of the charity is materially easier to explain to a board and to defend at a Commission inspection than one that depends on volunteer behaviour holding up consistently across hundreds of calls. Our PCI DSS Attestation of Compliance is what trustees include in their own SAQ A submission, and the AoC is updated annually as part of our certification cycle.
For charities operating in regulated sectors — hospice care, financial advice, mental-health helplines — the FCA's SYSC 10A taping requirements run in parallel. SYSC 10A obliges you to record certain client calls in full; PCI DSS 4.0.1 obliges you to ensure sensitive authentication data isn't present in those recordings. Masking is the architecture that satisfies both at the same time — the recording stays complete and continuous, with the card digits simply absent from the audio. There's no “pause the recorder when the card is being entered” control to fail.
Going live before the next big event
Most charities we work with are configured and live inside a week, and a meaningful number have payment links up the same day they sign the contract. The reason is that nothing here is bespoke development — the platform is already built, the integrations to the major gateways are already in place, and the channel mix you pick is mostly a configuration choice in the dashboard. For an event-driven charity calling us about a gala on the Saturday, a Monday start typically delivers campaign pages and SMS-distributable payment links by Wednesday and the phone leg integrated with the contact-centre platform by Friday.
The integration shape depends on what your telephony looks like. On modern cloud CCaaS — Genesys Cloud, Five9, NICE CXone, Amazon Connect, 8x8, RingCentral, Talkdesk — we plug in via API and the integration is a couple of working days, mostly bounded by change-window approvals on your side. On on-premise PBX (Mitel, Avaya, Cisco UCM, Asterisk, FreeSWITCH) the integration is SIP-based and runs five to ten working days. On a plain SIP trunk feeding agent softphones directly, two to three days. We support seven integration patterns between them — network-level divert, PBX-level divert, IVR menu, agent transfer or conference, PSTN outbound, WebRTC and direct SIP trunk — which covers almost every contact-centre stack we've walked into.
On the digital side there's even less to do. Payment links and QR-driven campaign pages are configured in the dashboard, branded with the charity's logo and colour palette, connected to your gateway, and distributed via your existing email or SMS platform — Mailchimp, dotdigital, Twilio, Spoke, whatever you already use. The reconciliation back into your CRM (Salesforce, Microsoft Dynamics, Donorfy, Beacon, Raiser's Edge) runs through our standard connectors or a webhook if you'd rather build the integration yourself.
The cost shape is pay-per-use — no setup fee, no monthly minimum, no long-term contract — which is the model most charities prefer because it doesn't penalise you for the seasonal nature of fundraising. A telethon weekend that processes thousands of donations costs more than a quiet week, and a quiet month costs almost nothing. Volume discounts kick in at higher tiers if your overall income justifies them. For the full pricing detail, including the per-transaction structure and the channel-specific fees, talk to us with a sense of your annual donation volume and channel mix.
Frequently asked questions
What is charity payment processing and how does it differ from a normal merchant account?
+
Charity payment processing is the set up that lets a non-profit take donations across phone, web, SMS, QR and in-person channels without putting card data through its own systems. The difference from a normal retail merchant account is the compliance posture — we route donor card details directly into our PCI DSS Level 1 environment, so the donor record on your CRM never carries a PAN, your call recordings never carry tones, and your event laptops stay out of scope. The money still settles into the charity bank account you already use; we sit on the data path, not the money path. See how DTMF masking handles the phone leg and payment links for the web and SMS legs.
Can we collect Gift Aid declarations alongside phone donations?
+
Yes. When a donor pays over the phone, your fundraiser captures the Gift Aid declaration and donor address details before the card entry step. The donation record stores both the payment and the declaration together, so when you export for HMRC at the end of the quarter, every eligible gift is already matched to a valid declaration. See how phone payments work for the full call flow.
How do donors pay during a phone-fundraising call without reading their card aloud?
+
The donor keys their card number into their own phone keypad while still on the call with your fundraiser. We replace the keypad tones with flat audio in real time, so your fundraiser hears nothing identifiable and the digits never touch your call recording or CRM. They stay on the line throughout to confirm the donation landed. DTMF masking is what makes this work.
Can event staff take card payments on phones or tablets at a gala?
+
Rather than putting card data on event-staff devices, we send a secure payment link by SMS or email — the donor taps it and pays from their own phone. Card data never lands on a borrowed iPad or a volunteer's laptop, which keeps the night out of PCI scope entirely. Payment links handle the in-room and post-event pledge follow-up the same way.
Can we set up regular giving for a donor during a single phone call?
+
Yes. Once the donor keys in their card via the phone keypad, we tokenise it and you set the schedule on the spot — monthly, quarterly, or annually. The donor doesn't need a second call to authorise future collections, and the token is meaningless to anyone who intercepts it. Useful for converting a one-off event donor into a regular supporter without the admin friction. See recurring payments for the setup detail.
How does charity payment processing handle the post-event pledge chase?
+
Pledges are where most charity events leak money — guests commit on the night, the team chases by email a week later, and a chunk of pledged value never converts. We send a personalised payment link by SMS or email to each pledged donor, branded to your campaign, with the amount pre-filled. The donor taps, pays, and the donation is matched back to the pledge automatically. Payment chase covers the full workflow, including reminder cadence.
What does running multiple events a year mean for our PCI scope?
+
If your charity never touches card data, your PCI scope stays at the minimum SAQ A level no matter how many events you run. Because card details go straight from the donor's phone into our PCI DSS Level 1 environment, none of your event laptops, volunteer devices, or office systems come into scope. See our PCI DSS attestation if your auditor needs the AoC.
Does charity payment processing work for telethons and radio appeals?
+
Yes. Telethon volumes are exactly the load profile this is built for — burst traffic over a few hours, peaks of several hundred concurrent calls, and a need to keep call-handling time short. The volunteer takes the donor through the appeal, presses one key to start the capture, and the donor enters the card on their own phone. Average handling time on a masked telethon donation is around 20 seconds for the card entry itself, the volunteer stays in conversation throughout, and there's no transfer to an IVR. The Charity Commission's expectations on donor data are met because the digits never reach your environment.
Can the same setup take donations in different currencies for international appeals?
+
Yes, if your acquirer supports multi-currency. We support multi-currency settlement through the same major UK and international gateways that charities already use — Stripe (we're a Stripe partner), Worldpay, Adyen, Barclaycard, Opayo. For an emergency appeal that draws donors from the UK, EU, US and Australia, you can take each donation in the donor's local currency and settle in GBP if your acquirer offers that. The data architecture is identical — card data goes directly to Paytia, then to your gateway.
How quickly can a charity get charity payment processing live before an event?
+
Most charities go live in under a week for the standard configuration — phone donations with masking, payment links, recurring giving, and a branded donor-facing payment page. If you have an event next Saturday and you're calling on Monday, we can usually have payment links and a campaign page live by Wednesday and the phone leg integrated with your CCaaS or PBX by Friday. The integration is configuration, not new infrastructure — no hardware on the volunteer desk, no software install, no change to your CRM.
Ready to raise more at your next event?
See how UK charities use Paytia to capture more donations at every event. Book a personalised demo today.
New to payment compliance? Read our charity and non-profit payment compliance guide to see what trustees and finance teams need to know.