As of November 2025
The API worked. The books did not. Month-end close, 11:47 PM: treasury sees payments that left the bank, the ERP sees settlements that never arrived, and chargebacks, ACH returns, and RTP reversals each live in a different system.
The docs say everything is idempotent and RESTful. Nobody in that room cares. They need to explain a six-figure gap to the CFO in the morning, and the clean interface did nothing to help them.
The quiet failure mode
A lot of “modern” payment platforms look great at the interface and fail at the ledger. The JSON is pretty, developer productivity improves, and then accounting spends three days stitching exports to answer one basic question: what actually happened to this payment across all rails and all failure paths. Controllers lose confidence in numbers that depend on manual reconciliation. Treasury cannot trust a cash position when settlement timing is opaque. Audit burns hours reconstructing flows the platform already knows.
The different premise
An ERP-grade API treats the contract as a shared language between engineering and finance. Lifecycle states map to how the ledger thinks about money. Reference IDs and idempotency keys are designed for reconciliation, not only retry. Settlement dates, cut-off times, and return codes are modeled explicitly instead of buried in free text. And versioning respects that finance closes books on real timelines, not sprint schedules.
Lifecycle states
Ledger-mapped
initiated, settled, adjusted, reversed - states the general ledger already understands.
Keys
Reconciliation-first
reference IDs and idempotency keys designed around reconciliation, not just retry logic.
Versioning
Book-close
version policies that respect when finance closes books, not the sprint calendar.
The platforms that win long term will do more than make integration easier for developers. They will make financial truth easier to see for the teams who sign the numbers.
