Privacy and security

Gamification treats balances, ledger provenance, provider identifiers, and member activity as application data—not decorative profile metadata. Start private and publish only the surfaces a site genuinely needs.

Member visibility

Full member history is private by default. A profile or public member surface requires explicit activation, a viewer policy, and an administrator point-type allow-list. Members can opt out of eligible public leaderboard and profile presentation where the configured surface supports that choice.

Public responses omit internal UUIDs, provider object IDs, private metadata, idempotency keys, and private ledger history. Optional activity summaries contain only normalized display fields. A visitor must never receive transaction provenance merely because the member has a public profile.

Test each enabled surface while signed out, as the profile owner, as another member, and as an administrator. Do not infer privacy from an administrator-only preview.

Mutation permissions

WordPress capabilities and REST nonces protect browser mutations. Server integrations must also pass a stable idempotency key, a reason, an actor, and the intended member and point type. Only trusted administrators or reviewed service code should receive award, event-ingestion, reporting, migration, or Gamification-management capabilities.

Never expose an unrestricted award endpoint through a shortcode, public form, terminal alias, or generic MCP command. The public presentation layer is read-oriented; sensitive mutations stay in permission-checked administration, REST, or PHP workflows.

Provider synchronization

myCred and GamiPress synchronization stores allow-listed provenance and SHA-256 hashes rather than raw provider payloads. Provider mapping, direction, and conflict policy are administrator configuration. Begin with preview/report-only mode, verify a small account sample, and retain the generated audit report.

Deactivating a provider pauses its adapter without advancing a checkpoint. Do not delete mappings or invent new origin identifiers to force a retry; resume the same reviewed job so idempotency protection remains effective.

Retention and recovery

Deactivation and license expiry preserve ledger and earned data. Removing or changing a posted transaction is intentionally unsupported; create a reversal with a reason. Back up the WordPress database before migrations, reconciliation writes, or bulk configuration changes, and test recovery on staging.

Deleting the plugin should be treated as a deliberate data-retention decision. Export the required configuration and reports first, then follow the uninstall policy shown in the plugin rather than deleting database tables manually.