Agentic Payment Link

The Agentic Payment link let your agentic workflow or LLM-based application create gateway payment links and check their status directly through the Model Context Protocol (MCP), without your application needing to call the underlying REST APIs itself.

A typical flow looks like this:

  1. A consumer reaches a point in your merchant application or chat experience where a payment is needed.
  2. Your MCP client calls IPG_LINK_PAYMENT_GET_LINK to obtain a hosted payment page URL.
  3. You share that URL with the consumer, who completes the payment on Fiserv's hosted payment page.
  4. Your MCP client calls IPG_LINK_PAYMENT_GET_STATUS to confirm the outcome and continue the conversation or workflow.

All requests are authenticated with a bearer token (OAuth 2.0 / OpenID Connect) scoped to your merchant store, and are routed through Fiserv's API gateway.

What you need before you start

  • A gateway (IPG) generated Store ID, User ID, and password issued during onboarding. The KeyCloak username is the combination of {StoreID}@{UserID}.
  • Optionally, a Time-based One-Time Password (TOTP) secret if your account has one-time-password login enabled.
  • An MCP client (agentic runtime, LLM application, or any client library) that supports:
    • the MCP streamable HTTP transport, and
    • OAuth 2.0 Authorization Code flow with PKCE.

Environments

Test / CI

SettingValue
MCP Endpoint (Apigee ingress)https://cat.emea.api.fiservapps.com/exp/v2/payment-links/mcp
Identity Provider (Keycloak issuer)https://test.ipg-online.com/gws-sso/auth/realms/ipgMcp

Production

SettingValue
MCP Endpoint (Apigee ingress)https://prod.emea.api.fiservapps.com/exp/v2/payment-links/mcp
Identity Provider (Keycloak issuer)https://www.ipg-online.com/gws-sso/auth/realms/ipgMcp

Connecting your MCP client

1. Client configuration

Configure your MCP client with the MCP endpoint for your target environment (see Environments above) and the following values:

SettingValue
OAuth client IDipg-mcp-paymentlink-client
Scopeopenid mcp payment-link profile email checkout-inquiry
Redirect / callback URIhttp://127.0.0.1:<port>/callback — any free local port, for example 8090
Grant typeAuthorization Code with PKCE (code_challenge_method=S256)

2. OAuth discovery

Most MCP clients discover the OAuth endpoints automatically. If yours needs them explicitly, resolve them in this order:

PurposeEndpointDefined by
Protected Resource Metadata{mcpBaseUrl}/.well-known/oauth-protected-resourceRFC 9728
Authorization Server Metadata (proxied){mcpBaseUrl}/.well-known/oauth-authorization-serverRFC 8414 compatibility passthrough
Authorization Server Metadata (standard){keycloakIssuer}/.well-known/openid-configurationOpenID Connect Discovery

{mcpBaseUrl} is the MCP endpoint for your target environment; {keycloakIssuer} is the matching Identity Provider issuer (see Environments).

3. Authenticate

  1. Your MCP client opens a browser to the Keycloak authorization_endpoint with your client_id, requested scope, and a PKCE code_challenge.
  2. Log in with your Store ID and User ID in the form {StoreID}@{UserID}, plus your password (and TOTP code, if enabled).
  3. Keycloak redirects back to your local callback URI with an authorization code.
  4. Your MCP client exchanges the code for an access token at the token_endpoint.

The resulting bearer token carries these claims:

ClaimMeaningNotes
issToken issuerThe Keycloak realm URL for the environment you authenticated against
audIntended audienceDiffers by hop: the gateway validates one audience value, the Payment Link MCP Server another, and the Checkout API another
subSubjectEncodes your authenticated store; used server-side to scope every request to your store
scopeGranted scopesMust include mcp and payment-link
expExpiryStandard JWT expiry. Re-authenticate once the token expires; don't keep retrying with an expired token

4. Session handshake

Once authenticated, your MCP client performs the standard MCP handshake before making tool calls:

initialize            -> server capabilities
notifications/initialized
tools/list             -> IPG_LINK_PAYMENT_GET_LINK, IPG_LINK_PAYMENT_GET_STATUS
tools/call              -> your actual request

Send the bearer token on every request as Authorization: Bearer <token>.

❗️

If calls suddenly start failing with a generic 500 Internal Server Error after your client has been idle for a while, reconnect your MCP client to start a fresh session rather than retrying — see Error handling.

Tools reference

IPG_LINK_PAYMENT_GET_LINK

Creates a new hosted payment link for a given amount and currency.

Presence: m = mandatory, c = conditional, o = optional.

Request

TagDescriptionPresence
payment_link.amountAmount to charge. Must be a finite, positive number — the server does not silently round it.m
payment_link.currencyISO 4217 currency code (for example EUR, USD). Must be supported by your store configuration.m
{
  "payment_link": {
    "amount": 10.00,
    "currency": "EUR"
  }
}

Response

TagDescriptionPresence
storeIdYour merchant store ID, echoed back from the token.m
orderIdGateway order ID created for this link.m
paymentLinkIdShort identifier for the link. Use it later with IPG_LINK_PAYMENT_GET_STATUS.m
paymentLinkURLThe hosted payment page URL to share with the consumer.m
expiryDateTimeISO 8601 timestamp after which the link can no longer be paid.m
{
  "paymentLink": {
    "storeId": "120995513002",
    "orderId": "PL-100000775467",
    "paymentLinkId": "BpLgK3",
    "paymentLinkURL": "https://checkout-lane.com/pl/BpLgK3",
    "expiryDateTime": "2026-06-29T15:35:33+02:00"
  }
}

IPG_LINK_PAYMENT_GET_STATUS

Retrieves the current status of a previously created payment link.

Request

TagDescriptionPresence
payment_link_status.link_idThe paymentLinkId returned by IPG_LINK_PAYMENT_GET_LINK.m
{
  "payment_link_status": {
    "link_id": "BpLgK3"
  }
}

Response

Presence: m = mandatory (always present), c = conditional (present once the link has actually been used/paid).

TagDescriptionPresence
transactionStatusCurrent status, for example APPROVED, DECLINED, INITIATED, WAITING.m
transactionTypeTransaction type, for example SALE.m
transactionAmount.total / .currencyAmount and currency of the transaction.m
paymentMethodUsed.cards.cardNumber / .brandMasked PAN (for example 411111******1111) and card brand.c
ipgTransactionDetails.transactionResultResult of the underlying IPG transaction (for example APPROVED).c
ipgTransactionDetails.approvalCodeIssuer / processor approval code.c
ipgTransactionDetails.processor.responseCode / .responseMessageProcessor response code and human-readable message.c
ipgTransactionDetails.transactionStateSettlement state, for example CAPTURED.c
ipgTransactionDetails.ipgTransactionIdIPG's internal transaction ID — useful when contacting support.c
{
  "transactionStatus": "APPROVED",
  "transactionType": "SALE",
  "transactionAmount": { "total": 10.0, "currency": "EUR" },
  "paymentMethodUsed": {
    "cards": { "cardNumber": "411111******1111", "brand": "VISA" }
  },
  "ipgTransactionDetails": {
    "transactionResult": "APPROVED",
    "approvalCode": "Y:804167:4661560435:PPXM:5147258943",
    "processor": { "responseCode": "00", "responseMessage": "Function performed error-free" },
    "transactionState": "CAPTURED",
    "ipgTransactionId": "84661560435"
  }
}

Error handling

Error / StatusMeaningRecommended action
401invalid_tokenYour bearer token is invalid, expired, or no longer recognized.Clear cached tokens in your MCP client and re-authenticate.
checkout_connection (in the tool result)The Payment Link MCP Server could not reach the Checkout API.Retryable. Wait briefly and retry the call.
checkout_temporarily_unavailableThe Checkout API is rate-limiting or temporarily unavailable.Honor the retry_after_seconds value returned in the error before retrying.
500 Internal Server Error (with a Trace-Id)Gateway-level fault — most commonly caused by a stale MCP session after a period of client inactivity.Reconnect / re-initialize your MCP client to start a fresh session. If it persists, contact support with the Trace-Id.
404 on a discovery endpointThat specific .well-known path variant isn't served at this location.Expected for some path variants — fall back through the discovery order in OAuth discovery.

Operational rules

RuleExpected behavior
IdempotencyEach call to IPG_LINK_PAYMENT_GET_LINK creates a new, distinct payment link. It is not idempotent — don't call it again to "retry" a link a consumer already has; use IPG_LINK_PAYMENT_GET_STATUS instead.
AmountMust be a finite, positive number. The server does not silently round the value you send.
CurrencyMust be an ISO 4217 code supported by your store configuration.
Link expiryEvery link carries expiryDateTime. An expired link can no longer be paid — create a new one if the consumer needs to retry.
Token scopeEvery request is scoped to the store encoded in your token's sub claim. A single token cannot act on behalf of another store.
Session handlingIf calls start failing with generic 500 errors after a period of idle time, reconnect your MCP client rather than repeatedly retrying the same session.

Did this page help you?
Want a quick overview?