Transactions and payouts
Two pages cover the money moving through Homeward. Transactions is a read-only record of every donation. Payouts is where requests to move money out of the platform to profile owners are approved and sent. Both are staff-level pages.
Transactions
Section titled “Transactions”Transactions is the default landing page of the admin area. It searches every donation on the platform, across all donors and recipients.
Filters
Section titled “Filters”- General search box — searches donor, recipient, and fund. A Clear search button appears once you have typed.
- Donor… and Recipient… — multi-select fields with chip tokens, so you can narrow to several donors or recipients at once. Suggestions appear as you type.
- Status — all statuses, pending, succeeded, failed, cancelled, refunded, or redirected.
- Frequency — one-time, monthly, quarterly, or yearly.
- From / To — date range; the end date includes the whole day.
The table shows Date, Donor, Allocations, Frequency, and Amount, 50 rows per page, with a pagination control showing the page, the page count, and the total.
Rows read at a glance:
- Refunded, failed, and cancelled transactions carry a coloured status marker next to the date and a struck-through amount.
- Pending amounts render italic and muted.
- Cancelled rows are dimmed to about half strength.
- Anonymous donors show “—” instead of a name, with the donor email beneath it.
The Allocations cell shows the largest allocation as recipient and fund — the recipient name links to its public profile — with a +N button, tooltip “All allocations”, listing every recipient, fund, and amount when a gift was split. A transaction with no allocations leaves the cell blank.
The transaction detail modal
Section titled “The transaction detail modal”Clicking a row opens Transaction detail. It is a record, not a work area:
- Donor — name, email, type, and profile ID.
- Allocations — each fund with its linked partner profile and amount, plus a processing-expense line where one was booked.
- Payment — processor, the processor’s reference ID, and the redirect URL when the donation used one. Scheduled and cart donations also show a schedule ID or cart group.
- Timeline — created, started, and ended, or “—” where a step did not happen.
- Debug — the transaction ID, which is what to quote in a support request about a specific gift.
A status badge colours the hero: green for succeeded, amber for pending or paused, red for failed or cancelled, grey otherwise. An anonymous badge appears on the hero when the donor gave anonymously.
Payouts
Section titled “Payouts”Payout requests move money out of the platform to profile owners, and one request may draw on several funds. The page lead states the rule plainly: approve or reject each request before funds leave the platform. Nothing is sent without a decision.
The header shows a permanent badge: Live Wise when the payout integration will move real money, Sandbox Wise when it will move test money. Check it before sending anything — the same buttons appear in both, and only the badge tells you which kind of money they move.
The table lists the request date, the owner and whether they are an individual or an organization, each fund with its amount, the status, the total in USD, and the actions available at that status. Actions appear contextually, so a row only ever offers what its status allows. While one action is running the rest of the row’s buttons are disabled; a failure shows in a red sub-row beneath.
Actions by status
Section titled “Actions by status”- Pending — Approve or Reject.
- Approved — Fund payout, Reject, and the Wise buttons when applicable.
- Funded or failed — Process manually, Return to funds, and the Wise buttons.
- Processing (manual mode) — Confirm paid or Mark failed. Marking failed records “Manual payout could not be completed.” as the failure message.
Fund payout versus Process manually
Section titled “Fund payout versus Process manually”These two do different things and choosing between them is the main decision on the page.
- Fund payout commits the money internally: the funds are debited and the payout is marked as funded, ready to be dispatched.
- Process manually means you are paying outside Wise — by bank transfer you make yourself — and recording it. Pressing it asks for a Bank transaction ID, which is required, then starts the manual flow and shows Confirm paid and Mark failed.
Return to funds reverts the request and puts the money back where it came from.
The Wise flow
Section titled “The Wise flow”Wise is the payout provider that sends money to bank accounts. Three buttons appear when Wise is configured and the payout has a bank destination:
- Get Wise quote — request an exchange-rate and fee quote. Once a quote exists, the row shows what the recipient gets and what Wise will debit, including the fee.
- Confirm Wise send — dispatch the transfer. In the live environment this opens a confirmation dialog, “Send this live Wise payout?”, stating that it dispatches real funds and requiring you to press Send live payout. In sandbox it dispatches immediately.
- Sync Wise — reconcile an automatic in-flight transfer with Wise’s own status, for example after a webhook was missed.
Only one action per row runs at a time; the rest are disabled until it finishes. When Wise holds state on a payout, a sub-row shows its status and transfer ID, and any error appears in a red sub-row.
Related: Staff administration, Payment integrations, Fixing something that is wrong.
