Fiserv Ecommerce mock API and live sandbox

The transactional stores do — checkouts, payment links, gateway payments, payment tokens, and payment schedules all resolve the ids they mint, and a deleted token or schedule stays gone (the follow-up read 404s). The reporting side is fixed by design, and two spots sit in between. Dispute sub-writes acknowledge with constant receipts — note-001, evt-001, doc-002 — that never surface in the dispute detail's empty arrays, and the secondary-transaction verb answers a canned RETURN/CAPTURED body whose id the transaction-state read won't find. Assert the ack shapes there rather than chaining reads off them.

The fraud pair models PSD2 exemption processing: the evaluation route scores the transaction at risk 25, cites a known-device history as the exonerating signal, and lands on a TRA exemption with scaIndicator NO_SCA_REQUIRED, while the companion data route accepts submissions with a flat ACCEPTED. One fixed verdict makes the no-challenge branch of a 3-D Secure decision tree deterministic in CI; the challenge-required branch needs a stub of your own with SCA_REQUIRED in a private copy.

Because this is Fiserv's European acquiring stack — the merchant is German, funding settles to a German IBAN, the dispute is a euro chargeback, and the currency-conversion route offers DCC into sterling at 1.2986 with a 3% margin regardless of the currency you nominate. That makes the template the library's Fiserv surface for EU-facing work: IBAN handling, DCC decisioning, and SCA logic that US-centric processors never exercise.

Through the acquiring funnel this template deliberately skips. The Omnichannel template owns that stage — merchant applications, KYC sub-records, document collection, offer pricing — and hands off where this surface picks up: a boarded merchant taking payments and reconciling the money that follows. Build the two against each other and the whole merchant arc, signup through settlement exceptions, runs on mocks.