Fiserv Card Developer mock API and live sandbox

Real enough to bind dashboards against. Amounts carry decimals, the account's address geocodes, transaction timestamps parse, and identifiers respect their formats — masked PANs in the 400010 range, a sixteen-character non-transactional token, statement docIds long enough to exercise URL handling. Card data stays masked everywhere, which is itself contract-accurate: servicing APIs never return full PANs, and client code expecting them learns otherwise here. The one thin spot is the statement PDF route, whose 200 delivers a placeholder document of a few bytes — enough to verify the download path, not a rendering test.

No — every response is a fixture. The account create always returns the same masked account-and-card pair, the dispute claim always files as case 999999999, and neither appears in later searches, which answer their own canonical records regardless of criteria. That keeps every route deterministic for CI. When a flow needs its writes to surface in subsequent reads — file a dispute, find it in the case list — recreate that thread in a private WireMock Cloud copy with request-matched stubs per step.

The platform's own referencing scheme, preserved verbatim: a referenceId that embeds host and correlation segments behind colons, and caseItemIds that pack a JSON fragment — life cycle key, active key, device-unique id — inside a bracketed string. Parsers tend to assume tidy scalar ids and break on exactly this, so the fixture is a cheap conformance test: treat the values as opaque strings to store and echo, never as structures to decompose, and your client matches how the production system expects them handled.

Perspective. The Card as a Service template models a bank issuing cards through its own API — a live store where lifecycle verbs move real state — while Card Developer is the processor's servicing window onto an existing portfolio: search-heavy, fixture-rich, spanning disputes, fraud, and rewards in one surface. The loyalty engine feeding its uChoose balances has its own template in Loyalty & Rewards; pick by which side of the processing relationship your integration sits on.