Fiserv Sales & Product Management mock API and live sandbox

Host transaction identifiers. On the processing platform, maintenance work travels as numbered nonmonetary transactions — NM*191 updates an authorization strategy, NM*794 maintains carrier codes and member identifiers, NM*791 variants adjust purse tables and fund balances — and this API family names the underlying transaction right in each operation's summary. Integrators coming from the batch world can map their existing nonmon logic to these routes by code; the sandbox answers each with the standard success envelope so the mapping can be verified route by route.

Yes, and the internal consistency is the point. The same card-to-DDA pairing appears in the cross-reference view, the linked-accounts list, and the balance reads, so a client that stitches several views into one account screen gets data that agrees with itself — balances, addresses, and identifiers all describing the same person. Requests aren't inspected (any criteria return the canonical records), which keeps multi-view rendering tests deterministic without seed scripts.

Populated views and terse acks. The reads return one lifelike record apiece — a claim from City Medical Center with a 2024 service date, a grocery-merchant recurring transaction with a count of twelve, a purse holding 500.00 with fund access enabled, processing partner PP001 — while every write in the enrollment, copay, and settlement-control families confirms with 0000 SUCCESS and nothing else. The absent messageMap on those acks is worth encoding in your response models: it's a real dialect difference between the two halves of this one API.

In the Operations Execution template, which carries the back-office breadth — adjustments, authorizations, collections, statements — that this surface deliberately leaves out. Sales & Product Management is the setup-and-structure slice: creating the DDA links, strategies, and enrollments that Operations Execution then services. The two share the processorInfo envelope convention, so clients move between them without re-plumbing their response handling.