U.S. Bank Integrated Receivables mock API and live sandbox

Because the fixture is optimized for parser coverage, not realism. A real payment arrives over one channel and fills one block; this record fills them all so a single read exercises every optional structure your model defines. The corollary: channel-dispatch logic should key on the transactionType field — ACH, here — and never infer the channel from which detail blocks happen to be present, an inference this record is built to break.

There isn't one — the intake acknowledges receipt and stops, so correlation runs on the reference numbers you supplied. The matched invoices inside retrieval and search responses carry primaryReferenceNumber and buyerReferenceNumber fields, and those are your join keys back to the submitted open items. Cash-application integrations should treat that echo, not the intake response, as the confirmation the invoice entered the system.

Treat it as furniture for your pagination UI, not as an iteration contract. The counters describe a five-hundred-row result set parked at page five of twenty, while the body carries a single receivable — so next/previous controls, page indicators, and jump-to-page logic all get an interior page to render, but a loop that walks totalCount rows will starve. Row-accurate paging behavior belongs in a private WireMock Cloud copy.

Both, and deliberately: the fixture superimposes a settled payment and a partial return (reason R01, $100.10 of the original amount) so reconciliation code meets the two states in one record. Production logic decides precedence by comparing the return date against the posting date; here the takeaway is that returns arrive as an enrichment of the transaction, not a separate feed. The bank-account-side view of the same events — BAI-coded activity and an ACH returns feed — lives in the Corporate Account Information template.