Key topics
Related public pages
If you need the product, API or operations page rather than only the article, start with these VPOS.am sections.
Donation payment should be connected with campaign context
Amount without campaign id, donor consent and form source does not help nonprofit close reporting and support.
Charity collections, foundations, NGOs and social projects often run several campaigns at once. If payment link or form does not know campaign id, source, amount, currency and donor consent, team later reconstructs manually which campaign the payment belongs to.
Reliable flow creates donation payment request from controlled form: campaign id, donor record, public/private donation preference, amount, currency, request id and expiration are fixed before payment. CRM receives verified status only after webhook or server-side status lookup.
- connect every payment with campaign id;
- fix donor consent and communication preference;
- do not mark donation as received from return URL;
- separate public donor display and internal CRM record.
Recurring donations and receipts depend on rules
Recurring donations, receipts and tax documents should not be promised without provider, contract and current requirements.
Teams often want recurring donations, automatic emails and receipt-like documents. Technically these are different processes: one-time payment, recurring intent, reminder, accounting document, donor notification and legal/tax review. They should not be merged into one payment status.
If provider or contract does not support automatic recurring charge, safe start is donation links, reminders and donor CRM tasks. Legal, tax and reporting requirements should be checked against current organization and provider rules.
- do not promise auto-charge without provider support;
- store receipt status separately from payment status;
- donor notification should not expose extra data;
- manual correction needs actor, reason and timestamp.
Privacy and reconciliation matter more than a nice counter
Public campaign progress is useful, but backend should protect donor data and reconcile campaign by verified payments.
Donation page can show progress, donor list or anonymous amounts, but payment backend should store only required ids, statuses and CRM references. Unnecessary personal data should not enter public layer or technical logs.
Reconciliation compares campaign goal, verified payments, refunds, donor preferences, CRM records and provider report. Team sees which campaigns are closing, where refund or dispute exists, and which payments require manual review.
- minimize donor data in payment log;
- calculate public progress from verified payments;
- refund should not delete original donation;
- reconcile CRM, provider report and accounting export.
FAQ
Can donation appear on website immediately after return URL?
Prefer updating public progress after verified payment event. Return URL can open before final payment status.
Can recurring donations be implemented?
Only if provider, contract and organization rules support recurring charge. Otherwise use payment links, reminders and donor CRM tasks.
Which donor data should payment backend store?
Only minimum required ids, consent/status fields and provider references. Public names, contacts and preferences should stay in CRM with restricted access.
