Agentic Payments Infrastructure: Services and Control Boundaries

9 minute read · Payments, architecture and security review required

Agentic payments infrastructure is the control system around existing payment rails. The agent prepares a typed proposal. Identity, delegated authority, deterministic policy and exact approval decide whether it may proceed. A protected adapter uses isolated credentials, while reconciliation and evidence track the provider outcome.

The broader agentic payments architecture separates model proposals from payment authority. The service map below shows where those responsibilities live and which systems should remain authoritative.

Reference architecture

[documents / commerce intent]
          v
[agent proposal service] -> [schema and source validation]
          v
[identity + authority] -> [policy] -> [exact approval]
          v
[idempotency reservation] -> [credential broker] -> [payment adapter]
                                                        v
                                                 [payment provider]
                                                        v
                              [reconciler] <- [webhooks / provider query]
                                   v
                            [logs + action receipts]

The payment provider remains the system that processes or settles value. The agent and trust layer should not invent final status.

Decide where each fact comes from

AP2's protocol specification provides mandate and payment objects that can connect ecosystem participants. It does not replace a company's supplier master, approval matrix, treasury controls or reconciliation operations.

Keep payment data out of the model

Use opaque destination and credential references in proposals. The payment adapter resolves them after authorization. Restrict logs and portable receipts to minimal fields and digests. PCI SSC's AI principles are a useful security input, but scope and compliance require qualified assessment.

Set acceptance tests by boundary

Change the destination after approval, reuse an idempotency key with a different amount, lose the provider response after acceptance, replay a mandate and call the adapter around the gateway. Each test needs an expected state and evidence record.

Decide what to build and what to integrate

Most enterprises should integrate established identity, payment, supplier and accounting systems rather than recreate them. The agent-control layer needs adapters that preserve stable identifiers and explicit states. Avoid hiding provider differences behind a single success response.

Build the domain policy that expresses the organization's authority and approval matrix. A generic payment provider cannot know which buyer entity, supplier, cost center, destination or invoice is authorized. Keep this logic deterministic and versioned.

The evidence layer should accept provider and system-of-record observations without claiming stronger assurance than the source. A provider webhook can show what the provider reported. Ledger settlement or receiving records may be needed for the final business outcome.

Operational ownership matters as much as components. Name the team that handles uncertain transactions, credential rotation, policy releases, supplier destination incidents and evidence export failures. Infrastructure without these queues will push unresolved decisions back to the agent.

The BIS paper on AI agents for cash management in payment systems shows potential for AI-assisted payment operations while also calling for safeguards, oversight and further research. It is not evidence that autonomous payment control is risk free.

Use the payment threat model and reconciliation state machine to complete the design. Intelliger's agentic commerce platform is the live product destination.

Intelliger's OATI components are developer-preview infrastructure and do not operate customer payment rails or establish regulatory compliance.

Infrastructure design questions

Does the agent ever call the payment provider directly?

For consequential payments, route through a protected adapter that enforces the request-bound decision and resolves credentials. Direct model-to-provider access makes prompt injection and credential exposure harder to contain. Block alternate network and service-account routes and test from the agent runtime.

Where should supplier destinations live?

Keep executable destinations in a governed supplier or payment registry with independent change verification. Invoice text may propose a change but cannot activate it. The payment proposal should carry a stable destination ID, and the adapter resolves the actual rail details after authorization.

Which service owns payment status?

The local transaction service owns the workflow state while provider and ledger systems supply observations. The agent may explain state but should not set settlement. Define source ranking and permitted transitions. Preserve uncertainty and conflicting observations for operations.

How are protocols such as AP2 used?

Use protocol objects where ecosystem interoperability benefits from shared mandates and receipts. Map them to enterprise identity, authority, approval and provider records rather than assuming the protocol operates those systems. Version the mapping and verify signatures and context at the trust boundary.

What needs high availability?

Identity, policy, replay, reservation, adapter and reconciliation each have different failure requirements. Material payments may stop when fresh authority or atomic reservation is unavailable, while reconciliation continues from durable queues. Design availability around safe state, not just request success rate.

What is the first production slice?

Choose one buyer entity, payment method, currency, supplier set and approval rule. Keep destination creation outside the agent. Run provider simulations, uncertain-state drills and evidence reconstruction before live funds. Expand only after finance, security and operations accept the observed behavior.

Draw the accounting boundary as well as the API boundary. A provider's accepted response may create a pending payment, while the ledger, bank statement or treasury system records settlement later. Decide which service posts each accounting state and how reversals or returns enter the workflow. The agent can prepare a reconciliation case, but it should not close an invoice or release a budget reservation on the strength of its own summary. That decision belongs to deterministic rules over authoritative provider and finance records.

Treat every adapter as a versioned financial component. Record its provider contract, supported idempotency behavior, field mapping, timeout rules and evidence output. A seemingly small adapter update can change rounding, destination resolution or retry behavior without touching the agent. Run the payment fixtures against the adapter version that will handle live funds.