# Payments: a payout flow that is provider-ready, and a mock today Continuing from [A first payroll run, reviewed and approved by someone else](https://docs.blueonehr.com/books/enterprise/page/a-first-payroll-run-reviewed-and-approved-by-someone-else): once a month's payroll is approved, the money has to reach people. This page says plainly what BlueOneHR does about that today and what is **payment provider ready** but **not live**. The Payout module here is a **demonstration flow**: it runs against a **mock** provider. No bank or payment provider is contacted, no real money moves, and no real bank account is used. *Illustrative demonstration prepared using publicly available company context and synthetic data. This page does not represent a production deployment, customer endorsement, or use of real employee data.*

Payments: a provider-ready payout flow, run against a mock provider

## The company this page follows Same illustrative demo structure as the rest of this book: one fictional company, Meridian Interiors. Its name, its people, every amount and every account number shown are synthetic. The two bank accounts used are made-up numbers; none belongs to a real person or a real bank. ## The flow, step by step 1. **An approved payroll run.** A payout batch can only be prepared from a payroll run that has already been approved. It cannot be prepared from a draft or pending run. 2. **Payout instructions.** Each person who has an approved, validated beneficiary gets one payout instruction. Its amount is a snapshot of the person's net pay taken when the batch is prepared, written to two decimal places (paise). Someone with no approved beneficiary is skipped and listed, and does not stop the rest of the batch. 3. **Two people approve.** The person who prepared a batch never approves it. A member of the company's payout approver group does. The same rule applies one level down: a beneficiary (the person's bank details as registered for payout) must be approved by someone other than the person who added it. 4. **The provider adapter.** Approved instructions are handed to a provider adapter, a fixed interface that every provider sits behind. Each instruction carries its own idempotency key, so submitting the same instruction twice does not create a second payment. 5. **The bank or payment provider.** In this workspace the adapter talks only to a **mock** provider. The provider names that a real integration would use are listed in the product's provider registry, but they are not configured, and they refuse to run rather than fake a success. Mock operation is also enforced in the database: every beneficiary, batch and instruction row is stored as mock. 6. **The response.** The provider answers with a state for each instruction. If the answer is lost or ambiguous, the instruction becomes **Unknown**. An unknown instruction is settled only by asking the provider for its status; submitting it again is refused. A failed instruction is retried as a new instruction that needs a fresh approval, never resent as it was. 7. **Reconciliation.** Reconcile compares the batch's own ledger with the provider's statement, instruction by instruction, on amount and status. A batch becomes **Reconciled** only when every instruction has settled. Anything not settled is reported as a mismatch for a person to look at, never corrected automatically. ## What the Payout screens show The **Payout** page has two tabs, **Batches** and **Beneficiaries**. It states "MOCK provider only -- no real money moves." The **Batches** tab lists batches with reference, period, status, instruction count and total. A batch page shows its instructions (beneficiary, masked account, amount, state, and UTR, which stays empty until a provider settles), the reconciliation results, and an audit trail of every step. Account numbers are masked everywhere. Revealing one is permission-gated and is itself recorded in the audit trail. In the example, one batch for the November run was prepared, approved by someone other than the person who prepared it, and submitted to the mock provider. Both payments then show **Pending**: the mock provider does not settle them, so reconciling reports two matched and two mismatches, and the batch stays **Submitted**. ## What this page does and does not claim - The flow is **payment provider ready**: the adapter contract, the approvals, the status handling and the reconciliation exist and run against a mock. - Nothing here is **live**. No bank or payment provider has been connected, and no payment has been executed through a real rail. - No real bank account number appears on this page or in the video; the accounts used are synthetic. - Preparing a batch is a service action, the same one Mitra's prepare step uses. The Payout page is where a prepared batch is reviewed, approved, submitted and reconciled. ## Related reading - [A first payroll run, reviewed and approved by someone else](https://docs.blueonehr.com/books/enterprise/page/a-first-payroll-run-reviewed-and-approved-by-someone-else) - [India payroll compliance: a monthly run and a governed correction](https://docs.blueonehr.com/books/enterprise/page/india-payroll-compliance-a-monthly-run-and-a-governed-correction) - [Running payroll](https://docs.blueonehr.com/books/payroll/page/running-payroll)