Ignition Payouts v0.1.0
The first release of Ignition Payouts. When your platform collects pledge money on behalf of your creators, this is the record of paying it back out: one screen showing every creator you owe and how much, a form to record each payment you made, a history to audit it against, and — on the creator’s side — a page and an email telling them what arrived.
It records payments; it does not send them. Every payout describes money you already moved at your own bank, which is why the suggested figure is on screen before anything leaves your account rather than after.
New Features
Section titled “New Features”-
The To Pay queue — Every creator you are holding money for, one row per creator per currency, with what you owe, how many payments make it up, and how long the oldest has been waiting. Rows split into Ready to Pay and Held Back, so money behind an all-or-nothing campaign that fell short is separated from money that is safe to send — and never mixed into the same row. See The To Pay queue.
-
Record a payout — A form that shows exactly what it settles before you commit: the campaigns, every held payment with its backer and date, any refunds netted off since the last payout, and the suggested amount. The amount arrives pre-filled and stays editable, because the money moved at your bank and your figure is the true one. Both numbers are stored, so a difference stays visible on the record instead of disappearing. See Recording a payout.
-
Unreliable figures are marked before the money moves — Where a payment’s underlying data is known to be incomplete, the queue and the record form say so and say which direction it is wrong in: too high when a payment processor never reported its fee, too low when a partial refund of a tipped charge deducted the whole tip. The mark never changes the amount and never blocks you; it exists so the correction happens on screen rather than at the bank. See When the suggested figure is marked unreliable.
-
Payout history — Every payout you have recorded, newest first, filterable by creator and by month, with a per-currency total that covers everything the filters match rather than just the page on screen. Each payout opens into a full record: what it covered, what refunds it absorbed, and an append-only status history. See Payout history.
-
Reversing a payout, without rewriting history — A payout recorded in error is reversed, never edited or deleted. The original stays in the ledger marked Reversed, a reversing entry appears beside it, the payments it covered return to the To Pay queue, and the two net each other out in the totals. See Reversing a payout.
-
Creators can see what arrived — A read-only Payouts page on the creator dashboard listing every payout they have received: date, amount, method, your reference, and — expandable per payout — every payment it settled, grouped by campaign. A lifetime total closes the table. It is what lets a creator reconcile a bank deposit against their pledges without asking you. See What creators see.
-
A payout-recorded email — Sent to the creator when you record a payout, in the past tense because the money has already gone, with the amount, date, method, your reference, and what it covered. Creators can switch it off from their own account page. The confirmation you see after recording tells you whether it actually went. See The payout-recorded email.
-
Trace one pledge to its payout — The Payment Attempts table on the wp-admin pledge detail page gains a Payout column naming the payout that carried each payment, or saying it has not been paid out yet.
-
Live and Test kept apart — Every wp-admin screen follows the Live / Test switch, so rehearsal money never appears in a real queue or a real total. The creator’s own page shows both, badged, so a rehearsal payout is visible to the person who was told about it.
-
Refunds that arrive after you paid — A refund recorded after the creator was paid is never clawed back. It comes off their next payout instead, is shown on the record form as its own line, and is listed on the payout that eventually absorbs it.
-
Fails loudly, not silently — The add-on refuses to start, naming what to update, when Ignition Crowdfunding is below 0.22.0 or Ignition Platform Mode is missing or below 0.4.0.
Developer
Section titled “Developer”-
The Payout is a first-class entity — A filterable transitions map, a creation action and the three-tier status-change actions core gives its own entities, a filter over the row about to be written, a per-status veto, and an append-only read API with a bulk coverage lookup. Recipient, currency and mode are derived from the payments a payout covers and cannot be overridden through the filter. See the Payouts reference.
-
Answers core’s custody question — The add-on answers
igcf_payment_attempt_operator_still_holdswithfalsefor a payment an in-force payout already covers, so core’s own money statements stop describing held money once it has actually gone out.
Requirements
Section titled “Requirements”- Ignition Crowdfunding 0.22.0 or later
- Ignition Platform Mode 0.4.0 or later, active
- WordPress 6.9 or later, PHP 8.2 or later
No payment gateway is required. Recording a payment you made at your own bank needs none.
Not in this release
Section titled “Not in this release”Sending money through a payment gateway, tracking what a creator owes the platform, and accounting exports are planned for later versions. Payouts can be recorded and reversed; pending and failed payouts exist in the record for the send-money path but cannot be reached yet.