DropPay's Approach to Agentic AI Payments: One API for Humans and Agents

Most payment infrastructure was designed for a specific interaction pattern: a human opens a browser, selects a payment method, and completes a checkout flow. AI agents do not follow that pattern. They call APIs programmatically, need to pay for access in real time, and cannot authenticate through a browser or wallet UI.

DropPay handles both interaction patterns through a single API. A developer who integrates Embedded Checkout for human customers gets AI agent payment support with no additional work. This document explains how that works and what it means for developers building on the platform.

The design decision: unified API

When DropPay added support for AI agent payments, the approach was to extend the existing Embedded Checkout API rather than build a parallel system. The reasons for this were practical.

Separate payment paths for humans and agents would mean two integrations to maintain, two webhook schemas to handle, and two sets of payment records to reconcile. For a developer serving both customer types, this doubles the integration overhead without providing any additional capability.

A unified API means one integration, one webhook format, and one transaction log - regardless of whether the payer is a human or an agent. The payment confirmation looks the same. The webhook fires the same way. Fulfillment logic does not need to distinguish between customer types unless your product specifically requires it.

How the two paths work in practice

Human customers follow the standard Embedded Checkout flow. Your server creates a payment request via POST /payments/requests. The customer is redirected to the DropPay pay page, where they pay using Xaman or another XRP wallet. After payment confirms, they are redirected back to your site. Your webhook fires with the payment confirmation.

AI agents interact with the same endpoints but without a browser. The agent calls POST /payments/requests directly, reads the payment specification from the response, constructs and sends an XRP transaction on-chain, then calls POST /payments/{id}/verify with the transaction hash. The same webhook fires with the same payload.

The x402 protocol layer adds discoverability for agents that need to find payment requirements before making a request. When an agent hits a gated endpoint, your server returns HTTP 402 with the payment specification. The agent reads it, pays, and retries. See the x402 developer guide for the full protocol flow.

What this means for integration

If you have already built Embedded Checkout for human customers, AI agent support is largely a matter of making your API accessible to programmatic clients and implementing the x402 response if you want agents to discover payment requirements automatically.

Your existing webhook handler works without modification. The payment confirmation payload is identical. Your fulfillment logic can handle human and agent payments the same way, or branch on the transaction_type field if you need to treat them differently.

The developer documentation covers the full API reference including the payment request schema, verification endpoint, and webhook payload. The Embedded Checkout integration guide walks through the setup from scratch.

Why XRP is the right settlement layer for agent payments

AI agent payment use cases often involve high transaction frequency and small payment amounts. An agent making dozens of API calls per session, each requiring a small payment, needs a settlement layer where network fees do not make the economics unworkable.

XRP Ledger transactions confirm in 3 to 5 seconds with network fees under one cent. An agent can make repeated payments within a single session without fee accumulation making each call uneconomical. Card networks and most other blockchains do not have the right combination of speed, finality, and fee structure for this use case at scale.

Frequently asked questions

Do I need a separate DropPay account for agent payments? No. The same account and API key handle both human and agent payments. Pro is required for API access.

How do I identify which payments came from agents vs humans? The webhook payload includes a transaction_type field. Agent payments verified via the x402 flow are stamped with "x402". Payments from human customers show "api" or "dashboard" depending on how the payment request was created. The caller_wallet field shows the sending XRP address for every payment.

Can I restrict agent access to certain endpoints? Yes. Access control logic is in your application layer. You can allow or block specific XRP wallet addresses, implement rate limits per wallet, or gate agent access to specific endpoints while keeping others open to human customers.

Where can I find code examples? The developer documentation has examples for the payment request flow, x402 integration, and webhook handling. The AI agent payments overview covers the architecture and use cases.