Agentic payments

Software agents increasingly initiate or request payments: procurement bots, autonomous checkout agents, agent frameworks spending against budgets. The decision problem is the same as at a human checkout, and the same primitives apply: the agent's backend asks PayInference what should happen, receives one instruction, and executes it through its existing payment stack.

Two boundaries stay exactly where they are for human-driven payments:

• PayInference does not custody funds and does not execute payments, for agents or anyone else.
• The agent system's backend calls PayInference with an API key. Agents themselves are not handed keys, the same way browsers are not.

What works today#

Everything on this page uses the current API; nothing here is a separate agent product.

Spending guardrails via policy. Amount thresholds, currency and country restrictions, and step-up requirements express agent spending limits directly:

{
  "rule_id": "agent_spend_cap",
  "name": "Require approval above agent budget",
  "priority": 10,
  "enabled": true,
  "when": { "amount_gte": 20000 },
  "then": { "type": "step_up" }
}

{
  "rule_id": "agent_hard_cap",
  "name": "Block above hard cap",
  "priority": 5,
  "enabled": true,
  "when": { "amount_gte": 100000 },
  "then": { "type": "block" }
}

Human approval as step-up or hold. For agents, step_up means "get approval now, in the flow", and hold means "park this in a pending state until an approval queue resolves it". Route the request to a human approver (or a supervising agent), then proceed or stop; see Step-up integration and Hold and review integration.

Velocity signals. Send risk_signals (velocity_count_1h, velocity_amount_1h, previous_decline_count) computed per agent identity. They raise the advisory risk assessment on every decision, so a runaway loop is visible in the decision log and in review. To make velocity enforceable, feed your own composite score into transaction.risk_score and gate it with a policy rule (when: { risk_score_gte: 70 }, then: { type: "block" }); policy rules are what change the instruction.

Full audit trail. Every agent-initiated decision is in the decision log with reason codes and matched rules, which answers "why did the agent's payment go through" with evidence.

// Agent backend, before executing a purchase the agent requested:
const decision = await payinference.decide({
  order_id: `agent_task_${taskId}`,
  transaction: {
    amount: 18500,
    currency: 'USD',
    country: 'US',
    payment_method: 'card',
    // Your per-agent risk score; policy rules on risk_score_gte enforce it.
    risk_score: agentRiskScore,
  },
  available_providers: ['stripe', 'adyen'],
  risk_signals: {
    velocity_count_1h: agentAttemptsThisHour,
    velocity_amount_1h: agentSpendThisHour,
  },
});

if (decision.action === 'block') return denyAgentTask(taskId, decision.decision_id);
if (decision.action === 'step_up') return requestHumanApproval(taskId, decision.decision_id);
return executePurchase(decision.route!.primary_provider, task);

Planned#

Dedicated agent-native controls, per-agent budgets tracked by PayInference, and agent identity as a first-class request field are planned directions, not current API features. Today, model per-agent budgets in your own system, express the enforcement thresholds as policy rules, and use hold rules for approval queues.