Fiserv EmFi BaaS mock API and live sandbox

Three of them. Card status reads back whatever the last PUT wrote (it begins as an empty string — the unseeded state), the shipping address holds the body a POST gives it, and ACH recipients run a working registry: a created recipient resolves by id, an update merges into it, and a remove ends with the read rejecting the id. The list views are the boundary — the recipient roster and transfer history always answer their built-in fixtures, so records you mint appear on by-id reads only. Test list rendering against the fixtures and record lifecycles against your own ids.

Until something is stored, that route renders a body with a bare key and no value — syntactically invalid JSON under an HTTP 200 — and any client hits the parse failure before its first POST. Treat it as a built-in resilience drill (a malformed-200 handler is worth having against production middleware too), or simply seed the address first if the flow under test reads before it writes. After one POST the route returns clean JSON from then on.

The drift is part of the fixture set, and it's a useful tripwire. The card-balance route says 125.50 while the account-balances route reports 87.00 for the same card, and transaction F2164684129 is a 45.50 Walmart purchase in the feed but a 50.00 hobby-shop charge in its detail read. Code that assumes one route mirrors another gets caught here; pin each assertion to the route it actually calls. The detail read also spells its date field tranasaction_date — the API's own typo, preserved so generated models bind against reality.

The partner integration that creates these users and funds these cards — covered by the EmFi B2B template, where the payout platform onboards workers, checks KYC, and pushes earnings. The two mocks pair naturally: drive a payout through the B2B surface, then render this side's feed and balances as the cardholder would see them, all against deterministic data.