---
title: "Build a reconciliation ledger"
description: "A daily job that compares your database against BlindPay's payout, payin, and transfer statuses, catches drift, and alerts on stuck or mismatched money."
date: "2026-08-26"
category: "diagnostics"
products: ["payouts", "payins", "webhooks"]
---

Paste this prompt into your coding agent to build the safety net every money-moving integration needs: an independent daily reconciliation.

## Prompt

```text
You are building a reconciliation ledger for my BlindPay integration: a scheduled job that independently verifies my database agrees with BlindPay about every payment.

Before writing code, read these sources and follow them over any prior knowledge:
- https://blindpay.com/docs/llms.txt
- The OpenAPI spec: curl https://api.blindpay.com/doc (use it to find the list/get endpoints for payouts, payins, and transfers; do not guess paths)

Build:
1. A local ledger table if I do not have one: every BlindPay object I create (po_, pi_, tr_, qu_) stored with my own entity ID, amounts in minor units, status, and timestamps, written at creation time and updated only by verified webhooks.
2. The daily reconciliation job: page through BlindPay's records for the last N days via the list endpoints from the OpenAPI spec and diff against my ledger in both directions:
   - Objects BlindPay has that my ledger lacks (a create succeeded but my write failed).
   - Ledger rows BlindPay lacks or reports with a different status or amount (missed or unverified webhooks, manual dashboard actions).
   - Non-terminal statuses older than the rail's expected settlement window (stuck payments).
3. Output: a report per run (clean or discrepancies with IDs and both sides' values) plus an alert to my team channel when anything is found; never auto-correct money records, only flag them.
4. Idempotent healing helper: for the missed-webhook case, a command that re-fetches one object by ID and applies the true status through the same code path webhooks use, so fixes are audited.
5. Tests: seed a fake drift case of each type and assert the job catches all three.

Constraints: API keys server-side; the job must be rate-limit-polite (page, do not hammer) and safe to re-run; all comparisons in integer minor units.

Deliverables: ledger schema/migration if needed, the reconciliation job with report and alerting, the healing command, and the drift tests.
```

## How to use

1. Paste the prompt with your database schema and scheduler (cron, queue, or workflow engine).
2. Run it against your development instance history first; it should come back clean.
3. Treat any production discrepancy as an incident to root-cause, not just heal.

## Related docs

- [API reference](https://blindpay.com/docs/api/reference)
- [Webhooks](https://blindpay.com/docs/learn/webhooks)
- [Sandbox vs production](https://blindpay.com/docs/learn/sandbox-vs-production)