# Payment review lab

A runnable, deliberately bounded code review example for Null Review.
Python standard library, a real temporary SQLite database, HMAC signatures,
transactional ledger entries, eight concurrent callback handlers and two
concurrent withdrawals. No external services or real payment data.

Run from this directory:

```sh
python3 -W error::ResourceWarning -m unittest -v test_payments.py
```

The suite contains 10 tests. Three `before` tests confirm a known defect:
1. A failure between a committed credit and its deduplication entry makes a
   retry credit twice: 10000 -> 11000 -> 12000 minor units for one 1000 event.
2. Two withdrawals both read a balance of 10000 and each reserve 8000.
   Both succeed and the balance is -6000.
3. An alpha caller can read the ledger of a known beta account because the
   statement query omits its tenant scope.

The `after` implementations are checked for transactional rollback, replay,
concurrent deduplication, changed-payload denial, signature rejection,
conditional debit and foreign-tenant denial. The successful suite includes
assertions that the deliberately defective implementations produce the
wrong result. It does not mean the `before` code is correct.

These are newly authored, executable examples, not a customer's production
code or a captured output of an AI review. No Null model run was performed
for them. The examples establish behavior of this code, not AI recall.

Scope: one process per connection, local SQLite transactions; the failure
is injected as an exception, not a process kill. The caller supplies an
already authenticated tenant. HTTP authentication, key rotation, multiple
currencies, actual PSP settlement, distributed databases and an outbox for
external payments are outside this lab. Withdrawal means an internal ledger
reservation, not a transfer sent to a bank. Do not deploy the deliberate
`before` methods.