{
  "name": "Event Espresso 4 Customer Credit",
  "slug": "eea-customer-credit",
  "version": "0.2.1",
  "download_url": "https://gitea.mulligan.casa/ee-extensions/foh-updates/raw/branch/main/eea-customer-credit/eea-customer-credit-0.2.1.zip",
  "homepage": "https://gitea.mulligan.casa/ee-extensions/eea-customer-credit",
  "requires": "6.4",
  "tested": "7.0",
  "requires_php": "8.1",
  "last_updated": "2026-06-23 19:59:14",
  "icons": {
    "1x": "https://gitea.mulligan.casa/ee-extensions/foh-updates/raw/branch/main/eea-customer-credit/icon-128x128.png",
    "2x": "https://gitea.mulligan.casa/ee-extensions/foh-updates/raw/branch/main/eea-customer-credit/icon-256x256.png"
  },
  "author": "Mike Mulligan",
  "author_homepage": "https://gitea.mulligan.casa/mmulligan",
  "tags": [
    "event espresso",
    "store credit",
    "customer credit",
    "payments",
    "refunds"
  ],
  "sections": {
    "description": "<p>Customer Credit gives every Event Espresso customer a real store-credit <strong>account balance</strong> and a first-class <strong>\"Customer Credit\" payment method</strong> that moves that balance in both directions:</p>\n<ul>\n<li><strong>Refund into credit</strong> — recording a money-owed-back amount parks it as credit on the customer's account instead of issuing cash.</li>\n<li><strong>Pay with credit</strong> — recording a credit payment spends the balance toward an amount due.</li>\n</ul>\n<p>The balance is the audited side effect of recording a payment of this type, so credit always flows through Event Espresso's normal payment ledger.</p>\n<p><strong>Built for correctness:</strong></p>\n<ul>\n<li><strong>Atomic, oversell-safe balances.</strong> Each customer's balance lives in a counter guarded by a single conditional update, so a pay-with-credit debit can never drive a balance below zero even when several stations spend at once. A debit that exceeds the balance is refused, never silently clamped.</li>\n<li><strong>Fully ledgered.</strong> Every move writes an append-only audit row (customer, direction, amount, transaction, payment, clerk, timestamp). The balance is always reconstructable as the signed sum of the ledger, and the admin report flags any drift.</li>\n<li><strong>Email-keyed customers.</strong> Credit is matched to (or created on) Event Espresso's native customer record by email, so it follows the person across registrations.</li>\n<li><strong>Read-only admin report.</strong> Under <strong>Event Espresso → Customer Credit</strong>: every customer's live balance, the ledger-reconstructed total, and per-customer history.</li>\n</ul>\n<p><strong>Standalone, with an optional integration.</strong> Customer Credit works on a plain Event Espresso install through wp-admin. It also exposes a dependency-free filter seam so companion apps — such as <strong>Front of House for Event Espresso</strong> — can offer store-credit and pay-with-credit at the point of sale; the server enforces the same gates regardless of where the request originates. The integration is automatic when present and inert when absent.</p>\n<p>For full documentation, including the public filter contract and security model, see <code>README.md</code> included with the plugin.</p>",
    "installation": "<ol>\n<li>Install and activate Event Espresso.</li>\n<li>Upload this plugin to <code>wp-content/plugins/</code> and activate it. Activation creates the balance and ledger tables.</li>\n<li>(Optional) If you use Front of House for Event Espresso, activate this plugin so its presence is detected and store-credit options appear at the station.</li>\n</ol>",
    "faq": "<p><strong>Does this require Front of House for Event Espresso?</strong></p>\n<p>No. It is standalone on Event Espresso and is fully usable from wp-admin. Front of House is an optional consumer of its filter seam.</p>\n<p><strong>Where is the balance stored?</strong></p>\n<p>In two owned tables: a per-customer balance counter (the oversell guard target) and an append-only audit ledger. Money is stored in integer cents throughout. The counter must always equal the signed sum of the ledger.</p>\n<p><strong>Can a customer go negative?</strong></p>\n<p>No. A debit larger than the available balance is refused outright; it is never partially applied or clamped to zero.</p>",
    "changelog": "<p><strong>0.2.1</strong><br />\n* Migrate to the shared release pipeline; richer View-details modal (readme.txt sections, tags). No functional change.</p>\n<p><strong>0.2.0</strong><br />\n* Added a color-coded plugin icon (delivered through the update channel) and declared WordPress 7.0 compatibility. No functional change.</p>\n<p><strong>0.1.4</strong><br />\n* Updates are now handled by the Manifest Updater plugin (via the standard \"Update URI\" header) instead of a bundled updater. No functional change.</p>\n<p><strong>0.1.3</strong><br />\n* Money tables now use the InnoDB engine; existing installs are migrated (the ledger's atomic debit + idempotency key need row-level locking and transactions).<br />\n* The Customer Credit payment method self-heals if EE orphan-deactivates it (reactivates on load + at use time), so a credit move never carries a dead PMD_ID.<br />\n* The public credit seam is fully fail-closed: every filter callback catches unexpected errors and returns a structured envelope (loud-logged) instead of fataling the request.</p>\n<p><strong>0.1.2</strong><br />\n* Docs: corrected stale plugin-name references (eea-checkin -&gt; eea-foh). No code change.</p>\n<p><strong>0.1.1</strong><br />\n* Update channel + repository URLs moved to the ee-extensions org. No functional change.</p>\n<p><strong>0.1.0</strong><br />\n* Initial release: per-customer store-credit balances with an atomic, oversell-safe counter and an append-only audit ledger.<br />\n* Both-directions \"Customer Credit\" payment method (refund-into-credit and pay-with-credit).<br />\n* Email-keyed customer resolution and a read-only admin balances/ledger report.<br />\n* Dependency-free filter seam for optional point-of-sale consumers such as Front of House for Event Espresso.</p>"
  }
}