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, authorize and capture.
Take the money now, or hold it and settle later when the work is done. - 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 and ACH.
Bank transfer alongside cards, 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.
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 and PayPal are integration packages against the same contract rather than a rewrite of your application — but ask us where each one stands before you plan around it, because 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
Where we stand on card security
Payments attract compliance questions, and a confident non-answer on a marketing page wastes everybody's afternoon. So here is the actual position, including the part that is still work in progress.
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 can pass through the application server
In a direct-entry payment, the card is posted to your environment and forwarded to the gateway. Nothing is retained, but the data does transit the server, and that has real implications for the PCI scope of the environment. Client-side tokenization with hosted fields — where the card goes from the browser to the gateway and never touches your server at all — is on the roadmap and is not shipping today. We would rather you hear that here than find it in a questionnaire.
We will not tell you what your compliance obligation is
Which self-assessment questionnaire applies to you depends on your environment, your processor relationship and your assessor — not on a claim a vendor makes in marketing copy. Anyone who answers that question for you before seeing your setup is guessing. What we will do is walk your security team through exactly how the architecture works and where the boundaries sit.
The same applies to our broader compliance position, which we have written down plainly on the about page rather than implying more than is true.
Send us the questionnaire
If you are evaluating this for real money, the useful conversation is with your security and finance people in the room. We would rather work through it now than have you discover the shape of it in month three.