Online donation processing connects a supporter's intention to give with a payment provider, a bank receipt and an accounting record. A donation page is only the first part of that journey. The NGO also needs to handle failed collections, recurring gifts, fees, refunds, disputes and payouts containing many transactions.
Select payment methods around the countries and supporters you serve, then design reconciliation before launch. Cards, direct debit and digital wallets can produce different confirmation and settlement events. The donation record should show what has happened, what remains uncertain and who owns the next action.
Payment methods depend on donors and receiving entities
Build a matrix of donor location, receiving entity, currency, payment method and provider availability. Confirm onboarding and settlement eligibility for the NGO's legal entity, not just whether a checkout button can be displayed in that country. Record fees and payout terms from the provider's actual proposal.
| Method | Design Question | Exception To Test |
|---|---|---|
| Cards | How are authorisation, capture and later adjustments represented? | A refund or dispute after the original payout |
| Direct debit | How are mandates, collection status and returns handled? | A collection fails after an initial pending state |
| Digital wallets | Which underlying payment route and provider records are used? | The wallet payment appears in a mixed payout |
| Bank transfer | How does the donor supply a matching reference? | Funds arrive with an incomplete or incorrect reference |
Avoid presenting a wallet as a separate accounting model when it uses the same underlying processor settlement. Conversely, do not assume every method has the same finality or dispute rules. Confirm those details with the provider for the relevant country and payment scheme.
Crypto contributions require separate acceptance, custody and conversion decisions. Evaluate crypto donation controls as a distinct workflow before adding that option to a standard donation page.
A gift and a bank settlement are different events
Assign a donation identity that survives payment attempts and corrections. Store provider transaction references separately from the donor, campaign and fund references. One recurring commitment can create many payment attempts, and one bank payout can contain many successful gifts.
Keep the gross donation, processing charge, net settlement and later adjustments identifiable. Posting only the bank deposit as donation income would conceal the fees and refunds. The payout reconciliation below shows how those records explain one net deposit.
The correct accounting entries depend on the NGO's policy and jurisdiction. The operational requirement is to retain enough detail for finance to apply that policy and explain the reconciliation. Fund accounting also needs the gift's restriction reference, which cannot be inferred solely from the payment method.
Use a clearing account with a reviewed reconciliation
Where appropriate to the accounting design, a payment clearing account can track amounts between accepted transactions and bank settlement. Reconcile its balance to provider reports and investigate aged items. A timing difference may be legitimate; an unexplained difference still needs an owner.
Keep the reconciliation period and source exports with the approval. If a provider later corrects a payout, retain the original result and the adjustment instead of overwriting the previous review.
Payment notifications can be repeated or delayed
A provider notification can update a payment record, but integration reliability needs more than receiving a message. Stripe's documentation describes signature verification, retries and duplicate-event handling. Design for repeated or delayed messages and reconcile against the provider's authoritative records.
Check a notification's authenticity before applying it. Record its identity and processing result so retrying delivery does not create another gift. If the event order is uncertain, use the provider's supported method to obtain the current transaction state.
These are acceptance requirements for the NGO ERP integration, not a reason to make fundraising staff diagnose technical messages. Give staff a clear exception view with the donation reference, issue, owner and next action.
Recurring gifts, refunds and disputes need distinct states
Separate the commitment schedule from each collection attempt. A failed instalment should not cancel the entire relationship unless the agreed process calls for that action. Route communication through the supporter's approved preferences and record the result of any recovery attempt.
A refund should reference the original gift, reason, amount and authorisation. Support partial refunds where the selected provider and operating process permit them. Check how the change reaches the donor CRM, financial records and campaign totals.
Disputes need a different queue from ordinary refund requests. Name the person responsible for deadlines and evidence, and preserve access to the relevant transaction history without giving unnecessary access to unrelated donor information.
Reconcile payouts to bank
Donation → provider transaction → provider fee → payout batch → bank deposit → Causeway reconciliation.
The donation record explains the donor, campaign and designation. The provider record explains collection and fees. The payout groups transactions for settlement, while the bank statement confirms what reached the account. Keep all four references so a finance reviewer can move from a deposit back to its individual gifts.
| Reconciliation item | Example amount | Evidence |
|---|---|---|
| Collected donations in the batch | $1,000 | Provider transaction list matched to gifts |
| Refunds deducted | $50 | Refund references linked to original gifts |
| Provider fees | $30 | Batch fee statement |
| Expected bank deposit | $920 | $1,000 minus $50 minus $30 |
| Actual bank deposit | $920 | Bank line matched to the payout reference |
These example amounts assume one currency and no reserves or other adjustments. Record withheld reserves, chargebacks or conversion differences separately when they occur. A deposit for $900 would leave a $20 exception to investigate; it should not silently reduce recorded donation income. Close the batch when its gifts, adjustments and bank receipt reconcile, with any remaining difference assigned to an owner.
Confirm security responsibilities before launch
Prefer a design that keeps sensitive card credentials within the provider's approved payment flow. Confirm the actual integration boundary with the responsible payment-security adviser. Outsourcing payment processing does not eliminate the merchant's responsibility to ensure account data is protected, as the PCI Security Standards Council explains.
Test the public donation journey, mobile usability, confirmation message, failed attempt, duplicate submission and refund reconciliation. A successful test donation should be followed all the way to the bank and ledger before the process is accepted.
Who owns each part of the payment journey?
| Responsibility | Provider | NGO And ERP Workflow |
|---|---|---|
| Payment credentials and execution | Operates the contracted payment service | Uses references and status needed for the process |
| Gift identity and designation | Returns transaction references | Preserves donor, campaign and restriction |
| Payout and charges | Supplies settlement and fee records | Reconciles gross, adjustments and bank receipt |
| Refund | Executes an authorised provider request | Approves the reason and records the linked correction |
| Event failure | Supplies documented retry and status behaviour | Deduplicates intake and investigates unresolved differences |
The end-to-end flow is donor → checkout/provider → verified transaction event → gift and finance records → provider payout → bank reconciliation. A successful provider transaction without its ERP posting remains an integration exception, not a completed reconciliation.
Assign record ownership, reconciliation and recovery routes with the NGO Integration Map Generator.
Conclusion
Choose donation methods that fit the donor base and receiving entity, then test the full route from gift to bank deposit. A successful checkout does not prove the payout reconciles. Preserve provider events, fees, refunds and batch references so finance can explain the net receipt without losing the original donation. Launch when repeated notifications, failed collections and disputed transactions also have tested recovery paths and accountable owners.
Map your donation payment integration
Discuss scoping donation-provider and finance integrations around Causeway donor and fundraising platform. Share the receiving entities, proposed payment methods, provider reports and refund scenarios that the design must support.
Ask for explicit ownership of checkout, transaction updates, reconciliation and exception handling. Confirm provider eligibility, integration availability and any development separately. A useful assessment should show how a gift reaches the accounting records and how a failed or corrected transaction is resolved before implementation commitments are made.
Frequently asked questions
Can several payment providers feed one ledger?
Yes, provided each provider has clear mappings, references and reconciliation ownership. Keep separate clearing and exception views where needed. Combining providers into one unexplained net deposit makes it harder to identify missing transactions or fees.
Should every NGO offer every payment method?
No. Prioritise methods that suit the actual donor base and receiving entities, with manageable costs and support obligations. Add methods when their value justifies the additional reconciliation, security review and exception handling they introduce.
