Payroll and Commitment Wallet
How direct deposit, payroll-linked funding, employee wallet visibility, and the Commitment Wallet fit into an enterprise rollout.
Payroll-linked wallet setup should remain visible beside queue and rollout health, not buried in finance-only screens.
The payroll lane should show whether payout rails are keeping pace with wallet adoption.
Employers can review payroll adoption, but the Commitment Wallet keeps its own password, biometric, and Continuity Key rules.
The workspace can explain the benefit clearly: funds can arrive directly into the employee's PayToCommit wallet, then move into commitment activity, payouts, and the rest of the wallet flow without extra manual steps.
That keeps wallet behavior understandable even when the employer is helping drive funding adoption.
That separation matters because payroll and commitment activity can intersect without turning the wallet into a generic employer-owned balance view.
Finance and operations teams should be able to read the same truth without guessing which line item belongs to the wallet, which belongs to the payroll rail, and which belongs to the employer agreement.
{
"organization_id": "org_northstar_logistics",
"payroll_program": {
"status": "active",
"default_wallet_destination": "commitment_wallet",
"direct_deposit_enabled": true,
"employee_opt_in_required": true,
"reporting_scope": "finance_and_operations"
}
}Payroll-linked funding is optional, employee-controlled where policy requires it, and still separated cleanly from normal wallet ownership.
Organizations can offer direct deposit into the Commitment Wallet as an optional payroll-connected path where policy and provider support allow it. This is an onboarding and payroll choice, not a forced requirement for employees.
The workspace can explain the benefit clearly: funds can arrive directly into the employee's PayToCommit wallet, then move into commitment activity, payouts, and the rest of the wallet flow without extra manual steps.
Payroll-linked wallet funding should feel like a clean extension of the normal PayToCommit wallet, not a separate banking app hidden inside the product. Employees can review available balance, funding timing, payout rules, and payroll-linked activity from the same wallet surface.
That keeps wallet behavior understandable even when the employer is helping drive funding adoption.
The Commitment Wallet remains distinct from basic account login. Employers can support payroll-connected funding and organization markets, but the wallet still follows the published continuity-key, access, and recovery rules.
That separation matters because payroll and commitment activity can intersect without turning the wallet into a generic employer-owned balance view.
The enterprise workspace can review payroll-linked adoption, funding usage, and any approved organization program that shares value back to the company under the commercial package. Those views stay explicit about what is payroll, what is platform fee, and what belongs to the employer program.
Finance and operations teams should be able to read the same truth without guessing which line item belongs to the wallet, which belongs to the payroll rail, and which belongs to the employer agreement.
The enterprise workspace can review payroll-linked adoption, employee funding usage, and organization-level revenue share or fee views where those commercial rules are enabled.
Reporting should stay explicit about what is platform fee, what is payroll-linked settlement, and what belongs to the employer's commercial package so the flow remains understandable for both finance and operations teams.