Boarding a Merchant with Fiserv

You can board a Fiserv merchant either through the Koard Merchant Management System (MMS) UI or programmatically via the API. Koard targets Fiserv's UMF Rapid Connect interface (spec UMF_RMY019_2026.02.16, v15.04.4) over the Datawire transport.

Per the UMF spec, a Fiserv merchant is identified at the integrator boundary by three merchant-supplied values — MID, TID, MCC — plus the TPPID that Koard owns and sets once per environment. Everything else needed to run an authorization is configured by Koard (TPPID, terminal-capability constants); a Datawire ID (DID) is used only when Datawire is enabled on the terminal.

Fiserv Flavors

Fiserv Rapid Connect fronts several acquiring platforms. Koard selects the right one per merchant via the processor config — you board with the same VAR-sheet shape shown on this page regardless of flavor; only the processor_config_id and the Fiserv-assigned GroupID differ.

The GroupID in the VAR packet tells you which front-end the merchant sits on. Use the processor_config_id for that flavor; everything else on this page is identical across flavors.

Before You Start

Fiserv provisions the merchant on their side; Koard never makes a "create merchant" call. Once a merchant is set up on Fiserv's platform, your VAR sheet packet contains:

The UMF TPPID field (Rapid Connect ID assigned by Fiserv for a specific version of vendor/merchant software, UMF §3.1.9) is not on the merchant VAR sheet — it identifies the integrator's certified SDK build, not the merchant. Koard owns it and sends a fixed value (RMY019 for the current Koard build) on every transaction.

Via the MMS

After creating the merchant account, click New Terminal and select Fiserv as the processor. You'll be presented with the Fiserv VAR Sheet Information form.

Fill in all required fields (marked with *) using the values from the merchant's Fiserv VAR sheet:

Once saved, assign the terminal to a location and generate merchant credentials as usual.

Via the API

Create Terminal — POST /v2/terminals

Request body

Required vs conditional fields

Every Fiserv board — regardless of flavor — requires the top-level account_id, processor_config_id, terminal_name, mid, tid, mcc, plus the var_sheet address (merchant_street_address, merchant_city, merchant_state, merchant_postal_code), country_code, and industry. The rest is conditional on the flavor:

Example — DID already issued

curl https://api.uat.koard.com/v2/terminals \
  -X POST \
  -H "X-Koard-apikey: $KOARD_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "account_id": "100200300001",
    "processor_config_id": "prc_live_fiserv_us",
    "terminal_name": "Front Counter iPhone",
    "mid": "RCTST1000118756",
    "tid": "00000003",
    "mcc": "5812",
    "var_sheet": {
      "group_id": "40001",
      "did": "00067045767186571068"
    }
  }'

Example — DID provisioned at boarding (Datawire enabled)

With datawire_enabled true (the default), omit did and Koard provisions a Datawire ID at boarding and persists it on the terminal.

curl https://api.uat.koard.com/v2/terminals \
  -X POST \
  -H "X-Koard-apikey: $KOARD_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "account_id": "100200300001",
    "processor_config_id": "prc_live_fiserv_us",
    "terminal_name": "Front Counter iPhone",
    "mid": "RCTST1000118756",
    "tid": "00000099",
    "mcc": "5812",
    "var_sheet": {
      "group_id": "40001"
    }
  }'

The response includes the persisted var_sheet.did so you can confirm registration succeeded.

Update Terminal — PUT /v2/terminals/{terminal_id}

To correct or update VAR sheet fields after creation, send a PUT with a var_sheet object containing only the fields you want to change.

curl https://api.uat.koard.com/v2/terminals/500600700001 \
  -X PUT \
  -H "X-Koard-apikey: $KOARD_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "var_sheet": {
      "did": "00067045767186571068"
    }
  }'

Batch Management

Fiserv is host capture today — the host manages the batch and settles on its cutoff. There is no merchant-driven batch open/close model, and the MMS batch panel is read-only for Fiserv terminals.

Merchant-driven batch management (see Automated Batch Scheduling) is on the roadmap. Until then, leave batch management disabled in the MMS.

Gotchas

• Omaha settlement — for merchants on Fiserv DD / sponsor-bank funding via FDC, confirm the Omaha flavor is provisioned before boarding.
• tid is zero-padded to 8 characters as AuthKey2 in the Datawire envelope. Don't pad it yourself in the VAR packet — supply the raw value (Koard pads).
• TranFee (Merchant Surcharge) triggers full declines without enrollment. The UMF spec is explicit: "Failure to do this will cause all credit card transactions with the surcharge amount field populated to be declined." Don't enable surcharge until Fiserv confirms enrollment.

Troubleshooting

400 Bad Request on create

• Confirm mid, tid, and mcc are at the top level of the request, NOT inside var_sheet.
• Confirm group_id is inside var_sheet and is 5-13 alphanumeric chars.
• Verify processor_config_id is a valid Fiserv config ID for your environment.

Transactions erroring with INVALID MERCHANT

• The acquirer MID is platform-level. If your merchant requires a different acquirer relationship, contact Koard support — per-merchant acquirer routing is a future enhancement, not configurable on the VAR sheet today.

Need Omaha settlement

• Confirm the Omaha flavor is provisioned for the merchant before boarding.