Security and Compliance
Who can do what
| Control | Where | Effect |
|---|---|---|
API_TNT_DM_CRM_MEMBERSHIP_CARD_HDR_READ / CREATE / UPDATE, with branch targets | Membership Admin → permission listings | Listing, create and edit of members; the listing shows only the branches in the user’s targets |
DISALLOW_EDIT_MEMBERSHIP_POINTS (setting) + ALLOW_EDIT_MEMBERSHIP_POINTS (client permission) | Membership Admin Field Settings; also on Customer Maintenance’s Membership tab | With the setting on, Point Transaction and Points Expiry rows are read-only except for holders of the permission |
EDIT_MEMBERSHIP_END_DATE | Membership Admin client permission | Only holders can change a member’s end date |
| Add Point Adjustment | Membership Admin member Details tab | Requires a branch, an item and a reason; written with source ADMIN_MANUAL_POINTS_ASSIGNMENT and a Display Type (DISPLAY / HIDDEN) so the member-facing history can hide it — it is never hidden from the applet |
POS_ALLOW_VERIFIED_MEMBER_REDEEM_POINTS | POS General | Only members with verification status VERIFIED may redeem at the counter |
| Balance check at FINAL | Backend | Redeemed points are validated against the balance when the bill finalises; a void that leaves the balance short adds a shortfall adjustment rather than a negative balance |
TNT_API_COUPON_*, TNT_API_COUPON_ENCRYPTED_SOFTPIN_READ / UPDATE | Voucher endpoints | Voucher CRUD, and separately the right to read or change a ticket’s soft pin |
| Softpin, Activation Pin, URL Key, Prefix | Voucher Management voucher form | Optional second secrets and serial patterns on tickets; the ticket edit screen shows URL Key and Activation Pin read-only |
There is no approval workflow on a point adjustment — the product’s approval engines cover
purchase orders, purchase and stock requisitions and claims, not membership. If two people must sign off a
large adjustment, the second person is the one holding ALLOW_EDIT_MEMBERSHIP_POINTS under a
DISALLOW_EDIT_MEMBERSHIP_POINTS setting; there is no amount threshold.
What is audited
- Membership Admin → Audit Trail: applet code, table, action, user, device, dates, for every member change; the member API writes old and new snapshots on update.
- Every point transaction line carries its source (
GenericDocumentPointUpdateProcessor,ADMIN_MANUAL_POINTS_ASSIGNMENT, the OCR and commission processors, the CSV import), the document and line it came from, Created By and the branch. - A voucher’s Audit tab and each ticket’s Ticket History (location, description, document, entity, quantity, amount, posting status).
- A
MEMBERSHIP_CARD_WEBHOOK_PROCESSORexists to push member changes to a webhook if you subscribe.
Integration security
External systems reach members and points through the platform API with the headers on the
authentication page; every endpoint has backoffice-ep, etl-ep
and where relevant login-entity-ep variants, and the only anonymous ones are the
membership-class/public-ep/query and membership-points-currency/public-ep/query reads and the
MLM invitation-acceptance flow. Give an integration its own access key and the narrowest
permission family.
What is not here
- No certification. This wiki does not state that BigLedger holds PDPA, PCI-DSS, ISO or any other certification, and no page in it should. Encryption at rest, key rotation and penetration testing are questions for your platform agreement, not features of the membership applets.
- No fraud engine: no velocity limits, no store-level issuance caps, no impossible-travel checks, no rotating QR codes. A voucher’s protections are its per-customer and daily limits, its rules, its soft pin and activation pin, and the fact that a serial is redeemed once.
- No member authentication in this module — member logins are the storefront’s, documented with CP Commerce.
- No points-liability accounting: outstanding points post nothing; a “liability” figure is a query, not a ledger balance.