A WireMock simulation of Fiserv's REST API — covering partner-side worker onboarding, KYC status, and payout creation, tracking, cancellation, and retry.
A shared instance of this template runs on a public endpoint — call it right now from curl, an SDK, or an AI agent. Responses are fixed examples and behavior can't be changed; rate limits apply.
Jump to the endpoints ↓Run this template as a mock API in WireMock Cloud for a private instance you control — edit stubs, add stateful scenarios, use dynamic response templating, and inspect requests in the log.
Open in WireMock Cloud (free) →Live sandbox · no signup, no API key
A running WireMock Cloud instance of this template, callable right now from a terminal, a script, or an AI agent.
Endpoints
POST Create User Application
curl -s -X POST 'https://jy8zy.wiremockapi.cloud/v1/users/create-application' \
-H 'Content-Type: application/json' \
-d '{}'GET Get KYC Information
curl -s -X GET 'https://jy8zy.wiremockapi.cloud/v1/users/your-payfare_id/kyc'GET Get KYC Webview Link
curl -s -X GET 'https://jy8zy.wiremockapi.cloud/v1/users/your-payfare_id/kyc/form-link'Spec catalog — Fiserv EmFi B2B API (1.0) · 10 endpoints
| Method | Path | Summary |
|---|---|---|
| POST | /v1/payment/{payfare_id} | Add Payments |
| GET | /v1/payouts/{payout_id} | Check Payment Status |
| PUT | /v1/payouts/{payout_id}/cancel | Cancel Payment |
| POST | /v1/payouts/{payout_id}/retry | Retry Payment |
| GET | /v1/users/{payfare_id} | Get a User |
| PUT | /v1/users/{payfare_id} | Update a User |
| GET | /v1/users/{payfare_id}/kyc | Get KYC Information Associated with the User |
| GET | /v1/users/{payfare_id}/kyc/form-link | Get KYC Webview Link |
| GET | /v1/users/{payfare_id}/primary-card | Get Primary Card of User |
| POST | /v1/users/create-application | Create a User |
Unauthenticated WireMock Cloud demo sandbox for Fiserv — not an official Fiserv sandbox, and it returns simulated example data only.
This is the integration a payout platform builds against the EmFi program — ten routes for onboarding workers and moving their earnings — and the mock runs both of its registries for real. A create-application call returns your submitted fields under a fresh payfare_id with a same-second created_at and status pending-activation; the user read resolves that id from then on, and a profile update rewrites just the fields you send while the rest of the record stands. The payment intake does the same for money: it mints a payout carrying a nested earnings block, the status read finds it, a cancel moves it to cancelled, and a retry moves it again to processing — the record keeps whichever verb ran last. Around the registries sit the platform's fixed lookups: a KYC read reporting a passed New York driver's-license check for any worker id, a form-link route handing back the hosted verification webview URL with its session tokens, and a primary-card read describing an active Mastercard. Everything a partner integration calls in its first week is here, live and unmetered.
With a 400, not a 404. An unregistered worker id draws an error envelope carrying field payfare_id and numeric code 10050; an unknown payout answers code 40070. Error handling here therefore branches on the code inside the body rather than the HTTP class, and the sandbox enforces that discipline on every gated route — a client switching on status codes alone will misfile these as validation failures.
Yes — the status field simply takes the most recent verb. Cancel writes cancelled, retry overwrites it with processing, and the read reports whichever came last with the rest of the record untouched. That makes the payout store a clean fixture for retry-loop logic and for idempotency decisions (the intake mints a new payout every call, so deduplication is the client's job, exactly as the error-code table implies).
Two worth coding for. Timestamps mix formats in a single body — the payout's created_at is ISO-8601 while the earnings block inside it uses epoch milliseconds — and currency_code returns as an empty string no matter what the request supplied, even as the amount echoes faithfully. Both are the platform's real serialization habits, and both are cheap to handle once your models stop assuming uniformity.
Like a banking app — and it has its own template. The EmFi BaaS surface exposes the cardholder's view: the balance the payout lands on, the transaction feed it appears in, card controls, and ACH out. Run the pair as a loop — push earnings through this API, read them back through that one — to rehearse an end-to-end demo with no live program behind it. For a different disbursement rail entirely, the Zelle B2C template models bank-account payouts of the same shape.
Vendor names identify APIs represented by WireMock template sources. This page does not imply vendor endorsement, certification, partnership, or official integration status.