ENGINEERING NOTE 41 / 50 · CARD
Separate card support permissions from money movement
Reading a transaction, revealing sensitive details and moving money are different capabilities. Give each role only the actions required for its work.
Published by OPEN RAMBO. The engineering patterns and pseudocode illustrate designs, not a documented product API. Numerical examples are illustrative.
Model actions explicitly
Avoid a single is_admin switch for every operation. Define read, export, freeze, load and adjustment capabilities with tenant scope. A support user may need a masked transaction timeline while having no ability to alter balances.
Check on the server
Hiding a button is not authorization. Every endpoint needs permission and ownership checks. Background jobs and internal service calls also need a constrained identity so a compromised integration cannot act as an unrestricted administrator.
Audit high-impact actions
Record the actor, reason, target and result for high-impact operations. Where the business requires dual control, enforce it as a workflow rather than a note in a handbook. Review access when staff roles change and expire temporary permissions.
Illustrative implementation
authorize(actor, action="card.freeze", tenant=card.tenant_id)
record_audit(actor, safe_card_ref, reason)
execute_authorized_action()Acceptance check
Test each role against each endpoint, including direct requests to actions hidden in the interface.