Payment code is mostly failure handling, and a fixture of successful charges never touches it. Set the failure rate to twenty per cent and a fifth of your batch arrives as declines, insufficient funds and expired cards.
What you can control
- The failure rate is a direct control, so you can produce a batch that is mostly declines if that is the path you are testing.
- Refunds and chargebacks carry negative amounts, which is where sign handling in a ledger sum breaks.
- Three transaction mixes — retail, bank ledger and subscription billing — each with the columns that context needs.
- The time window spreads transactions over anything from a day to two years for testing date filters.
What this is not
Amounts convert at fixed indicative rates and each transaction is independent, so a running balance across rows will not reconcile. For a coherent ledger, generate in bank mode and recompute the balance yourself.
Questions
Do the balances add up across rows?
No. Each transaction is generated independently, including the balance-after column in bank mode. Recompute it from the amounts if you need a consistent ledger.
Why are refunds negative?
Because that is how most ledgers store them, and summing a column that mixes signs is where naive revenue calculations go wrong.
What do the failure statuses represent?
The common decline reasons a card network returns — declined, insufficient funds, expired card. Each usually needs a different message in your interface.