Begin with an agreed record of the pay run
A payroll-card rollout is not finished when employees hold cards. A wage instruction must travel from the employer’s approved payroll to the provider and ultimately to the account. Treat pay calculation, destination assignment, file acceptance, funding and account credit as separate checkpoints. No public Fintwist page verifies your company’s exact integration, file format or cutoff; request that information from the provider and payroll vendor for the contracted program.
The distinction helps triage. A correct pay statement does not demonstrate that a file was accepted; an accepted file does not, by itself, prove that the receiving account is usable. Avoid presenting a success screen as an end-to-end guarantee.
WATCH & UNDERSTAND · 28 SECONDS
The payroll handoff has five checkpoints
Original visual explainer · silent · no autoplay
A silent diagram separating approved wages, destination, accepted instruction, funding and account receipt. This is an editorial illustration, not a provider tutorial or a recording of an account. Video files are served by this website.
Read the full video explanation
- Checkpoint 1. Approved wages. A pay statement records the employer calculation; it is not account proof.
- Checkpoint 2. Destination assigned. The selected method must match the effective payroll instruction.
- Checkpoint 3. Instruction accepted. A rejected record needs an owner and an authorized resolution.
- Checkpoints 4 and 5. Funding and receipt. A sent batch and a usable deposit are separate observations.
Source context: Corpay Prepaid: PayCard overview. The visual arrangement and hypothetical examples are editorial explanations.
Build a reconciliation table
For each pay run, track expected employee count, total net wages by delivery method, file count, accepted and rejected records, funding status, and resolved exceptions. Match these numbers to the actual reports returned by the payroll system and provider. Document who may correct a routing mistake and who may approve a replacement payment. Names of report fields and timestamps are implementation details; the categories are the reusable part.
Example: the employer approves 120 wage payments and sees 119 accepted recipient records. The important work is finding the one exception, preserving its reason and arranging wages under the employer’s procedure. Re-sending the whole batch without checking idempotency could cause a duplicate. This example is hypothetical and does not describe a specific Fintwist screen.
Test a rejected instruction before launch
Run through an invalid destination, a late enrollment and a worker who switches pay method just before cutoff. Each test should identify where an error becomes visible and what evidence payroll keeps. Ask the provider which rejects are returned immediately, which are delayed, and whether a correction uses a new instruction. Until the answers are confirmed, mark those steps as unresolved in the runbook.
For onboarding inputs, minimize copies of personal information. HR does not need a worker’s card PIN, security answers or app password to establish that wages were calculated. A case ID and appropriate employer payroll record are usually the safer starting point. The support guide shows how to route account issues.
Keep a human owner on payday
A morning dashboard can look green while one employee has no usable wages. Give the employee a single employer contact for pay amount and delivery, and define a provider contact for card access. Set an escalation schedule on payroll dates, including weekends or holidays when the team actually operates. Do not describe the provider’s public support availability as a promise about employer funding or payroll cutoffs.
After each incident, compare the wage record, accepted instruction and account-related confirmation without exporting unnecessary card details. Record the cause and a prevention change. Pair this with the pilot plan before broad rollout.
A timeline for an exception
Suppose a worker reports missing pay on payday. At 9 a.m. payroll confirms approved net wages. At 9:15 a.m. it verifies which destination was effective when the run closed. Next it checks the provider’s acceptance record and the employer’s funding record. This order helps isolate the failure without asking the employee to reveal account credentials. The timeline is illustrative; real reporting and cutoff windows must come from the contracted parties.
A “success” response may apply to one checkpoint only. The payroll vendor could accept a file while a recipient record is rejected downstream. A provider could acknowledge an instruction before funds are available. Label each stored status by the boundary it proves and avoid renaming every green indicator “paid.” Have the escalation guide say who can see each record and which team may correct it.
When a correction is needed, pause before resubmitting the original batch. Ask whether the first instruction is still pending, whether a replacement will create a duplicate and whether any wage deadline requires an alternate route. Document a case-specific decision and reconcile the resulting entries. This site cannot authorize a payment or tell a particular worker when money will settle.
When the numbers appear to match
Before declaring a pay run complete, compare totals in both directions: approved wages against delivery instructions, and accepted instructions against the run you meant to send. Record the exception count and resolution separately from the overall total. A matching grand total can hide an omitted recipient offset by a duplicate. If your reports do not contain enough detail to make that comparison, ask the vendor what reconciliation evidence can be provided under the agreement. A worker-facing message should state what the employer has verified and what remains under investigation. It should never imply that a bank or card account was credited solely because an employer file was produced.