A WireMock simulation of Fiserv's REST API — covering credit-bureau records and per-network transaction ticket retrieval behind issuer servicing.
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 CREDIT_BUREAU_BKCY_INFORMATION View
curl -s -X POST 'https://g8689.wiremockapi.cloud/creditBureau/v1/bankruptcyInformation' \
-H 'Content-Type: application/json' \
-d '{}'POST CREDIT_BUREAU_BKCY_UPDATE RPC
curl -s -X POST 'https://g8689.wiremockapi.cloud/creditBureau/v1/bankruptcyInformationUpdate' \
-H 'Content-Type: application/json' \
-d '{}'POST BI ODS View
curl -s -X POST 'https://g8689.wiremockapi.cloud/creditBureau/v1/bi' \
-H 'Content-Type: application/json' \
-d '{}'Spec catalog — Fiserv Issuer Solutions - Reference Data (1) · 19 endpoints
| Method | Path | Summary |
|---|---|---|
| POST | /creditBureau/v1/bankruptcyInformation | CREDIT_BUREAU_BKCY_INFORMATION View |
| POST | /creditBureau/v1/bankruptcyInformationUpdate | CREDIT_BUREAU_BKCY_UPDATE RPC |
| POST | /creditBureau/v1/bi | BI ODS View |
| POST | /creditBureau/v1/companyBureau | COMPANY_BUREAU ODS View |
| POST | /creditBureau/v1/companyBureauDetail | COMPANY_BUREAU_DETAIL ODS View |
| POST | /creditBureau/v1/companyBureauDetailAdd | COMPANY_BUREAU_DETAIL_ADD RPC |
| POST | /creditBureau/v1/companyBureauDetailDelete | COMPANY_BUREAU_DETAIL_DELETE RPC |
| POST | /creditBureau/v1/companyBureauDetailUpdate | COMPANY_BUREAU_DETAIL_UPDATE RPC |
| POST | /creditBureau/v1/companyBureauUpdate | COMPANY_BUREAU_UPDATE RPC |
| POST | /creditBureau/v1/creditBureauReportDetails | Search CREDIT_BUREAU_REPORT_DETAILS view |
| POST | /creditBureau/v1/information | CREDIT_BUREAU_INFORMATION ODS View |
| POST | /creditBureau/v1/reportStatus | CREDIT_BUREAU_REPORT_STATUS ODS View |
| POST | /transactions/v2/balanceConsolidationDetail | BALANCE_CONSOLIDATION_DETAIL ODS View |
| POST | /transactions/v2/ticketAmexData | Search TICKET_AMEX_DATA view |
| POST | /transactions/v2/ticketDiscoverData | Search TICKET_DSCV_DATA view |
| POST | /transactions/v2/ticketDscvData | Search TICKET_DSCV_DATA view |
| POST | /transactions/v2/ticketMastercardData | TICKET_MC_DATA ODS View |
| POST | /transactions/v2/ticketMcPurchaseItem | TICKET_MC_PURCHASE_ITEM |
| POST | /transactions/v2/ticketVisaData | TICKET_VISA_DATA ODS View |
Unauthenticated WireMock Cloud demo sandbox for Fiserv — not an official Fiserv sandbox, and it returns simulated example data only.
Reference Data is the lookup shelf of the issuer platform — the API a servicing screen calls when an agent needs what was reported to the bureaus or what a transaction's ticket said — and its nineteen routes split into /creditBureau/v1 and /transactions/v2. Every response identifies its host up front: processorInfo names the FDR system running in PROD mode, and each view then delivers one plausibly complete record. Bankruptcy inquiry finds case 24-12345 filed by SMITH JOHN, the company bureau answers as COMP001 with a federal tax id and a grocery-store SIC code, report details score 720 against bureau code E, and the BI view returns a full arbitration-and- compliance block for an acquirer named FIRST DATA RESOURCES at its actual Atlanta address. The ticket views assign each card network its own merchant — a clothing boutique on the Visa ticket under test PAN 4111 1111 1111 1111, a grocery market in Mastercard's reconciliation-fee field layout, ACME RETAIL on Amex — and the Mastercard purchase-item view goes one level deeper, to a Level-3 line item for the commodity FOOD.
The interchange record of a cleared transaction — the document an issuer retrieves when a cardholder questions a charge or a chargeback needs supporting detail. Each network formats its own, which is why the sandbox gives every scheme a separate view and a separate field dictionary: the Visa ticket is authorization-centric, the Mastercard ticket arrives in reconciliation-fee terms, and the purchase-item view exposes the line-level data a commercial-card program passes. Clients learn here that "get the ticket" is four different contracts, not one.
The upstream specification carries both spellings of the TICKET_DSCV_DATA view — ticketDiscoverData and ticketDscvData — and the template keeps both live rather than collapsing them. Each answers its own record (an electronics merchant on one, a fuel merchant on the other), so a generated client reveals which of the two operation names it bound to just by the merchant that comes back. That's worth one deliberate test if your codegen consumed this spec.
No — the add, update, and delete verbs acknowledge with message 0000 Successful and the views keep answering their canonical records. The one RPC with a data payload is companyBureauDetailAdd, which reports sequenceNumber 002: the slot after the detail view's existing 001 record, so an add-then-render flow sees a coherent story even though nothing is stored. Sequences that truly advance are a scenario-stub exercise for a private WireMock Cloud copy.
The servicing desks. Ticket retrieval feeds dispute intake, and the library's populated dispute desk lives in the Card Developer template — file a claim there, then picture this API as where the supporting interchange detail came from. The bureau views pair the other way: they show the reported state of an account that collections and compliance tooling reconciles against, keeping both sides of a data-quality check mockable.
Vendor names identify APIs represented by WireMock template sources. This page does not imply vendor endorsement, certification, partnership, or official integration status.