What is function calling in AI Agents? A Guide for CTOs in payments

Function calling is a way for an AI agent to ask your software to run a specific function, like get_payment_status() or create_refund(), instead of guessing the answer itself. In practice, it lets the model turn a user request into a structured API call with the right parameters.

How It Works

Think of function calling like a payment ops desk with a strict playbook.

A customer says, “Where is my card payment?” The agent does not improvise. It identifies the intent, picks the right internal function, and passes structured data such as transaction ID, account ID, or date range. Your backend executes the function, returns the result, and the model turns that result into a natural-language response.

For a CTO in payments, the important part is this: the model is not the system of record. Your APIs are.

A typical flow looks like this:

1. •User asks a question or makes a request.
2. •The LLM decides whether it needs to call a function.
3. •The model emits a structured payload, not free text.
4. •Your orchestration layer validates the payload.
5. •The backend service executes the function.
6. •The result is returned to the model for final response generation.

Example structure:

{
  "name": "get_payment_status",
  "arguments": {
    "payment_id": "pay_12345"
  }
}

This is closer to how an experienced operations analyst works than how chatbots used to work. The analyst does not “know” every settlement status from memory; they look up the ledger, check systems of record, then respond.

The same pattern applies in AI agents.

Why It Matters

• •

  It makes agents useful in real workflows

  • •Without function calling, an agent can only talk.
  • •With it, the agent can initiate actions like checking KYC status, retrieving chargeback data, or starting a refund workflow.
• •

  It reduces hallucination risk

  • •In payments, wrong answers are expensive.
  • •Function calling forces the model to fetch verified data instead of inventing transaction states or policy details.
• •

  It creates clean separation of responsibilities

  • •The LLM handles language understanding and decision-making.
  • •Your services handle business logic, authorization, audit trails, and state changes.
• •

  It fits regulated environments

  • •You can put policy checks between intent detection and execution.
  • •That matters for PCI scope control, maker-checker approval flows, fraud controls, and customer authentication.

Real Example

Let’s say you run a payment platform and support teams get this request:

“Refund the last failed card payment for merchant M-8821.”

A good agent should not directly issue the refund just because it understood the sentence. It should first resolve what “last failed card payment” means using internal functions.

Possible workflow:

1. •The agent calls list_recent_payments(merchant_id="M-8821", status="failed").
2. •Your service returns matching transactions.
3. •The agent identifies the most recent one and prepares a refund request.
4. •Before execution, your orchestration layer checks:
   • •Is this payment eligible for refund?
   • •Does this user have permission?
   • •Is additional approval required?
5. •If approved, the agent calls create_refund(payment_id="pay_77891", amount=...).
6. •The backend processes it and returns confirmation.
7. •The agent replies: “Refund initiated for payment pay_77891. Reference: RF-44219.”

That is function calling in production terms: controlled tool use with validation around it.

Here’s what that looks like in simplified pseudocode:

tools = [
    {
        "name": "list_recent_payments",
        "description": "Fetch recent payments for a merchant",
        "parameters": {
            "merchant_id": "string",
            "status": "string"
        }
    },
    {
        "name": "create_refund",
        "description": "Create a refund for an eligible payment",
        "parameters": {
            "payment_id": "string",
            "amount": "number"
        }
    }
]

The key design choice is that your system decides what tools exist and what they are allowed to do. The model can only choose from those tools.

In banking and payments, this pattern also works well for:

• •balance lookups
• •dispute creation
• •payout scheduling
• •merchant onboarding checks
• •AML alert summaries

The same guardrails apply every time: validate inputs, enforce permissions, log every call, and never let the model bypass business rules.

Related Concepts

• •

  Tool use

  • •Broader term for letting models interact with external systems through defined interfaces.
• •

  Agent orchestration

  • •The layer that decides when to call tools, how to chain them, and when to stop.
• •

  Structured outputs

  • •JSON or schema-constrained responses that make downstream processing reliable.
• •

  RAG (retrieval augmented generation)

  • •Used when the agent needs knowledge from documents rather than an action from an API.
• •

  Workflow automation

  • •Deterministic process execution that often sits behind or alongside AI agents in regulated operations.

Keep learning

• •The complete AI Agents Roadmap — my full 8-step breakdown
• •Free: The AI Agent Starter Kit — PDF checklist + starter code
• •Work with me — I build AI for banks and insurance companies

By Cyprian Aarons, AI Consultant at Topiax.