Money movement.
Part of the platform, not a plugin.
Most applications end up bolting a payment processor onto the side and reconciling it by hand. Invoices, pledges, receipts and donations are first-class records here, sitting on the same ledger as everything else your organization tracks.
Running in production PAG bills on this today as part of its benefits administration platform, with a second environment going live shortly. This is not a module waiting for its first customer.
Four kinds of document, one ledger
Two of them say money is owed. Two of them say money arrived. Everything else — the line items, the transactions, the running balance — works the same way underneath.
Invoice
A balance due, with line items, taxes and adjustments. Partial payments reduce it and the balance rebalances rather than being recalculated by hand.
Pledge
A commitment to give, tracked as an outstanding balance until it is fulfilled. The same mechanics as an invoice, with the language a development office actually uses.
Receipt
Money received against something owed, or on its own. Issued, numbered and retrievable by the person who paid, not just by your staff.
Donation
A gift, received and acknowledged, with the donor record attached. Not an invoice with the labels changed — a distinct kind with its own handling.
The operations finance asks for
Taking a payment is the easy half. What determines whether a billing system survives its first year is what happens when something has to be undone.
- Charge.
Take the money against a card entered at the time or a stored profile. - Void and refund.
Before settlement and after, each handled correctly against the gateway rather than approximated with an offsetting entry. - Corrections.
Because somebody will key the wrong amount, and the answer to that cannot be editing a historical record. - Card, with ACH next.
Cards process end to end today. Bank transfer is recorded on the ledger now and will be processed through the gateway, for the payers who will not put a five-figure invoice on a credit card.
Stored payment methods, kept current
Cards are vaulted with the payment gateway against a customer profile, so a repeat payer confirms rather than re-enters. Your application holds the profile reference, not the card.
Cards also expire, get reissued after a breach, and get replaced when someone changes bank. A scheduled Account Updater job reconciles stored methods against the gateway's records each month and reports what changed — in dry-run by default, so you see the effect before it is applied. The alternative is discovering the problem through a wave of failed payments and a month of chasing donors and members for new card details.
Recurring gifts and dues use the same stored methods. A Logic App (or any timer) calls one billing API once a day. Each due date is claimed before the charge, so a retry or overlapping run cannot double-take a congregation's monthly gift. Pause freezes the next date; cancel is terminal. The job does not invent a second subscription at the processor — WebEdify owns the schedule, and the gateway only charges.
One contract, whichever processor you end up on
This is the part worth understanding before you commit, because it is the decision that usually costs people later.
Your application never calls a processor's API. It asks for a purpose — charge this, refund that, save this payment method — against a single gateway contract. One implementation of that contract sits behind it, and Authorize.Net is the one that ships in the box.
The consequence: changing or adding a processor is a package reference and a configuration change, not a re-integration of every screen and workflow that touches money. Stripe, Square, PayPal and other processors will be created as packages against the same contract rather than a rewrite of your application. Authorize.Net is what is proven in production today.
It also means the reverse. If you are already on Authorize.Net, you keep the merchant account and the rates you have negotiated — moving onto the platform is not a forced processor migration. For an organization that spent real effort getting those rates, that tends to matter more than any feature on this page.
Merchant account portability is not a theoretical concern. Rates change, acquirers drop verticals, and nonprofits in particular get moved around. Being able to switch without re-engineering is worth more than whatever you save on the initial integration.
Where it already runs
The screens come with the platform rather than being built per project:
- Invoice list, compose, pay, refund and void for staff
- Transaction history and ledger review
- A client-facing portal for invoices and payment
- Self-service management of stored payment methods
- Quick donation and quick receipt entry
How card security works here
Payments attract compliance questions, and a confident non-answer on a marketing page wastes everybody's afternoon. So here is the actual architecture.
We do not store card numbers
Not in any table, not encrypted, not anywhere. A saved card is vaulted with the gateway and we hold the gateway's customer and payment profile identifiers. What lands in the ledger is a display snapshot — last four digits, card type, expiry and a formatted label. That is what a receipt needs, and it is all we keep.
Card data never has to reach your environment at all
Customer-facing payment pages use client-side tokenization: the card is exchanged for a single-use token in the browser, and your server only ever handles the token. The number does not pass through your application, your logs, or your network. That is the architecture that narrows PCI scope, and it is the default for the pages your customers use. Direct entry remains available for staff-keyed work, where the card is forwarded to the gateway and nothing is retained.
Your assessor's questions, answered directly
Which self-assessment questionnaire applies depends on your environment, your processor relationship and your assessor. We will walk your security team and your assessor through exactly how the architecture works and where the boundaries sit, so the determination gets made on the facts rather than on a vendor's summary of them.
Our broader security and compliance posture is on the about page.
Send us the questionnaire
If you are evaluating this for real money, the useful conversation has your security and finance people in the room. Bring them, and bring the questionnaire.