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.