Agentic payments control for AI agents, merchants and payment infrastructure

Agents today typically receive a full API key or payment token. Once issued, that credential carries as much spending authority as a human employee with unrestricted access to a corporate card. The agent can initiate transactions at any merchant, for any amount, at any time the credential is valid. There is no mechanism in most payment stacks for expressing that an agent should only be permitted to spend up to a given ceiling, with a specific merchant, during a defined window.

When something goes wrong with an over-permissioned agent, the post-incident situation is difficult. There is no permission boundary to point to, no machine-readable record of a decision granting authority for the specific transaction that caused the problem, and no way to show that a delegation constraint was in place that should have blocked the action. Chargebacks attributed to agent-initiated transactions are hard to dispute without that evidence layer.

PSPs, acquirers, payment gateways, merchants, and terminal vendors all face the same structural gap. Chargebacks from over-permissioned agents are difficult to contest. Fraud that originates from a compromised agent credential is hard to trace to a specific delegation scope. There is no machine-readable evidence of whether a given payment action was actually authorised under a policy that was active at the time it occurred.

The gap is not in the payment network itself. Card schemes, PSPs, and acquirers process what they receive. The missing layer is the one that should sit between the agent and the payment execution: the layer that evaluates "was this agent actually permitted to do this, at this amount, with this merchant, at this time" and returns a verifiable answer before any funds move.

AffixIO operates as a control plane that sits between payment-requesting agents and payment-executing infrastructure. It is not a bank, not a wallet, and it does not move funds. Its role is to evaluate whether a given agent is permitted to trigger a specific payment action, under the delegation and policy in force at the time of the request, and return a machine-readable decision.

Agents register with AffixIO and receive scoped credentials tied to a specific agent identity. Delegations are separate objects that express what the agent is permitted to do: which merchants it may transact with, which amount ceilings apply, which currencies are permitted, which channels are in scope, and when the delegation is valid. A single agent can hold multiple delegations with different constraints for different contexts.

When an agent wants to trigger a payment action, it calls AffixIO with a permission request containing its agent identifier, device identifier, delegation identifier, and the details of the payment intent. AffixIO evaluates whether the agent is registered, whether the device is attested and trusted, whether the delegation is active and covers the requested action, whether the merchant is on the allowlist, and whether the trust policy is satisfied. The result is a decision object containing the action code, the applicable reason codes, a proof identifier, and an expiry.

Downstream systems, whether a PSP, a merchant backend, or a terminal, read the decision. They only proceed if the action is ALLOW or ALLOW_WITH_LIMITS. A decision of DENY stops execution before any payment is initiated. A decision of REQUIRE_USER_CONFIRMATION pauses the flow for a human checkpoint before the permission request can be completed.

API example

# Permission request
curl -X POST https://api.affix-io.com/v1/nior/agent/permission \
  -H "Authorization: Bearer $AFFIXIO_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "agent_id": "agt_5d1f9b3a",
    "device_id": "dev_8c2e6a4f",
    "delegation_id": "dlg_2b8e4a7c",
    "payment_intent": {
      "merchant_id": "mer_3c7a1b9f",
      "amount": 1850,
      "currency": "GBP",
      "channel": "online"
    }
  }'

// Full decision response
{
  "decision_id":       "dec_9f7a3c1b",
  "allowed":           true,
  "action":            "ALLOW_WITH_LIMITS",
  "reason_codes":      ["DELEGATION_VALID", "DEVICE_TRUSTED", "MERCHANT_ALLOWED"],
  "policy_id":         "pol_7c3a9f1b",
  "delegation_id":     "dlg_2b8e4a7c",
  "agent_id":          "agt_5d1f9b3a",
  "device_id":         "dev_8c2e6a4f",
  "payment_intent_id": "pi_4a7b1c9e",
  "max_amount":        2500,
  "currency":          "GBP",
  "requires_step_up":  false,
  "proof_id":          "prf_3e6c1a8b",
  "audit_event_id":    "aud_1f4d9c2a",
  "expires_at":        "2026-03-11T20:15:00Z"
}

AffixIO is not in the money flow. It does not settle funds, hold balances, or replace your PSP, acquirer, or issuer. Adding AffixIO to your stack does not change how payments are processed, settled, or reconciled. It adds a decision layer upstream of your existing payment execution path.

It sits between the agent or system requesting a payment action and the payment infrastructure that executes it. The agent calls AffixIO with a permission request. AffixIO evaluates that request against the current state of the agent's registration, device attestation, active delegations, trust policy, and merchant rules. It returns a machine-readable decision object. Your payment infrastructure reads that object and acts accordingly.

Because the permission check happens upstream of payment execution, your existing PSP, acquirer, and merchant backend code changes are limited to reading the decision response and branching on the action code. The funds routing path stays unchanged. AffixIO proofs are stored alongside transaction records rather than in the payment data flow.

This architecture means AffixIO can be integrated with any payment stack that supports a pre-authorisation hook or middleware layer, without rerouting funds and without adding to PCI cardholder data environment scope.