Every WooCommerce credit feature, with the receipts.
CreditKit Pro is one WordPress plugin doing eight jobs — plus an optional Groups & Budgets module: a WooCommerce product type for bundles, an atomic credit payment gateway, goodwill store credit on refunds, five-factor fraud scoring, a documented REST API and signed webhooks, an admin-attributed audit log, and an hourly reconciliation cron that catches drift before you do. The rest of this page is the proof, not the pitch.
// what’s in the box
Eight pillars, one plugin — plus an optional module.
No add-ons, no Pro-of-the-Pro tier, no “contact us for pricing.” Everything below ships in the same WordPress plugin folder and runs on the WooCommerce you already have.
Credit bundles
Custom WooCommerce product type with expiry, bonus, and usage scoping.
Atomic gateway
Pay fully in credits. Atomic spend, snapshots, rollback.
Goodwill refunds
A rate you set, an issuance log on the order, a refund.restored webhook.
Fraud scoring
5 weighted factors, 4 thresholds, 3 presets, 24h cooldown.
REST API
21 routes under pcs/v1, three auth modes, rate-limited.
Signed webhooks
18 events, HMAC-SHA256, idempotent envelope.
Audit & backups
Signed log, hourly snapshots, 90-day retention, drift cron.
Account widget
My Account tab, five shortcodes, expiring credits view.
Groups & Budgets
Optional module: teams, hard budgets, manager approvals, allowances, reports.
// pillar 01 — bundles
A real WooCommerce product type, not a coupon hack.
WC_Product_Credit_Bundle extends WC_Product, declares HPOS compatibility via FeaturesUtil::declare_compatibility, and stores everything in native WooCommerce meta. Your reports, your taxes, your exports — they all keep working.
| Bundle | Credits | Bonus | Expiry | Price | Scope |
|---|---|---|---|---|---|
| Starter | 4 | 0 | 90 days | $119.79 | general |
| Small | 10 | 1 | 180 days | $289.50 | general |
| Standard | 20 | 3 | 365 days | $549.00 | general |
| Pro | 35 | 7 | 365 days | $899.00 | products |
| Team | 50 | 12 | 365 days | $1,249.00 | services |
| Enterprise | 80 | 25 | 730 days | $2,032.80 | subscription |
// pillar 02 — gateway
A WooCommerce gateway that treats credits like money.
PCS_Credit_Payment_Gateway registers as gateway ID credits and behaves like every other WooCommerce gateway — checkout block, settings tab, order notes, refund integration. The difference is what it spends. A card gateway moves currency; this one moves credits from the customer’s balance. It is all-or-nothing by design: an order is either covered entirely by the customer’s credit balance, or it is paid another way.
- Three modes per store: money-only, credits-only, or either.
- Pays the full order in credits in one atomic operation — the balance check and debit can’t race or oversell. No credit-plus-card split.
- If the balance doesn’t cover the order, the credit gateway isn’t offered — the customer tops up first.
- Pre- and post-transaction snapshots via
PCS_Backup_Recovery— every payment is reversible. - Refunds flow back through the same gateway, not a separate manual adjustment.
// pillar 03 — refunds
Refunds return credits at a rate you set.
Refunding a credit-paid order returns credits automatically, in proportion to the amount refunded. Goodwill issuance is a separate manual action on money-paid orders.
PCS_Refund_Credit adds an HPOS-compatible meta box to every WooCommerce order. Set the Goodwill credit rate once in Settings → General (stored as refund_credit_rate), and every refund logs its issuance to _pcs_refund_credit_issuances on the order itself. The refund.restored webhook fires the moment the credits are issued — your accounting system gets notified without you opening a ticket.
// pillar 04 — fraud
A safety net with five factors, not a black box.
PCS_Fraud_Detection scores every credit transaction on five weighted factors. You see the weights. You set the preset. You read the score in the fraud.flagged webhook. No model card, no vendor lock-in.
Amount risk
Outlier vs user average, absolute limits, new-user protection.
Velocity
5-minute transaction cluster, hourly threshold breaches.
Behavioral
Anomalous time windows (2–6 AM), daily deviation from baseline.
Account
Account age, lifetime transaction history.
Contextual
Temporal and geographic signals.
Critical-block triggers a 24h auto-suspension cooldown. Clear it manually from the admin or wait it out — both are logged via the user.suspension_cleared webhook.
// pillar 05 — rest api
Twenty-one endpoints, three auth modes, one namespace.
Every operation in the WordPress admin is also a pcs/v1 REST call. Authenticate with an API key, a Bearer token, or the standard wp_rest cookie. Errors come back in one normalized shape: {success: false, error: {code, message, data}}.
$ curl https://yourshop.com/wp-json/pcs/v1/credits/me -H "Authorization: Bearer $TOKEN" { "success": true, "data": { "user_id": 42, "balance": 215, "pending": 0, "expiring_next_30d": 12 } }
// pillar 06 — webhooks
Eighteen events, signed.
Every webhook is dispatched through PCS_Credit_Manager::trigger_webhook() and the pcs_webhook_dispatch action. HMAC-SHA256 signed. Envelope v2025-01-01: api_version, event_id (UUIDv4), timestamp (Unix epoch), data.
// Headers X-PCS-Event: credit.spent X-PCS-Event-Id: 7c5f2a1b-9d3e-4f1a-b8c2-1e4d6f8a2c91 X-PCS-API-Version: 2025-01-01 X-PCS-Signature: sha256=a7b9c2e4f1d8... // Body { "api_version": "2025-01-01", "event_id": "7c5f2a1b-9d3e-4f1a-b8c2-1e4d6f8a2c91", "event": "credit.spent", "webhook_id": 11, "timestamp": 1747000000, "data": { "user_id": 42, "amount": 25, "balance_after": 190 } }
| Event | Fires when | Sample data field |
|---|---|---|
| credit.added | Credits land in a user balance for any reason. | balance_after |
| credit.spent | A user’s balance decreases via the gateway or API. | context |
| credit.expired | The expiry cron writes off credits past their TTL. | credits_expired |
| bundle.purchased | A WooCommerce order containing a bundle is paid. | bundle_id |
| refund.restored | A WooCommerce refund restores credits to a balance. | transaction_id |
| fraud.flagged | The fraud scorer crosses any threshold. | factors |
| user.suspension_cleared | The 24h cooldown ends or an admin lifts the block. | target_user_id |
| ip.block_cleared | An IP-level block expires or is manually cleared. | ip |
| order.paid | A WooCommerce order using the credits gateway completes. | order_id |
// pillar 07 — trust
An audit log that remembers who, what, and when.
PCS_Security::log() writes every state change to pcs_security_log with actor user ID, IP, and a content hash. PCS_Backup_Recovery runs hourly, daily, and weekly snapshots. The pcs_integrity_check cron flags drift before your accountant finds it. 90-day retention, 11 tables, all prefixed wp_pcs_*.
// pillar 09 — groups & budgets (optional module)
Run credits for a whole team, not just one wallet.
Clubs, schools, and companies get an optional module that organises members into teams with shared budgets, manager-approved credit requests, and recurring allowances. It ships off by default — flip it on under Settings → Features when you need it, and a single-user shop never sees it.
For managers
- Hard budget enforcement — a team can never spend past its allotted budget.
- Manager-approved credit requests — members ask, managers approve or decline in an approval workflow.
- Recurring allowances — top each team up automatically on a schedule.
- Team & volume discounts — reward larger teams and bigger top-ups.
- Reports + CSV export — store and per-team reports with date-range and column selection, exportable to CSV.
For members
- Self-service requests — drop the
[pcs_credit_request]shortcode on any page and members request credits themselves. - My Account tab — members see their team, budget, allowance, and pending requests right in WooCommerce My Account.
- One ledger underneath — every approval, allowance, and team spend is still a signed row in the same audit trail.
// faq
Features people actually ask about.
Does CreditKit Pro need a separate database or service?
No. Eleven tables on your existing WordPress database, prefixed wp_pcs_*. No external service, no SaaS dependency, no outbound call unless you configure a webhook URL.
Will it work with HPOS (High-Performance Order Storage)?
Yes. The plugin declares custom_order_tables compatibility via FeaturesUtil::declare_compatibility, and the refund meta box, gateway, and order hooks all read through the WooCommerce order CRUD — not wp_posts directly.
Can a customer pay partly in credits and partly on a card?
No. The credit gateway is all-or-nothing: an order is paid in full from the credit balance, or it isn’t paid with credits at all. If the balance doesn’t cover the order, the gateway simply isn’t offered — the customer can top up first. There is no credit-plus-card split.
Where do I plug in my own fraud rules?
The fraud.flagged webhook ships the full five-factor breakdown. Subscribe, decide, and call POST /credits/spend with a reversal or user.suspension_cleared via the admin. The scorer is deterministic and inspectable — no opaque model.
What happens if a webhook delivery fails?
The event is logged with its event_id and signature so you can replay it manually from the admin. Automatic retry with exponential backoff is on the roadmap for v2.2 — we’d rather ship it correctly than half.
Is there a sandbox or a test mode?
WooCommerce Payments dev mode covers checkout, and the REST API accepts a wp_rest cookie from a logged-in test user, so you can drive the full credit lifecycle from a staging WordPress install without touching production keys.
Built for shops, clubs, schools, and events that count things in credits.
One WordPress plugin. One WooCommerce install. 21 endpoints, 18 webhooks, 11 tables, and an audit log that survives your next accountant.