Corporate Portal
Design recommendation for the corporate self-service portal — the web console a corporate customer (our B2B customer) uses to manage cards, assign them to employees, fund spend, and report. It builds on the card activation flows and security model. Screens and endpoints are illustrative.
The portal is the corporate customer's control plane over the xperise payment system: it is where a company chooses its operating model — employees spend against a monthly limit or a cost center (one or the other, never both) — funds the company wallet, allocates card balances, and sees every spend reconciled. It sets both layers of the two-layer model: the spending authority (Layer 1) and the funding source (Layer 2).
Personas & roles (RBAC)
The portal is role-based — a corporate account has multiple admins with least-privilege roles, plus employees who are cardholders (employees self-serve in the app, not this portal).
| Role | Can do | Typical user |
|---|---|---|
| Company super admin | Everything: manage admins, funding, org settings; the account owner | Finance lead / owner |
| Card manager | Order, assign, freeze, replace cards; set limits within policy | Ops / office manager |
| Finance / approver | Approve issuance, limit increases, top-ups; view spend; reconcile & export | Finance team |
| Auditor (read-only) | View reports, statements, and the audit log — no changes | Internal audit |
| Employee (cardholder) | In the app, not the portal: view own card, freeze, see transactions | Staff |
Separate card manager (requests) from finance/approver (approves) so no single admin can issue a card and raise its limit and fund it unchecked. This mirrors the maker-checker pattern used in Approvals.
What the portal manages — core modules
1. Organization & admin setup
Business onboarding/KYB, company profile, departments / cost centers, admin invitations with RBAC roles, SSO (SAML/OIDC), and admin MFA.
2. Employee directory
Add employees individually, bulk CSV import, or auto-sync from HR/HRIS (SCIM). Each employee has a department, cost center, and manager. Offboarding an employee automatically freezes their cards (see the offboarding flow).
3. Card management (lifecycle)
Issue cards in physical and/or virtual (in-app) form — a card can be both; order physical cards
in bulk or issue virtual cards instantly; set each card's CVM (PIN or OTP) and funding source
(company wallet or none); view the card inventory by
status (ISSUED / ASSIGNED / ACTIVE / FROZEN / LOST / EXPIRED); freeze/unfreeze, replace,
reissue, cancel, and report lost/stolen — all reflected in the shared
card lifecycle. See the full
Card Management spec for per-function detail (hard cap on cards per
employee, physical/virtual, periodic balance reset, reclaim-to-wallet).
4. Card assignment
Assign a card to one employee or leave it unassigned (a bearer card):
- To an employee (single or bulk) →
ASSIGNED; the card inherits all the employee's cost center(s) and stays in sync (the default one is used for card payments; picker hidden); final activation uses the employee-claim (recommended) or admin full-activation path from card activation. - Unassigned (bearer) → anyone with the card + PIN can use it; optionally link one cost center; admin activates directly. Best for shared/pool cards with a low balance and tight limits.
Reassign or unassign at any time (frozen first; balance reclaimed to wallet by default).
5. Operating model & spending authority (Layer 1)
Choose the company's operating model — monthly limit or cost center, never both — and set the values (see Spend controls below):
- Monthly limit per employee (resets monthly), or
- Cost center budgets employees are assigned to (reset by period or manual top-up).
Separately, each xperise card carries a card balance with a configurable reset (a day of the month, or no reset with manual top-up; top-up is always available); it applies to card payments on top of the chosen model.
6. Funding (Layer 2) & company wallet
Manage the company wallet (the real balance) and its assigned company credit line (resets ~monthly). Top up the wallet by bank transfer, monitor balance, set low-balance alerts, and enable credit-card funding via 2c2p where the operating model allows it. A card's funding source is optional — company wallet or none (an unfunded card's balance is stored value).
7. Approvals
Maker-checker workflows for issuance, limit increases, and large top-ups — see Approvals.
8. Transactions & reporting
Real-time spend feed filterable by employee / department / card; statements; CSV/PDF export; budget-vs-actual per cost center; and reconciliation. Feeds naturally into the xperise expense workflows so card spend becomes reportable expense.
9. Audit & security
Immutable audit log of every admin action, admin MFA, session management, and optional IP allowlisting — see Security & audit.
Key flows
Flow 1 — Onboard the organization
Flow 2 — Add employees (bulk / HRIS)
Flow 3 — Order & assign cards, then activate
Flow 4 — Offboarding (auto-freeze)
Cost-center sync also runs at a finer grain: when an employee is removed from a cost center, their assigned cards are unlinked from that cost center automatically (the card inherits the employee's cost-center membership). Bearer cards are unaffected — their optional single cost center is set on the card itself.
Spend controls
Spending authority is assigned per the company's operating model and attached to an employee, a group, or a department — so onboarding a new hire is "assign card + apply the Sales team policy." Every payment decrements the applicable Layer 1 bucket and the Layer 2 funding source (see the two-layer model).
Layer 1 — spending authority
The company runs monthly limit or cost center — never both. Card balance is separate: it applies to xperise-card payments on top of the chosen model.
| Instrument | How it resets | Applies to |
|---|---|---|
| Monthly limit (model A) | Automatically each month | An employee |
| Cost center (model B) | After a configured period, or manual top-up to a new limit | A shared team / department budget |
| Card balance (cards, either model) | Configurable: reset on a day of the month, or no reset (manual top-up). Top-up always available. | A specific xperise card |
When the company runs the cost-center model, an xperise-card payment draws both the card's card balance and the assigned cost center. Layer-2 funding for the card is optional — the company wallet, or none (the card balance is then stored value).
Layer 2 — funding
| Source | Notes |
|---|---|
| Company wallet | Real balance + assigned company credit (resets ~monthly). Funds wallet, QR, and wallet-funded xperise-card payments. |
| Credit card (2c2p) | External card charged via 2c2p; funds credit-card payments (the company wallet is not drawn). |
| None (stored-value card) | An xperise card can have no funding source — its card balance is the money; top-ups move real value onto the card. |
Additional guardrails
| Control | Example |
|---|---|
| Amount limits | Per-transaction / daily caps on top of the Layer 1 bucket |
| Allowed vendors | Restrict to specific xperise vendors or categories |
| Time windows | Business hours / working days only |
| Channel rules | e.g. disallow manual-entry (card-not-present); require step-up above a threshold |
| Freeze on inactivity | Auto-freeze cards unused for N days |
Changes that loosen a control (raise a limit/balance, add a vendor, add a funding source) should route through approval; tightening can be immediate.
Approvals (maker-checker)
High-impact actions require a second admin to approve, enforcing segregation of duties:
Recommended approval triggers: new card issuance beyond a threshold, per-card limit increases, top-ups above an amount, and adding a new payout/funding source. Every decision is audit-logged with who, when, and why.
Transactions, reporting & reconciliation
- Live spend feed per card / employee / department, with receipts where captured.
- Statements & exports (CSV / PDF) per period and per cost center.
- Budget vs actual so a department lead sees remaining budget in real time.
- Reconciliation against the double-entry ledger (the system source of truth).
- Expense hand-off — card spend flows into the xperise expense workflows for approval and reimbursement/booking, so the portal doesn't reinvent expense reporting.
Security & audit
Inherits the platform security layers and adds portal-specific controls:
- RBAC + admin MFA on every admin; SSO (SAML/OIDC) for enterprise sign-in.
- Immutable audit log of all admin actions (assign, freeze, limit change, top-up, export).
- Maker-checker on high-impact actions; session management and optional IP allowlist.
- Least-privilege data access and controlled exports (auditor is read-only).
Recommended phasing
| Phase | Portal scope |
|---|---|
| 1 — Manage & assign | Org + admin setup (RBAC/MFA), employee directory (manual + CSV), card inventory, assign → activate, basic per-card limits, transaction feed, audit log. |
| 2 — Control & fund | Policy templates + department budgets, corporate wallet top-up & low-balance alerts, maker-checker approvals, CSV/PDF exports, budget-vs-actual. |
| 3 — Integrate | HRIS/SCIM auto-provisioning, SSO, expense hand-off, accounting/ERP export, webhooks/API for the corporate's own systems. |
Phase 1 delivers the core ask — manage cards and assign them to employees — on top of the existing card lifecycle; phases 2–3 layer on financial control and enterprise integration.
Related
- Card Payment — card lifecycle and the activation flows the portal drives.
- Security & Trade-offs — the layers the portal inherits.
- Overview — the ledger and account model behind corporate funding.