Paper deep dive
APEX: Agent Payment Execution with Policy for Autonomous Agent API Access
Mohd Safwan Uddin, Mohammed Mouzam, Mohammed Imran, Syed Badar Uddin Faizan
Intelligence
Status: succeeded | Model: google/gemini-3.1-flash-lite-preview | Prompt: intel-v1 | Confidence: 98%
Last extracted: 4/3/2026, 12:17:01 AM
Summary
APEX is a research system that implements HTTP 402-style payment gating for autonomous agents, specifically adapted for fiat-based systems like UPI. It provides a reference architecture for request-level monetization, programmatic spend governance, and secure tokenized access, featuring a challenge-settle-consume lifecycle with HMAC-signed tokens and idempotent settlement.
Entities (5)
Relation Signals (4)
APEX → implements → HTTP 402
confidence 100% · We present APEX, an implementation-complete research system that adapts HTTP 402-style payment gating
APEX → uses → FastAPI
confidence 100% · The system uses FastAPI, SQLite, and Python standard libraries
APEX → uses → SQLite
confidence 100% · The system uses FastAPI, SQLite, and Python standard libraries
APEX → supports → UPI
confidence 90% · adapts HTTP 402-style payment gating to UPI-like fiat workflows
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Autonomous agents are moving beyond simple retrieval tasks to become economic actors that invoke APIs, sequence workflows, and make real-time decisions. As this shift accelerates, API providers need request-level monetization with programmatic spend governance. The HTTP 402 protocol addresses this by treating payment as a first-class protocol event, but most implementations rely on cryptocurrency rails. In many deployment contexts, especially countries with strong real-time fiat systems like UPI, this assumption is misaligned with regulatory and infrastructure realities. We present APEX, an implementation-complete research system that adapts HTTP 402-style payment gating to UPI-like fiat workflows while preserving policy-governed spend control, tokenized access verification, and replay resistance. We implement a challenge-settle-consume lifecycle with HMAC-signed short-lived tokens, idempotent settlement handling, and policy-aware payment approval. The system uses FastAPI, SQLite, and Python standard libraries, making it transparent, inspectable, and reproducible. We evaluate APEX across three baselines and six scenarios using sample sizes 2-4x larger than initial experiments (N=20-40 per scenario). Results show that policy enforcement reduces total spending by 27.3% while maintaining 52.8% success rate for legitimate requests. Security mechanisms achieve 100% block rate for both replay attacks and invalid tokens with low latency overhead (19.6ms average). Multiple trial runs show low variance across scenarios, demonstrating high reproducibility with 95% confidence intervals. The primary contribution is a controlled agent-payment infrastructure and reference architecture that demonstrates how agentic access monetization can be adapted to fiat systems without discarding security and policy guarantees.
Tags
Links
- Source: https://arxiv.org/abs/2604.02023v1
- Canonical: https://arxiv.org/abs/2604.02023v1
Trouble viewing inline? Open PDF directly →
Full Text
48,423 characters extracted from source content.
Expand or collapse full text
APEX: Agent Payment Execution with Policy for Autonomous Agent API Access Mohd Safwan Uddin, Mohammed Mouzam, Mohammed Imran, Syed Badar Uddin Faizan Abstract Autonomous agents are moving beyond simple retrieval tasks to become economic actors that invoke APIs, sequence workflows, and make real-time decisions. As this shift accelerates, API providers need request-level monetization with programmatic spend governance. The HTTP 402 protocol addresses this by treating payment as a first-class protocol event, but most implementations rely on cryptocurrency rails. In many deployment contexts—especially countries with strong real-time fiat systems like UPI—this assumption is misaligned with regulatory and infrastructure realities. We present APEX, an implementation-complete research system that adapts HTTP 402-style payment gating to UPI-like fiat workflows while preserving policy-governed spend control, tokenized access verification, and replay resistance. We implement a challenge-settle-consume lifecycle with HMAC-signed short-lived tokens, idempotent settlement handling, and policy-aware payment approval. The system uses FastAPI, SQLite, and Python standard libraries, making it transparent, inspectable, and reproducible. We evaluate APEX across three baselines (no policy, payment without policy, payment with policy) and six scenarios (normal, overspending, replay attack, invalid token, token expiry, idempotency) using sample sizes 2-4x larger than initial experiments (N=20-40 per scenario). Results show that policy enforcement reduces total spending by 27.3% ($550 to $400) while maintaining 52.8% success rate for legitimate requests. Security mechanisms achieve 100% block rate for both replay attacks (20/20 blocked) and invalid tokens (20/20 blocked) with low latency overhead (19.6ms average). Multiple trial runs show low variance (±2.7-8.9ms standard deviation) across scenarios, demonstrating high reproducibility with 95% confidence intervals. Payment gating introduces 86.9ms average latency overhead compared to 8.0ms baseline, representing a 10.9x slowdown that remains acceptable for controlled agent payment workflows in research contexts. The primary contribution is a controlled agent-payment infrastructure and reference architecture that demonstrates how agentic access monetization can be adapted to fiat systems without discarding security and policy guarantees. I Introduction Autonomous agents are moving beyond simple retrieval tasks. They now invoke APIs, sequence multi-step workflows, and make bounded execution decisions in real time [10, 11, 12]. As this shift accelerates, API providers increasingly require request-level monetization and spend governance that can be enforced programmatically, not manually. The emerging HTTP 402-oriented ecosystem addresses this need by treating payment as a first-class protocol event, not an afterthought in monthly invoicing pipelines. In this interaction model, an unpaid request receives a machine-readable payment challenge, and the client retries with proof of payment. This pattern is attractive for agent-to-agent markets, where low-friction, small-value, high-frequency transactions are common. Yet most practical demonstrations around this direction are tightly linked to blockchain rails. In many deployment contexts, that assumption is misaligned with regulatory, user, and infrastructure realities. In countries like India where UPI processes billions of transactions monthly [14, 15], agents need to work with fiat systems, not crypto. The research question is therefore direct: can we preserve the architectural strengths of 402-style access control while grounding settlement semantics in fiat-like flows and enforcing policy at payment time? This paper answers that question through APEX, an implementation-complete reference architecture built for controlled experimentation. The system is intentionally scoped to protocol behavior, policy enforcement, security invariants, structured logging, and repeatable scenario-based measurements rather than full banking integration. APEX contributes five practical elements. First, it adapts a challenge-based 402 interaction to a UPI-like payment abstraction, keeping the developer-facing API simple. Second, it enforces spend control using request limits and daily budget policy checks as the primary control boundary. Third, it secures post-payment access with signed, expiring, single-use tokens. Fourth, it supports idempotent settlement to reduce duplicate side effects under retries. Fifth, it includes an experiment harness that directly compares baseline behavior under normal and adversarial patterns. I-A Key Contributions We make four concrete contributions aimed at reproducible systems research. 1. Fiat-oriented protocol adaptation: An HTTP 402-style challenge-settle-retry pattern mapped to UPI-like payment semantics for agent-executed API access. 2. Policy-governed payment control: Deterministic per-request and daily budget enforcement integrated directly into settlement decisions. 3. Security-complete token lifecycle: Signed, expiring, single-use tokens with replay rejection and idempotent settlement behavior under retries. 4. End-to-end reproducibility: Structured logs, scenario baselines, and machine-readable outputs that directly support publication tables and figures. A major design goal was a small dependency surface. The implementation uses FastAPI, SQLite, and standard Python libraries for cryptography, serialization, and timing, matching constraints common in reproducible systems research. This choice intentionally favors interpretability over feature breadth. The remainder of the paper is organized as follows. Section I reviews related work in HTTP 402, micropayments, agent systems, and payment policy control. Section I defines the problem, assumptions, and threat model. Section IV describes the APEX architecture and lifecycle. Section V defines system constraints and latency models. Section VI details implementation. Section VII documents experimental design. Section VIII reports results. Section IX discusses implications and limitations. Section X outlines future work, and Section XI concludes. I Related Work I-A HTTP 402 and Agent-Native Payment Flows The x402 protocol extends HTTP 402 to enable internet-native API monetization, where payment is integrated directly into request handling [1]. This positions 402 not merely as a legacy status code, but as a practical trigger for machine-interpretable payment challenges. Extensions like A402 explore atomic service channels and address latency concerns in payment settlement [2]. Recent work examines how 402-style semantics could enable autonomous transactions between software agents [3, 4, 5]. These works establish architectural motivation, but most available artifacts remain focused on crypto rails. The fiat adaptation problem remains under-explored, especially for systems intended to interoperate with UPI-like abstractions. APEX addresses that adaptation gap with a strict, inspectable implementation scope and an explicit policy boundary, where spend governance is the decision point that distinguishes controlled agent monetization from simple payment transport. I-B Micropayments and Settlement Infrastructure Micropayment literature emphasizes fee efficiency, settlement reliability, and machine-scale throughput. Systems such as MicroCash and Lightning-based designs discuss probabilistic, off-chain, or channel-based mechanisms for very small transactions [6, 7, 8, 9]. These studies are valuable for performance intuition, but deployment assumptions differ from fiat-led payment ecosystems. In fiat systems, especially near-real-time rails, compliance, identity, and institutional integration constraints dominate design decisions. A practical system in this setting must expose where protocol-level ideas transfer directly, and where architecture must diverge. I-C AI Agents and API Execution Agent frameworks continue to evolve from reasoning-only systems toward tool-using systems that execute side effects. ReAct, Toolformer, and autonomous agent frameworks illustrate this progression [10, 11, 12]. As execution autonomy increases, spend and access controls become mandatory, not optional. Survey work on web-capable agents also highlights risks tied to unconstrained tool invocation and external action loops [13]. APEX situates itself in this execution-centric framing. Its value is not in generalized cognition, but in disciplined payment-mediated API access for controlled agent behavior. I-D UPI and Real-Time Fiat Systems UPI literature and policy analyses document large-scale adoption, low settlement latency, and broad user accessibility, making UPI-like rails strategically relevant for research on practical agentic payments [14, 15, 16]. While these sources do not define agent protocols, they provide the operational context motivating fiat-oriented implementations. I-E Policy Enforcement and API Control Policy-governed API execution is established in rate limiting, budget governance, and adaptive gateway design [17, 18, 19]. APEX draws from this line of work by enforcing bounded per-request and cumulative spend policies at payment-time, with deterministic reject behavior under violations. I-F Research Gap The current landscape still lacks open, reproducible systems that combine: (1) a 402-like challenge flow, (2) fiat-oriented settlement semantics, (3) explicit policy controls, (4) tokenized replay-resistant verification, and (5) benchmark-style scenario experiments with exportable metrics. APEX is designed as a direct contribution to this specific gap. Table I positions APEX against representative x402-style systems at a high level. TABLE I: Comparison with Existing x402-based Systems Feature x402 APEX Fiat support No Yes Policy control Limited Yes Replay protection Partial Strong Experimental validation Limited Yes I Problem Statement and Scope I-A Core Problem Given an API endpoint that should only return protected data after successful payment, we require a machine-executable protocol that: 1. challenges unpaid requests with structured payment details, 2. accepts a payment settlement attempt, 3. validates payment proof on subsequent access, 4. enforces spend policy constraints, 5. prevents replay and token forgery abuse, 6. and provides measurable logs for empirical evaluation. The problem is constrained to request-level payments, not subscriptions, not credit models, and not invoice post-processing. I-B Design Objectives APEX was developed under five explicit objectives. 1. Protocol clarity: A simple and explicit challenge-settle-consume state progression. 2. Policy determinism: Hard rejection when request amount or daily budget constraints are violated. 3. Security by default: Short-lived signed tokens, single-use semantics, and replay rejection. 4. Operational observability: Append-only structured logs with status, reason, latency, and endpoint context. 5. Experimental reproducibility: Built-in scenario runner that exports comparable metrics for paper tables and figures. I-C Out of Scope The following are intentionally excluded from this implementation scope. 1. Real bank settlement integration, KYC, and financial compliance workflows. 2. Horizontal distributed consensus or multi-node fault tolerance. 3. End-user UI/UX design and payment confirmation interfaces. 4. Production-grade secrets management and HSM-backed signing. 5. Formal verification of protocol implementation. These exclusions preserve focus on architectural and experimental clarity. IV System Model and Threat Model IV-A System Entities APEX models five entities. 1. Client Agent: Calls the protected endpoint, parses challenge details, and performs settlement attempts. 2. Protected API: Exposes /data and returns either a challenge or protected payload. 3. Payment API: Exposes /pay, performs policy checks, settles payment state, and returns verification token. 4. Ledger Store: SQLite table recording state, tokens, amount, and idempotency metadata. 5. Policy Engine: Evaluates per-request and cumulative spend constraints. IV-B Adversary Capabilities The adversary can: 1. call endpoints without payment, 2. replay a previously consumed token, 3. submit malformed or forged tokens, 4. attempt overspending through repeated calls, 5. and trigger duplicate settlement requests. The adversary cannot: 1. compromise server-side secret key storage, 2. alter server code at runtime, 3. or tamper with database files directly. IV-C Security Goals APEX aims to satisfy four goals. 1. G1 - Access control: Protected data is returned only after valid settlement evidence. 2. G2 - Integrity: Forged tokens are rejected. 3. G3 - Replay resistance: Consumed tokens cannot grant repeated access. 4. G4 - Policy enforcement: Requests violating spend constraints are blocked deterministically. IV-D Failure Categories Observed outcomes are grouped into: 1. success 2. blocked 3. failed This triad is used consistently across API responses, structured logs, and experiment summaries. Figure 1 summarizes the security boundary and attack surfaces considered in this work. Attacker NodeAPI Server(/data, /pay)Token Service(verify + expiry + consume)Policy Engine(max/request + daily budget) Defended Backend SurfaceA1A2A3A1: invalid tokenA2: replay attemptA3: overspending flood Figure 1: Threat Model and Attack Surfaces V APEX Architecture V-A Endpoint Overview The architecture centers around two externally invoked endpoints and one auxiliary reset endpoint used for controlled experiments. Figure 2 presents the end-to-end APEX architecture, including challenge, policy, settlement, verification, and response components. Figure 3 provides a single integrated control, security, and payment-flow view for quick system understanding. AI AgentProtected ResponseAPI ServerHTTP 402Policy EnginePayment LayerUPI-like settleToken Serviceverify/consumeLedger DB APEX BackendNormal flowResponse / successPolicyTokenFailure / security Figure 2: System Architecture of APEX 1 Agent Request2 402 Challenge3 Payment Settle4 Token Issue5 Verify & ConsumePolicy:max/requestPolicy:daily budgetSecurity:replay rejectSecurity:invalid token reject Control PlaneSecurity Plane Figure 3: End-to-End APEX System Overview 1. GET /data (a) If baseline is no_policy, returns protected data directly. (b) If no payment token is provided, creates challenge record and returns HTTP 402 with ref_id and amount. (c) If token is provided, verifies signature and expiry, then attempts token consumption. (d) Returns data only if token is valid and consumable. 2. POST /pay (a) Receives ref_id, amount, baseline, and optional idempotency key. (b) Evaluates policy according to baseline. (c) Issues signed token with expiry. (d) Settles payment state transactionally. (e) Returns token and state metadata on success. 3. POST /reset (a) Clears ledger table for reproducible scenario execution. V-B State Machine Each request reference moves through a strict state sequence: 1. CHALLENGED: challenge created at unpaid /data request. 2. INITIATED: settlement process started. 3. SETTLED: payment accepted, token attached, idempotency key recorded. 4. CONSUMED: first valid token use grants data and consumes entitlement. Transitions are implemented with SQLite transactions using BEGIN IMMEDIATE to reduce race risks in single-node operation. V-C Data Model The payment ledger stores: 1. ref_id (primary key) 2. amount 3. created_at 4. state 5. token 6. token_expiry 7. consumed_at 8. idempotency_key Indexes are maintained for state and token to support lookup efficiency in the system. V-D Baseline Modes APEX explicitly supports three comparative baselines. 1. no_policy: No payment gating, direct access path, no spend control. 2. payment_no_policy: Payment challenge and token verification enabled, policy checks disabled. 3. payment_with_policy: Full payment and policy controls enabled. These modes are selected per request to enable side-by-side controlled experiments under identical runtime stack. VI Protocol Walkthrough VI-A Normal Access Sequence The standard sequence is: 1. Agent calls GET /data with baseline payment_with_policy. 2. Server responds 402 with challenge payload including ref_id and amount. 3. Agent calls POST /pay with challenge values. 4. Policy is evaluated. 5. Token is issued and settlement state becomes SETTLED. 6. Agent retries GET /data with x-payment-token. 7. Token is verified and consumed. 8. Protected content is returned. Key failure and security branches are illustrated in Figure 4. AgentAPIPaymentTokenPolicyReplay Attack1. reuse token2. verify3. replay detected4. blockedInvalid Token1. invalid token2. verify3. rejectedOverspending1. POST /pay2. budget check3. blocked Figure 4: Failure and Security Scenarios in APEX VI-B Replay Attempt Sequence Replay handling follows: 1. First token use succeeds and sets state to CONSUMED. 2. Second use of same token triggers token_already_consumed path. 3. Server returns blocked response. VI-C Invalid Token Sequence Invalid token handling follows: 1. Client sends malformed or forged token. 2. Signature or format verification fails. 3. Request is blocked with explicit reason, for example invalid_token_format or invalid_signature. VI-D Overspending Sequence Overspending handling follows: 1. Policy computes current day spend from settled or consumed records. 2. If spent_today + amount > daily_budget, request is blocked. 3. No settlement token is returned. VII System Constraints and Guarantees VII-A Budget Constraint Let xi∈0,1x_i∈\0,1\ denote APEX’s admission decision for request i and let cic_i denote request cost. For one budget window, the policy engine enforces: ∑i∈Aci≤B, _i∈ Ac_i≤ B, (1) where A=i∣xi=1A=\i x_i=1\ is the accepted request set and B is the configured budget. For day-indexed notation, this is equivalent to: ∑i∈Adci≤Bd _i∈ A_dc_i≤ B_d (2) where BdB_d is the configured daily budget. In the current system, Bd=100B_d=100. This constraint is enforced before payment settlement is committed. VII-B Utility under Budget (Optimization View) Admission decisions can be modeled as constrained utility maximization: maxxi∈0,1∑i=1nuixis.t.∑i=1ncixi≤B, _x_i∈\0,1\ _i=1^nu_ix_i .t. _i=1^nc_ix_i≤ B, (3) where uiu_i is request utility and cic_i is request cost. APEX currently implements a feasibility-first online policy (accept only when constraints are satisfied), which corresponds to a simplified constrained-optimization policy with strict budget compliance. VII-C Per-Request Constraint For each payment attempt amount a, policy requires: a≤Ma≤ M (4) where M is maximum per-request amount. In current configuration, M=10M=10. VII-D Token Validity A token payload contains (ref_id,amount,exp)(ref\_id,amount,exp) and an HMAC signature. Token validity requires: VerifyHMAC(payload,signature,key)=trueVerifyHMAC(payload,signature,key)=true (5) and exp≥tnowexp≥ t_now (6) with single-use condition: state(ref_id)=SETTLEDstate(ref\_id)=SETTLED (7) before consumption, after which: state(ref_id)←CONSUMEDstate(ref\_id)← CONSUMED (8) VII-E Latency Decomposition End-to-end round latency for one payment-gated success can be approximated by: Ttotal=Tnetwork+Tpayment+Tpolicy+Tprocessing.T_total=T_network+T_payment+T_policy+T_processing. (9) In APEX, TpaymentT_payment captures settlement and token work, TpolicyT_policy captures budget/validation checks, and TprocessingT_processing captures API and storage processing. This decomposition explains baseline differences: no_policy minimizes TpaymentT_payment and TpolicyT_policy, payment_no_policy activates payment logic with reduced policy checks, and payment_with_policy activates all terms. VIII Implementation Details VIII-A Technology Stack The implementation intentionally uses a narrow stack: 1. FastAPI for request routing and structured error handling. 2. SQLite for local transactional ledger persistence. 3. Python standard library modules: json, time, hmac, hashlib, base64, urllib, pathlib, datetime. No external logging, crypto, or data processing frameworks are required for baseline operation. VIII-B Token Service The token service performs: 1. payload construction with expiry, 2. stable JSON serialization, 3. HMAC-SHA256 signature generation, 4. URL-safe base64 payload packing, 5. split-and-verify parsing on incoming tokens. Failure reasons are explicit, including: 1. invalid_token_format 2. invalid_signature 3. token_expired VIII-C Ledger Service The ledger service encapsulates challenge creation, settlement, and token consumption. Challenge creation: Inserts or replaces a record in CHALLENGED state. Settlement: Checks reference existence, amount consistency, idempotency conditions, and current state. On success, transitions through INITIATED to SETTLED and stores token metadata. Consumption: Valid only for SETTLED records with matching token. Transitions to CONSUMED and writes timestamp. VIII-D Idempotency Handling If a settlement is retried with the same idempotency key, APEX returns prior settled token details (idempotent_replay path), preventing duplicate side effects. If the same reference is retried with a different idempotency key after settlement, it is rejected. VIII-E Policy Service Policy service supports mode-aware evaluation. 1. If policy disabled baseline is chosen, request is allowed with reason policy_disabled. 2. Else, max-per-request and daily budget constraints are evaluated. 3. Violations return blocked decision and explicit textual reason. VIII-F Structured Logging Service Every significant event appends one JSON line to logs.json. Fields include: 1. timestamp 2. event_type 3. endpoint 4. request_id 5. ref_id 6. amount 7. status 8. reason 9. attack_type (optional) 10. latency_ms (optional) The append-only line-delimited format is chosen for simplicity, low overhead, and easy downstream aggregation. VIII-G Experiment Driver The experiment script automates: 1. baseline selection, 2. mode-based scenario execution, 3. run-level console output, 4. summary metric aggregation, 5. JSON export to experiments/quick_results.json. Console output format is intentionally compact, for example: RUN 1 SUCCESS - latency: 120ms RUN 2 BLOCKED - reason: daily_budget exceeded RUN 3 FAILED - reason: invalid_token_format IX Experimental Methodology IX-A Goals Evaluation aims to answer four questions. 1. Can policy controls effectively bound spending? 2. Are replay and invalid token attempts consistently blocked? 3. What latency and throughput overhead appears under payment gating? 4. How do outcomes differ across baseline modes? IX-B Baselines Three baseline conditions are executed: 1. no_policy 2. payment_no_policy 3. payment_with_policy IX-C Scenarios Six scenarios are run for each baseline: 1. normal (20 requests per trial, 2 trials = 40 total) 2. overspending (15 requests per trial, 2 trials = 30 total) 3. replay_attack (10 requests per trial, 2 trials = 20 total) 4. invalid_token (10 requests per trial, 2 trials = 20 total) 5. token_expiry (5 requests per trial, 2 trials = 10 total) 6. idempotency (5 requests per trial, 2 trials = 10 total) We run each scenario twice to ensure reproducibility. Total requests per baseline: 120. Total across all baselines: 360. This represents a 2-4x increase in sample sizes compared to initial experiments, with two new scenarios (token_expiry and idempotency) added to validate complete token lifecycle management. IX-D Metrics Per scenario summary includes: 1. success rate 2. blocked requests 3. failed requests 4. average latency 5. 95% confidence interval 6. p95 latency 7. throughput (requests per second) 8. total spend IX-E Reproducibility Procedure To reproduce runs: 1. Start server: uvicorn backend.main:app --reload 2. In separate terminal run experiments: python experiments/enhanced_test_flow.py 3. Collect outputs: experiments/quick_results.json and logs.json. 4. Regenerate summary tables in manuscript from exported JSON. X Results X-A Baseline-Level Comparison Table I reports weighted aggregate outcomes across all scenarios, using values generated from the enhanced experimental results in experiments/quick_results.json. TABLE I: Baseline Comparison Across All Scenarios Baseline Success Blocked Avg Lat. p95 Lat. Spend Std Dev Rate Req. (ms) (ms) Total ($) (ms) no_policy 1.000 0 8.0 13.6 0.0 0.6 payment_no_policy 0.667 40 442.0 495.5 550.0 27.7 payment_with_policy 0.528 70 477.0 549.1 400.0 75.7 The first observation is expected: no_policy is fastest, as it bypasses challenge, settlement, verification, and consumption paths. However, it offers no spend governance and no meaningful payment security semantics. The second observation is more informative. Compared to payment_no_policy, payment_with_policy reduces total spend from $550 to $400, representing a 27.3% reduction ($150 savings). This occurs because policy enforcement blocks requests after budget exhaustion, preventing unchecked spending. The success rate of 52.8% for policy-enabled execution reflects intentional blocking of budget-exceeding requests rather than system failure. At aggregate baseline level, policy-enabled runs show higher latency than payment-only runs because policy checks are always active and scenario mix includes stricter control paths. Under overspending and adversarial branches, early policy rejection still short-circuits settlement work and reduces per-request path cost. The key insight is that policy acts as a safety mechanism for autonomous agents—without policy, a buggy agent could exhaust budgets through unchecked API calls. X-B Policy Baseline Scenario Breakdown Table I isolates payment_with_policy by scenario. TABLE I: Scenario Analysis for payment_with_policy Baseline Scenario Success Blocked Avg Lat. CI 95% p95 Lat. Spend Rate Req. (ms) (ms) (ms) ($) normal 0.500 20 86.9 ±8.9 132.5 100.0 overspending 0.667 10 88.5 ±8.8 125.8 100.0 replay_attack 0.000 20 135.1 ±5.2 172.1 100.0 invalid_token 0.000 20 19.6 ±5.9 31.7 0.0 token_expiry 1.000 0 2119.9 ±10.0 2138.3 50.0 idempotency 1.000 0 412.2 ±851.9 694.0 50.0 Normal mode confirms the expected successful path when constraints are satisfied, though budget limits are reached after 10 requests (50% success rate). Overspending and stress modes show deterministic blocking behavior once budget constraints are hit. Replay attack runs demonstrate post-consumption denial with 100% block rate (20/20 attempts blocked). Invalid token scenario shows low-latency rejection at 19.6ms average, as no settlement lookup or state transition can proceed—these fail signature verification before database access. Token expiry tests confirm tokens remain valid within TTL (300 seconds), with all 10 attempts succeeding when tokens are used within the validity window. The high latency (2119.9ms) includes an intentional 2-second sleep to approach the TTL boundary, so this metric reflects test design rather than system overhead. Idempotency tests validate duplicate payment prevention, with all 10 attempts correctly returning the same token for identical idempotency keys. The high variance (±851.9ms) suggests timing inconsistency in the idempotency path that warrants further investigation. Overall, policy enforcement reduces total spending from $550 to $400 (27.3% reduction), while security checks maintain a 100% block rate for replay and invalid-token attacks, and repeated trials show low variance (±2.7-8.9ms) for most scenarios. The latency overhead for policy-enabled execution is 86.9ms average for normal flow compared to 8.0ms for no-policy baseline. This 10.9x increase is acceptable for controlled agent payment workflows in research contexts. Importantly, policy rejection paths terminate earlier than full payment flows, which explains why policy-enabled runs sometimes show lower aggregate latency than payment-only runs under adversarial scenarios. X-C Visualization from Exported Figures The generated figure artifacts provide quick visual interpretation. Each figure uses a consistent style, explicit axis labeling, and baseline/scenario legends for publication readability. Figure 8 additionally summarizes the control-overhead tradeoff between unrestricted and policy-governed execution. Figure 5 reports comparative success rates, Figure 6 reports latency differences, and Figure 7 highlights allowed-versus-blocked behavior under policy enforcement. Figure 5: Success rate comparison across baselines and scenarios. Figure 6: Average latency comparison for measured scenarios. Figure 7: Blocked versus allowed behavior under policy-sensitive modes. Figure 8: Policy Control vs Latency Tradeoff Across Baselines. X-D Interpretation From a research perspective, APEX demonstrates a useful tradeoff frontier. Unrestricted access yields best raw latency, but no monetization safeguards. Payment gating without policy captures economic intent, but can still permit undesirable cumulative spend. Full policy mode introduces stricter outcomes, with predictable blocking and bounded spend. The outcome profile is especially relevant for autonomous agents, where unattended loops can amplify both benign and malicious behavior. Deterministic spend ceilings and explicit rejection reasons help maintain operational control. These observations align with the system constraints in Section V. Under the budget-constrained decision model, APEX intentionally trades acceptance volume for bounded spend, which explains lower cumulative spend in payment_with_policy compared with payment_no_policy. Under the latency decomposition, early policy rejection removes downstream payment and processing work, which explains why policy-enabled runs can show lower aggregate latency than payment-only runs under overspending and stress traffic. XI Security and Robustness Analysis XI-A Formal Security Guarantees Guarantee G1 (Bounded Spend). Assume policy checks are enforced before settlement commit and each accepted request has cost ci≥0c_i≥ 0. Then, for any request sequence (including adversarial overspending attempts), ∑i:xi=1ci≤B. _i:\,x_i=1c_i≤ B. (10) Therefore, monetary damage per budget window is upper-bounded by the configured budget B. Guarantee G2 (Replay Blocking under Consume-Once Semantics). Assume a token is accepted only if signature verification succeeds, expiry is valid, and token state is not consumed. Under this rule, for bit-for-bit replay of a previously consumed token, P(replay success)=0.P(replay success)=0. (11) This follows from the irreversible state transition SETTLED → CONSUMED and rejection of consumed tokens. XI-B Experimental Security Validation We validate security properties through adversarial scenarios. Replay attack tests show 100% block rate (20/20 attempts blocked) with average latency of 135.1ms (±5.2ms CI). Invalid token tests similarly achieve 100% block rate (20/20 blocked) with faster rejection at 19.6ms (±5.9ms CI), as these fail signature verification before database lookup. Token expiry tests confirm tokens remain valid within TTL (300 seconds). All 10 attempts succeeded with tokens used within the validity window. Idempotency tests validate duplicate payment prevention, with all 10 attempts correctly returning the same token for identical idempotency keys. XI-C Replay Resistance Replay resistance relies on two coordinated checks: 1. token validity checks on signature and expiry, 2. stateful one-time consumption semantics in ledger. Even if a token remains cryptographically valid before expiry, its second use fails once state is CONSUMED. This combination is stronger than stateless verification alone. Signature checks alone are insufficient—we need the state transition from SETTLED to CONSUMED to prevent token reuse. XI-D Forgery Resistance HMAC-based signatures prevent straightforward token tampering, assuming secret key confidentiality. Any mutation to payload fields, including amount or reference, invalidates signature equivalence. XI-E Idempotency and Duplicate Protection Settlement retries are common in real distributed clients. APEX avoids duplicate side effects by honoring same-key retries while rejecting conflicting duplicate attempts. This behavior improves reliability under network retries and partially mitigates double-settlement conditions in single-node scope. XI-F Policy Robustness Policy checks occur before settlement persistence, ensuring rejected requests do not produce paid state artifacts. Because daily spend is computed from SETTLED and CONSUMED records, challenge-only requests do not inflate spend counters. XI-G Operational Traceability Structured logs include reasons and status at each major decision point. This is critical for: 1. auditability, 2. post-run analysis, 3. regression detection, 4. and paper-quality metric reconstruction. XII Discussion XII-A Policy Effectiveness Policy enforcement successfully bounds spending while maintaining service availability. In our experiments, policy reduced total spend by 27.3% ($150 savings) compared to payment-without-policy baseline. The success rate of 52.8% for policy-enabled execution reflects intentional blocking of budget-exceeding requests rather than system failure. The key insight is that policy acts as a safety mechanism for autonomous agents. Without policy, a buggy agent could exhaust budgets through unchecked API calls. With policy, spending stops deterministically at configured limits. XII-B Security Properties Security mechanisms provide deterministic threat mitigation. The 100% block rate for replay attacks and invalid tokens demonstrates that HMAC-signed tokens with single-use semantics effectively prevent common attack patterns. Low variance across trials (±2.7-5.9ms) indicates consistent security behavior. XII-C Performance Tradeoffs Payment gating introduces latency overhead (86.9ms vs 8.0ms baseline), but this remains acceptable for agent workflows where spend control outweighs raw speed. The overhead comes primarily from payment settlement and token generation, not policy checks (which add minimal latency). Interestingly, policy-enabled runs sometimes show lower aggregate latency than payment-only runs under adversarial scenarios. This occurs because policy rejection terminates requests early, avoiding expensive settlement operations. XII-D Reproducibility Low variance across multiple trials validates our experimental approach. Standard deviations of ±2.7-8.9ms for most scenarios indicate stable, reproducible behavior. The exception is idempotency testing (±434.6ms variance), which requires further investigation. XII-E Limitations Our study has important limitations. First, the single-node SQLite architecture doesn’t reflect distributed contention patterns. Second, UPI integration is simulated rather than connected to real payment providers. Third, sample sizes (N=20-40) provide initial validation but larger-scale experiments would strengthen confidence. Fourth, we focus on specific attack patterns (replay, invalid tokens) rather than comprehensive adversarial testing. These limitations are intentional tradeoffs for experimental clarity and reproducibility. We prioritize transparent, inspectable implementation over production-scale deployment. XIII Ablation-Oriented Observations Although the current experiment script is scenario-focused rather than full component ablation, several behavior-level observations can be interpreted as practical ablations. XIII-A Payment Layer Ablation Comparing no_policy against payment baselines isolates payment-layer overhead. Result: lower latency but no spending signal, no token controls, and no replay semantics. XIII-B Policy Layer Ablation Comparing payment_no_policy against payment_with_policy isolates policy effects. Result: policy reduces cumulative spend and raises blocked count in adversarial/overspending scenarios, reflecting intended guardrail behavior. XIII-C Security Path Ablation by Scenario Replay and invalid token scenarios isolate security paths. Result: replay is blocked after first consumption; invalid tokens are blocked quickly. These two scenario classes provide direct evidence that token validation and stateful consumption are functionally active. XIV Practical Implications XIV-A For API Providers APEX-like architecture suggests that providers can implement request-level monetization controls incrementally, starting from deterministic challenge-response design and local policy enforcement, before introducing full banking integrations. XIV-B For Agent Developers Agent clients should treat payment operations as stateful protocol steps, not blind retries. The implementation highlights best practices: 1. preserve ref_id integrity, 2. use stable idempotency keys, 3. handle blocked responses as control signals, 4. avoid token reuse assumptions. XIV-C For Researchers APEX provides a controlled evaluation environment where protocol, policy, and security behavior can be measured together, which is often difficult in larger platform stacks. XV Future Work Future extensions are planned in six directions. 1. Distributed ledger backend: Migrate from single SQLite file to replicated transactional datastore and study consistency under concurrency. 2. Real PSP integration: Replace simulated UPI link abstraction with sandboxed payment provider callbacks and asynchronous settlement reconciliation. 3. Policy extensibility: Add per-agent, per-endpoint, and risk-adaptive budget strategies, possibly with temporal quotas. 4. Cryptographic hardening: Introduce key rotation, key identifiers, and optional detached signatures with algorithm agility. 5. Extended attack corpus: Include token theft simulation, header replay windows, duplicate challenge races, and malformed payload fuzzing. 6. Automated report pipeline: Generate manuscript-ready tables directly from the enhanced results JSON, minimizing manual transcription risk. XVI Conclusion This paper presented APEX, a reference architecture that maps a 402-style payment-gated API model onto a fiat-oriented UPI-like interaction pattern, while preserving critical controls for policy enforcement, security, and measurement. The implementation demonstrates that even a minimal stack can enforce meaningful guarantees: explicit payment challenging, stateful settlement, signed expiring tokens, single-use entitlement, idempotent retry handling, spend policy checks, and structured event logs. Experimental runs across baselines and adversarial scenarios show coherent, explainable behavior: no-policy mode remains fastest but unconstrained; payment gating introduces overhead but establishes monetization semantics; policy-enabled mode bounds spending and blocks abusive patterns as intended. APEX is therefore a useful reference architecture for research on agentic API payments in fiat ecosystems. Its value lies in reproducibility, clarity, and direct extensibility, rather than breadth of features. By releasing a complete and inspectable implementation with scenario instrumentation, this work aims to accelerate rigorous, comparable experimentation in a rapidly evolving domain. Acknowledgment The authors thank the open research community for public protocol, payment, and agent-systems references that informed this study. Appendix A Endpoint Contracts (Condensed) A-A GET /data Request parameters: 1. baseline: one of no_policy, payment_no_policy, payment_with_policy. 2. optional header x-payment-token. Typical challenge response: "detail": "amount": 10.0, "ref_id": "...", "baseline": "payment_with_policy", "upi_link": "upi://pay?...", "message": "Payment Required" Typical success response: "status": "ok", "baseline": "payment_with_policy", "data": "title": "Protected research data", "content": "..." A-B POST /pay Request body: "ref_id": "...", "amount": 10.0, "baseline": "payment_with_policy", "idempotency_key": "..." Typical success response: "status": "success", "ref_id": "...", "amount": 10.0, "token": "<signed token>", "token_expiry": 1712345678, "state": "SETTLED" Typical blocked response detail: "allowed": false, "reason": "daily_budget exceeded (...)" Appendix B Structured Log Schema Each line in logs.json is a JSON object. Table IV summarizes key fields. TABLE IV: Structured log fields Field Meaning timestamp UTC event timestamp event_type request, payment, or policy event category endpoint endpoint string, for example /data or /pay request_id per-request UUID generated by server ref_id challenge/settlement correlation identifier amount payment amount context status success, blocked, or failed reason human-readable decision reason attack_type optional scenario label for blocked/failed paths latency_ms optional measured endpoint latency Appendix C Extended Reproducibility Notes This section provides practical run notes for consistent output across machines. C-A Environment 1. Python 3.10+ recommended. 2. Install dependencies from requirements.txt. 3. Ensure no stale server process occupies port 8000. C-B Database Initialization On startup, server initializes schema and creates missing columns/indexes. A reset endpoint is available for clean scenario boundaries. C-C Artifacts to Preserve For paper traceability, preserve: 1. logs.json 2. experiments/quick_results.json 3. generated figure files in docs/figures 4. LaTeX source and compilation log. C-D Potential Source of Variance Small latency variations are expected due to local CPU scheduling, I/O contention, and development server reload behavior. Functional outcome trends should remain stable. Appendix D Supplementary Result Tables The following tables report exact per-scenario values from experiments/quick_results.json. Table V, Table VI, and Table VII are included for reproducibility and reviewer-side verification. TABLE V: Detailed scenario metrics for no_policy baseline Scenario Success Blocked Avg Lat. Spend Rate Req. (ms) Total normal 1.000 0 9.2 0.0 overspending 1.000 0 8.7 0.0 replay_attack 1.000 0 8.4 0.0 invalid_token 1.000 0 8.4 0.0 token_expiry 1.000 0 7.5 0.0 idempotency 1.000 0 7.8 0.0 TABLE VI: Detailed scenario metrics for payment_no_policy baseline Scenario Success Blocked Avg Lat. Spend Rate Req. (ms) Total normal 1.000 0 107.4 200.0 overspending 1.000 0 102.9 150.0 replay_attack 0.000 20 130.0 100.0 invalid_token 0.000 20 20.5 0.0 token_expiry 1.000 0 2115.0 50.0 idempotency 1.000 0 405.0 50.0 TABLE VII: Detailed scenario metrics for payment_with_policy baseline Scenario Success Blocked Avg Lat. Spend Rate Req. (ms) Total normal 0.500 20 86.9 100.0 overspending 0.667 10 88.5 100.0 replay_attack 0.000 20 135.1 100.0 invalid_token 0.000 20 19.6 0.0 token_expiry 1.000 0 2119.9 50.0 idempotency 1.000 0 412.2 50.0 Appendix E Additional Clarifications This section addresses common interpretation questions in concise form. E-A Why not use blockchain in the system? Because research objective is fiat adaptation of protocol semantics, not cryptographic settlement novelty. A minimal fiat-like abstraction is sufficient to evaluate policy, security, and latency behavior in the target design space. E-B Why SQLite? SQLite offers deterministic, inspectable, zero-ops persistence that is appropriate for controlled single-node experiments. Distributed behavior is future work, not ignored work. E-C How are citations selected? Citations are selected to connect four strands: HTTP 402 and agentic payments, micropayment infrastructure, agent execution systems, and policy/governance frameworks. E-D What is the key novelty? The novelty is an integrated, reproducible, fiat-oriented research system that joins protocol, policy, security, and experiment outputs in one compact implementation. Appendix F Checklist for Artifact Evaluation 1. Build environment from README instructions. 2. Start server and verify health by calling /data. 3. Run full experiment suite. 4. Confirm quick_results.json generated. 5. Confirm line-delimited logs.json entries generated. 6. Recreate baseline and scenario summary tables. 7. Verify replay and invalid token blocked outcomes. 8. Verify overspending blocks under policy baseline. Appendix G Extended Deployment Notes This appendix summarizes practical lessons without altering reported measurements. 1. Protocol transparency improves debuggability: The explicit challenge-settle-verify-consume chain makes failure diagnosis substantially easier than opaque gateway paths. 2. Policy must be inline with settlement: Evaluating policy before persistent settlement avoids inconsistent paid-state side effects. 3. Replay defense requires stateful consumption: Signature checks alone are insufficient; single-use state transitions are essential. 4. Structured logs are sufficient for research-grade observability: Normalized status and reason fields enabled reliable metric reconstruction. 5. Baseline triads improve causal interpretation: Using no-policy, payment-only, and payment+policy modes reduces ambiguity in overhead attribution. 6. Modular service boundaries ease migration: The token, ledger, policy, and logging split supports incremental backend substitution. 7. Spend bounds support autonomous reliability: Explicit ceilings reduce cost drift in unattended agent loops. 8. Tail latency reporting is necessary: Average values alone hide risk in control-heavy API paths. 9. Fiat-oriented adaptation lowers entry barriers: Teams can evaluate payment-governed access without immediate crypto infrastructure adoption. 10. Adversarial scenarios are mandatory for credible evaluation: Replay and invalid-token tests exposed control behavior that normal-only runs would miss. References [1] E. Reppel et al., “x402: Internet-Native Payments via HTTP,” 2025. [Online]. Available: https://w.x402.org/x402-whitepaper.pdf [2] “A402: Bridging Web3 Payments and Web2 Services,” 2026. [Online]. Available: https://arxiv.org/pdf/2603.01179.pdf [3] “Towards Multi-Agent Economies with HTTP 402,” 2025. [Online]. Available: https://arxiv.org/html/2507.19550v1 [4] “A Micro-Economic Framework for the Agentic Web,” 2026. [Online]. Available: https://arxiv.org/pdf/2603.16899.pdf [5] “The Trust Fabric: Decentralized Coordination for Agentic Web,” 2025. [Online]. Available: https://arxiv.org/pdf/2507.07901.pdf [6] “MicroCash: Practical Micropayment Processing,” 2019. [Online]. Available: https://arxiv.org/abs/1911.08520 [7] “Feeless Micropayments and New Business Models,” 2021. [Online]. Available: https://w.frontiersin.org/articles/10.3389/fbloc.2021.641508/full [8] “Enabling Micropayments on IoT using Lightning Network,” 2020. [Online]. Available: http://arxiv.org/abs/2012.10576 [9] “Lightning-Based Micropayment Framework for IoT,” 2020. [Online]. Available: http://sylvainkubler.fr/wp-content/themes/biopic/images/publications/documents/FGCS_2020.pdf [10] S. Yao et al., “ReAct: Synergizing Reasoning and Acting in Language Models,” ICLR, 2023. [11] T. Schick et al., “Toolformer: Language Models Can Teach Themselves to Use Tools,” NeurIPS, 2023. [12] T. Richards, “Auto-GPT: An Autonomous GPT-4 Experiment,” GitHub, 2023. [13] “Survey of WebAgents with Large Language Models,” 2025. [Online]. Available: https://arxiv.deeppaper.ai/papers/2503.23350v1 [14] BIS, “Digital Payments in India - UPI,” 2024. [Online]. Available: https://w.bis.org/publ/bppdf/bispap152_e_rh.pdf [15] “UPI Growth and Future Prospects,” 2025. [Online]. Available: https://academicjournal.ijraw.com/media/post/IJRAW-4-6-33.1.pdf [16] “Real-Time Payments Infrastructure Challenges,” 2020. [Online]. Available: https://w.ijirmps.org/papers/2020/5/232559.pdf [17] “API Rate Limit Adoption Patterns,” 2023. [Online]. Available: https://dl.acm.org/doi/10.1145/3628034.3628039 [18] “AI-Powered API Gateways for Adaptive Control,” 2024. [Online]. Available: http://ijaidsml.org/index.php/ijaidsml/article/download/273/250 [19] Google Cloud, “Budget API Access Control,” 2023. [Online]. Available: https://docs.cloud.google.com/billing/docs/how-to/budget-api-access-control [20] “Hybrid Serverless Computing and Pay-per-Use Systems,” 2022. [Online]. Available: https://arxiv.org/pdf/2208.04213.pdf