How CreditKit Pro scores a credit transaction for fraud
CreditKit Pro scores every credit transaction from 0 to 100 before the ledger is written. Two scores are enforced: a baseline of 75 asks the customer for extra verification, and a baseline of 90 refuses the transaction. Five weighted factors produce the score — amount at 30 percent, velocity at 25 percent, behaviour at 20 percent, account at 15 percent, context at 10 percent. The Security Level setting multiplies both enforced scores at comparison time, so 75 and 90 are baselines rather than the numbers a given store runs on. This page describes version 2.2.0 as shipped.
Scoring runs on the pcs_validate_credit_transaction filter, which fires before a credit grant, a credit spend and a refund claw-back. A transaction of type refund_credit skips the screener, because administrator-issued goodwill credit carries no customer-side risk signal. The master switch is Enable Fraud Detection on Credit System → Security, shipped on.
What the five factors measure
| Factor | Weight | What raises the factor score | Highest factor score |
|---|---|---|---|
| Amount | 30 percent | Over 10× the customer’s average spend: 40 points. Above 500 credits: 30 points. Account under 30 days spending over 100 credits: 35 points. | 100 |
| Velocity | 25 percent | 5 transactions in 5 minutes: 50 points. Over 20 in an hour: 30 points. | 80 |
| Behaviour | 20 percent | A 02:00–06:00 spend by a customer whose night spending is under 10 percent of normal: 20 points. A day above 3× that customer’s daily average: 25 points. | 45 |
| Account | 15 percent | Account under 7 days old: 30 points. No pcs_email_verified flag: 20 points. | 50 |
| Context | 10 percent | Device fingerprint outside the last 5 seen: 15 points. New request IP: 10 points. | 25 |
Each factor is scored 0 to 100 on its own signals, multiplied by its weight, then added to a total clamped to 0–100. A factor moves the total by its weight at most, so one extreme signal rarely reaches an enforced band alone. The rightmost column is the highest score each factor reaches in version 2.2.0.
What happens at each score
| Band | Baseline | On Low | On Balanced | On High | Response | Governing option |
|---|---|---|---|---|---|---|
| Low, then medium | 25, then 50 | n/a | n/a | n/a | None | None |
| High | 75 | 97.5 | 75 | 52.5 | Refused as verification_required; the transaction waits 3600 seconds for verification. | fraud_require_verification |
| Critical | 90 | 117 | 90 | 63 | Refused as transaction_blocked; pcs_fraud_alert fires and a fraud.flagged webhook is dispatched. | fraud_auto_block |
The low band of 25 and the medium band of 50 are declared in the source and read by no code in version 2.2.0, tests included. Both are labels rather than triggers.
The critical band also suspends the account, on a cooldown defaulting to 86400 seconds. A pcs_unsuspend_user cron event then re-scores the customer and releases the suspension below the effective high threshold. A daily sweep on pcs_daily_risk_assessment re-scores everyone who transacted in the past 24 hours and stores the result in the pcs_daily_risk_metrics user meta key.
How the Security Level changes the thresholds
Security Level is a three-way radio on Credit System → Security, shipped set to Balanced. Balanced is the calibration baseline at a multiplier of 1.0. A multiplier above 1.0 raises the bar; a multiplier below 1.0 makes CreditKit Pro act sooner.
| Security Level | Risk multiplier | High threshold | Critical threshold | Spending-limit multiplier |
|---|---|---|---|---|
| Low | 1.3 | 97.5 | 117 | 2.0 |
| Balanced | 1.0 | 75 | 90 | 1.0 |
| High | 0.7 | 52.5 | 63 | 0.5 |
Worked example on High: 75 multiplied by 0.7 gives an effective 52.5, and 90 multiplied by 0.7 gives an effective 63. Because the total is clamped at 100, the Low level’s effective critical threshold of 117 sits above the highest score CreditKit Pro can produce, so a store on Low never auto-blocks. The baselines of 75 and 90 are not editable from wp-admin; both live in the pcs_fraud_settings option.
Turning each response on or off
The two enforced responses are independently switchable under Actions on High Risk. “Automatically block high-risk transactions” writes fraud_auto_block; “Require additional verification for suspicious transactions” writes fraud_require_verification. Both ship on.
Clearing fraud_auto_block puts the critical band into flag-not-block mode. CreditKit Pro still raises the fraud alert, dispatches fraud.flagged with a disposition of alerted, runs the suspension path and writes a critical_risk_block_skipped row, then lets the transaction complete. Clearing fraud_require_verification writes a high_risk_verification_skipped row and lets a high-band transaction through unchallenged. A third control, Notification Threshold, ships at 70 and gates the administrator email only.
What the fraud.flagged webhook contains
CreditKit Pro dispatches fraud.flagged whenever a transaction reaches the effective critical threshold, whichever way fraud_auto_block is set. Delivery is throttled to one fraud.flagged per customer per 60 seconds, so a scripted burst cannot flood a SIEM endpoint. These fields sit in the envelope’s data object.
| Field | Value |
|---|---|
user_id | Flagged customer’s WordPress user ID. |
attempted_amount | Credit amount screened. |
risk_score | Float, 0 to 100. |
disposition | blocked with auto-block on, alerted with it off. |
direction | spend or add. |
reason | critical_risk_transaction. |
factors | Sub-scores keyed amount, velocity, behavior, account, contextual. |
Signing, retries and subscription management are covered in the webhooks guide.
Where to see and act on flags
Every scoring decision is written to the wp_pcs_fraud_log table, as a risk_assessment row per screened transaction plus rows such as high_risk_detected and auto_unsuspended. Version 2.2.0 ships no admin screen over that table, so reading it means a SQL query or a log shipper; the webhook is the supported route into a monitoring tool.
Suspended customers do appear in wp-admin, on the Blocked Users tab of Credit System → Security, where an administrator lifts the suspension. A suspended customer cannot pay with the Pay with Credits gateway. Alert emails go to the address on the Security Alerts tab, falling back to the WordPress admin email.
What this doesn’t do
CreditKit Pro calls no external fraud service and runs no machine-learning model. Every score is computed on the store’s own server from the wp_pcs_credit_transactions ledger, user meta, request headers and request IP, so no customer data leaves the site for scoring. The low and medium bands trigger nothing, so a score of 60 on a Balanced store produces a log row and nothing else.
The engine scores credit-ledger movements rather than card payments. Chargeback handling and 3-D Secure belong to the payment gateway that sold the credits, and CreditKit Pro reads no card-network risk signal. Geolocation is declared in the settings array and never evaluated, and the device signal is a hash of three request headers rather than a browser fingerprint, so a customer switching browsers registers as a new device. A store that wants the enforced bands to engage on ordinary traffic should set Security Level to High, where the bands sit at 52.5 and 63.