AWS Builder Center

Builder Center

Building AgentPay on AWS: From an x402 Idea to a Serverless Agent-Commerce Platform

Building AgentPay on AWS: From an x402 Idea to a Serverless Agent-Commerce Platform

AI agents can call APIs, but buying from them safely requires discovery, immutable pricing, payment verification, replay protection, and reliable fulfillment. This is the complete story of how we designed and deployed AgentPay on AWS, what failed along the way, what we loved, and what we deliberately left for later.

Building AgentPay on AWS: From an x402 Idea to a Serverless Agent-Commerce Platform

AI agents can already search the web, call tools, write code, and invoke APIs.
However, most online commerce is still designed around a human opening a
website, reading a product page, completing a checkout form, and manually
triggering fulfillment.
We started AgentPay with one question:
What would a seller need to make an existing API safely discoverable and
purchasable by autonomous software?
The simple answer appeared to be “add an x402 payment endpoint.” The real
answer became much larger. A buyer agent needs to understand the product,
validate its inputs, know the exact price, check payment compatibility, retry
safely, and receive structured fulfillment. The seller needs control over what
is published, where funds settle, which route is called, and what happens when
payment succeeds but fulfillment fails.
This article covers our complete journey: how we narrowed the product, built
the local system, designed the AWS architecture, deployed it in Mumbai,
debugged real failures, controlled cost, and learned where serverless fintech
becomes difficult.

What AgentPay does

AgentPay is seller-first commerce infrastructure for API providers, SaaS
companies, and digital-service businesses.
A seller can:
  1. Create and verify a seller account.
  2. Connect an existing HTTPS service.
  3. Verify a payout destination without sharing a private key.
  4. Generate a project key for the local AgentPay MCP connector.
  5. Let a coding agent inspect the repository and propose integration changes.
  6. Define a product with a fixed price, API route, input schema, output schema,
    and fulfillment timeout.
  7. Validate and preview the exact buyer contract.
  8. Explicitly approve publication.
  9. Monitor payments, fulfillment, evidence, webhooks, and disputes.
An external buyer agent can:
  1. Discover a published product through structured endpoints, storefront
    manifests, llms.txt, or the public directory.
  2. Validate the required request schema and payment capability.
  3. Create an immutable purchase intent.
  4. Receive an x402 payment challenge.
  5. Authorize the exact seller-approved amount.
  6. Receive structured fulfillment after payment verification.
AgentPay does not hold seller private keys and does not take custody of buyer
funds. In a live payment mode, settlement goes to the seller's verified wallet.

Our starting constraints

We were a student team building with limited time and approximately USD 100 in
AWS credits. We had no customers and almost no expected traffic. That changed
our architectural priorities:
  • idle cost needed to remain close to zero;
  • every cloud resource had to be reproducible;
  • payment and identity failures had to fail closed;
  • the local environment had to work without AWS;
  • optional AI functionality could not become a launch dependency;
  • we could not justify always-on container or database infrastructure;
  • we needed a clear boundary between demo behavior and production claims.
These constraints led us toward a serverless architecture and a modular
monolith instead of early microservices.

The architecture

The deployed development flow is:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Seller browser
|
v
Next.js application on Vercel
|
| Same-origin backend-for-frontend proxy
v
Amazon API Gateway HTTP API
|
| AWS_PROXY integration
v
ARM64 Go runtime on AWS Lambda
|
+--> Amazon Cognito for seller identity
+--> Amazon DynamoDB for operational state
+--> DynamoDB Streams for publication events
+--> Amazon SQS for the publication failure DLQ
+--> AWS KMS for signing and envelope encryption
+--> AWS Secrets Manager for isolated secret material
+--> Amazon S3 for append-only evidence objects
+--> Amazon CloudWatch for logs, metrics, alarms, and dashboards
|
v
Seller-owned HTTPS API
The frontend runs on Vercel because it is a Next.js application. The payment,
authorization, persistence, evidence, and fulfillment control plane runs on
AWS. The browser never receives direct DynamoDB, KMS, S3, or Secrets Manager
access.
The public website uses a branded same-origin backend route. The generated API
Gateway hostname remains a private server-side upstream instead of appearing
in public product documents or browser requests.

Building the backend once for local and AWS execution

The backend is a Go modular monolith. We used:
  • AWS SDK for Go v2;
  • AWS Lambda for Go;
  • AWS Labs Lambda Go API Proxy;
  • Smithy Go through the AWS SDK;
  • explicit interfaces at external boundaries such as persistence, signing,
    secrets, payment verification, clocks, and seller forwarding.
The HTTP handlers are intentionally thin. They validate transport input,
invoke one use case, and translate typed domain errors into documented API
errors. Payment and publication rules remain in domain packages rather than
Lambda adapters.
The same application runs locally with in-memory repositories and in AWS with
DynamoDB, S3, KMS, and Secrets Manager adapters. This let us develop the
complete seller and buyer flow before spending time or credits on cloud
deployment.

Why DynamoDB became central to the design

Initially, DynamoDB looked like a place to store records. During implementation
it became the concurrency boundary for the entire system.
We use a single-table model for:
  • seller profiles and ownership;
  • products and publication versions;
  • immutable purchase intents;
  • transaction state;
  • idempotency records;
  • payment-identifier uniqueness claims;
  • integration credentials;
  • seller entitlements;
  • webhook subscriptions and deliveries;
  • append-only audit events;
  • usage-meter events;
  • public discovery projections.
Conditional writes and TransactWriteItems enforce rules such as:
  • one product slug per seller;
  • one claim for a payment identifier;
  • one fulfillment owner for a transaction;
  • no update to an immutable purchase intent;
  • exact idempotent replay returning the original result;
  • conflicting replay failing instead of silently changing behavior;
  • product and discovery projections changing atomically.
For normal request paths, production code does not scan the table. Keys and
indexes are designed around known access patterns.
One subtle lesson was that DynamoDB expressions must be assembled carefully.
During testing, a transaction failed with:
1
ValidationException: ExpressionAttributeValues must not be empty
The fix was not to weaken the transaction. We corrected the expression builder
so it omitted the attribute-value map when no values were required, and added
a regression test. That small failure reinforced an important principle:
database edge cases become payment edge cases when money is involved.

Authentication with Amazon Cognito

We use an Amazon Cognito user pool for seller accounts and an app client for
the web application.
The Next.js backend-for-frontend communicates with Cognito server-side and
stores the seller session in secure, HTTP-only, SameSite cookies. Cognito
tokens are not placed in local storage or exposed to client-side JavaScript.
API Gateway uses a Cognito-backed JWT authorizer for protected seller routes.
The Go application still performs seller ownership and lifecycle checks
because a valid identity token does not automatically prove access to a
specific seller resource.
The local environment implements a contract-equivalent development identity
adapter so we can test the same journeys without calling Cognito.
One onboarding challenge was understanding the difference between:
  • the AWS root account;
  • an IAM deployment user;
  • AWS CLI local-development sign-in;
  • a Cognito application user.
These are different identity systems with different responsibilities. Once we
separated them mentally, authentication debugging became significantly easier.

Signing and secret isolation with AWS KMS and Secrets Manager

We did not want application code or a model to hold raw signing keys.
AWS KMS is used for:
  • asymmetric evidence signing;
  • short-lived seller execution-capability signing;
  • application-envelope encryption.
The backend signs a capability only after payment and exactly-once forwarding
preconditions succeed. The capability is bound to the seller, route,
transaction, HTTP method, literal path, request-body hash, issue time, expiry,
and unique identifier.
The seller verifies the signed capability before executing fulfillment. This
keeps the seller API from trusting a plain header that a caller could forge.
AWS Secrets Manager stores the credential-pepper and confirmation-grant
secrets. Terraform creates the secret containers, but actual secret values are
injected separately. This prevents plaintext secret values from entering
source control or Terraform state.

Evidence storage with Amazon S3

Payment systems need more than mutable transaction rows. We wanted evidence
that could be independently verified and would be difficult to silently
rewrite.
Amazon S3 stores append-only evidence objects. The bucket is configured with:
  • Block Public Access;
  • bucket-owner-enforced ownership;
  • versioning;
  • encryption;
  • Object Lock;
  • deletion-protection requirements.
Evidence contains allowlisted metadata and hashes rather than unrestricted
seller responses or raw payment signatures. KMS signatures make the evidence
chain verifiable without exposing the signing key.

Keeping discovery synchronized

Publishing a product affects several buyer-facing representations:
  • the storefront page;
  • the seller manifest;
  • llms.txt;
  • public product discovery;
  • machine-readable schemas.
Updating these synchronously inside the seller's request would make
publication slower and more fragile. We implemented a durable publication
outbox in DynamoDB.
A DynamoDB Stream invokes the Lambda worker for new publication-outbox
records. The mapping uses bounded batching, partial-batch failure reporting,
record-age limits, retries, and batch bisection. Failures that survive the
retry policy are delivered to an encrypted Amazon SQS dead-letter queue.
Discovery is a read model, not payment authority. Even if a cached or
seller-hosted document is stale, intent creation checks the current seller,
entitlement, product version, availability, and payment destination.

Shipping the Go runtime with Lambda and API Gateway

The Go binary is compiled for ARM64 and runs as a provided.al2023 Lambda custom
runtime. API Gateway HTTP API uses payload format 2.0 and forwards requests to
the Lambda through AWS_PROXY integration.
API Gateway provides:
  • the HTTP entry point;
  • seller JWT authorization;
  • throttling;
  • CORS restrictions;
  • structured access logs;
  • detailed route metrics.
Lambda provides:
  • request-based compute;
  • reserved concurrency;
  • structured JSON logging;
  • DynamoDB, S3, KMS, and Secrets Manager integration;
  • one runtime for REST, MCP, and publication-stream events.
We initially used a 15-second Lambda timeout. CloudWatch logs showed that a
legacy invocation exhausted the deadline while seller forwarding was still in
progress. We changed the Lambda and API Gateway integration timeout to 29
seconds, bounded seller forwarding at 25 seconds, and reserved two seconds for
parent cancellation and response handling.
That incident taught us to treat timeout budgets as a hierarchy rather than a
single number.

The Lambda quota surprise

We expected the documented Lambda concurrency default, but our new AWS account
had an applied regional concurrency quota of only 10.
Our Terraform configuration intentionally reserves concurrency for the API and
keeps room for unreserved AWS operations. Deployment therefore failed its
precondition instead of creating an unsafe configuration.
We requested a quota increase through AWS Service Quotas and eventually
received an applied quota of 400. The API Lambda currently reserves five
concurrent executions, which is more than enough for a development environment
with no real customer traffic.
The frustrating part was seeing a large documented default while the applied
account quota was much smaller. The useful lesson was to validate the applied
quota during infrastructure planning instead of assuming the default.

Observability with CloudWatch

We use structured JSON logs with request identifiers and redaction. API Gateway
access logs include:
  • request ID;
  • route and path;
  • HTTP status;
  • integration latency;
  • response latency;
  • integration error;
  • response length.
CloudWatch helped us distinguish browser, API Gateway, Lambda, and downstream
seller failures that otherwise all appeared as a generic 504.
We deployed a seller-operations dashboard and thirteen alarms covering:
  • API server errors and latency;
  • Lambda errors, throttles, and duration;
  • MCP failures;
  • checkout failures;
  • facilitator failures;
  • evidence failures;
  • seller-forwarding failures;
  • webhook retries;
  • dead-letter conditions.
The remaining gap is notification delivery. The alarms exist, but Amazon SNS
alarm actions and end-to-end subscription verification are not configured yet.
We document this as incomplete rather than claiming that operators are already
being paged.

Cost controls

Cost mattered from the first day because we were working with limited credits
and no production traffic.
Our main decisions were:
  • Lambda instead of always-on compute;
  • ARM64 runtime;
  • reserved concurrency of five;
  • DynamoDB on-demand capacity;
  • bounded CloudWatch log retention;
  • one serverless Go application instead of multiple idle services;
  • Amazon SQS only for failure handling;
  • AWS-managed S3 encryption where an additional idle customer-managed key was
    not justified;
  • an AWS Budgets monthly development guard;
  • Bedrock disabled for the seller-first launch.
The architecture can scale, but it does not pay for theoretical scale before
traffic exists.

Infrastructure as code

Terraform is the source of truth for AWS resources. We separated:
  • state bootstrap;
  • foundation and data resources;
  • Cognito identity;
  • application runtime;
  • observability;
  • cost controls;
  • restricted operator access.
Remote state is encrypted and versioned in Amazon S3 with native state locking.
We keep development, demo, and future production configuration separate.
Before an apply, we run formatting, validation, and a reviewed plan. We also
re-run the plan afterward and expect no changes.
One deployment applied 37 resources with no changes or destroys. Later drift
audits found emergency console or CLI patches to Lambda and IAM. Instead of
leaving that drift undocumented, we imported the intended configuration back
into Terraform and ended with a no-change plan.
This was one of our strongest operational lessons: a successful emergency fix
is not finished until infrastructure as code can reproduce it.

Connecting Vercel and AWS without exposing the backend

The Next.js frontend is deployed on Vercel, while the backend runs on AWS.
We did not want the browser to depend directly on the generated API Gateway
hostname. Next.js provides a same-origin backend-for-frontend route that:
  • reads the private upstream from server-side environment configuration;
  • forwards only allowed methods and headers;
  • removes hop-by-hop headers;
  • preserves payment and request-correlation headers;
  • keeps Cognito and AWS configuration out of browser bundles.
Public discovery links use the branded domain. The raw API Gateway URL remains
a server-only implementation detail.

The end-to-end seller flow

The complete locally verified seller journey is:
  1. The seller signs up and verifies email.
  2. The seller creates a storefront and connects an HTTPS service.
  3. The seller verifies a payout destination.
  4. AgentPay checks entitlement and service readiness.
  5. The seller generates a reveal-once project key.
  6. The local MCP connector exchanges it for a short-lived capability.
  7. A coding agent inspects the repository and proposes the integration.
  8. The seller creates a product with schemas, price, route, and timeout.
  9. AgentPay runs publication checks.
  10. The seller previews and approves the exact buyer contract.
  11. The product becomes machine-discoverable.
  12. An external-agent simulation creates an immutable purchase intent.
  13. AgentPay returns an x402 payment challenge.
  14. The local test adapter verifies a deterministic test authorization.
  15. AgentPay claims fulfillment once and calls the seller.
  16. The seller dashboard shows the completed test transaction.
The browser does not show the seller a buyer checkout page. The seller
publishes products and receives transactions; the external buyer agent owns
the buying journey.

What we loved about AWS

DynamoDB matched payment safety surprisingly well

Conditional writes and transactions were a natural fit for idempotency,
payment uniqueness, immutable intents, and exactly-once forwarding. We could
express important race protections close to the data.

Lambda kept experimentation affordable

We could deploy a real Go backend without maintaining servers. At our current
traffic level, request-based compute and ARM64 are much more appropriate than
an always-on cluster.

KMS gave us a real signing boundary

Signing through KMS was better than loading a private key into environment
variables. It forced us to design explicit signing and verification contracts.

Cognito removed an entire category of unsafe custom code

We still had to design secure sessions and ownership checks, but we did not
have to invent password storage, email verification, token signing, or refresh
logic.

CloudWatch turned vague failures into measurable ones

The 504 timeout problem became solvable only after we had integration latency,
response latency, route, and Lambda duration in one investigation.

AWS services composed without forcing microservices

API Gateway, Lambda, DynamoDB, Streams, SQS, S3, KMS, Cognito, and CloudWatch
supported clear responsibilities while the application remained a maintainable
modular monolith.

What was difficult and what could improve

The main difficulty was the operational learning curve across services.
  • Lambda's applied concurrency quota was not obvious from the documented
    default.
  • IAM and KMS failures were safe but sometimes difficult to trace back to the
    exact missing action or condition.
  • Cognito application users, IAM users, root login, and AWS CLI authentication
    are easy for a new builder to confuse.
  • Terraform-created Secrets Manager containers plus separately injected secret
    versions are secure, but the workflow requires discipline.
  • API Gateway and Lambda timeout failures need carefully correlated logs.
  • CloudWatch alarm creation and Amazon SNS notification delivery are separate
    workflows, making it easy to believe monitoring is complete before a human
    can actually receive an alert.
We would value more guided cross-service diagnostics that explain the likely
root cause and show the relevant IAM, quota, integration, and downstream
settings together.

Why we did not activate Bedrock

The repository contains a Bedrock Runtime adapter and tests that treat model
output as untrusted input. Every route, price, limit, and payment decision must
still be revalidated by deterministic Go code.
However, Bedrock is disabled in the deployed seller-first V1.
The seller journey does not require a model. A seller can connect a service,
publish products, expose machine-readable discovery, and accept an external
agent purchase without AgentPay operating the buyer agent.
Activating Bedrock now would add:
  • regional model-access work;
  • token and tool-call budgets;
  • additional IAM permissions;
  • latency and cost monitoring;
  • evaluation against the deterministic baseline.
We chose not to add that cost and operational surface only to make the AWS
service list longer. Bedrock is a future buyer-orchestration feature, not a
seller-launch dependency.

What is deliberately not complete

As of September 20, 2026, the web application and AWS development backend are
deployed. The full production release gate is not complete.
The following features remain deferred:
  • deployed Base Sepolia buyer-to-seller payment proof;
  • mainnet settlement;
  • additional networks and stablecoins;
  • active Stripe subscription collection;
  • card checkout;
  • UPI;
  • automatic on-chain or provider refunds;
  • seller negotiation;
  • Agent-to-Agent execution;
  • global marketplace ranking;
  • official Shopify and WooCommerce adapters;
  • physical inventory, shipping, tax, and multi-item carts;
  • Amazon SNS alarm delivery;
  • external security and legal review.
The video demonstration uses the deterministic local test-payment adapter. The
deployed runtime is configured for exact x402 on Base Sepolia USDC, but we will
not claim deployed end-to-end settlement until the buyer and seller transaction
has been independently verified and recorded.

How the deferred features would be integrated

Bedrock buyer assistance

We would enable approved model access, add a narrowly scoped Lambda role,
configure token and tool-call limits, run offline evaluations, and compare
every result with the deterministic buyer. Bedrock could interpret buyer goals
or explain alternatives, but it would never authorize payment or change a
seller's price.

Stripe subscriptions

The entitlement lifecycle and event-reconciliation code already exist.
Activation requires Stripe products and prices, environment-specific webhook
secrets, raw-body signature verification, replay tests, cancellation tests,
secret rotation, and production canary monitoring.

Mainnet or additional payment rails

Each rail needs an explicit adapter with network and asset allowlists,
authorization verification, finality rules, replay protection, reconciliation,
refund semantics, and operational alarms. Changing only a token address would
not be sufficient.

UPI and cards

UPI and cards are not x402. They require a regulated provider integration,
provider webhooks, idempotent status reconciliation, buyer checkout UI,
refund handling, and separate settlement evidence.

Shopify and WooCommerce

The generic signed HTTPS adapter and merchant verification packages provide the
boundary. Official adapters would add OAuth, webhook verification, catalog
mapping, inventory synchronization, order-state mapping, sandbox fixtures, and
platform-specific installation flows.

What we learned

The payment is the smallest part of a payment product

The difficult problems were identity, immutable terms, concurrency,
fulfillment, recovery, and evidence.

AI should not decide money

A model can help understand a request, but seller-approved prices and
deterministic policy must remain authoritative.

Discovery and transaction authority must be separate

Public product documents help buyers find an offer. They must never authorize a
purchase. Every transaction must re-read current authoritative state.

Exactly-once is built from several smaller guarantees

Idempotency, unique payment identifiers, immutable intents, single-winner
claims, seller-side replay protection, and reconciliation all contribute.
There is no single exactly-once switch.

Cost controls are architecture

Reserved concurrency, on-demand DynamoDB, log retention, serverless compute,
budgets, and disabled optional services were design decisions, not later
optimizations.

A demo should be honest

We learned to label local test payments, avoid calling deferred functionality
complete, and separate a deployed development environment from a production
financial-service claim.

Closing

AgentPay began as an x402 payment experiment. Building it on AWS forced us to
think like operators: identity, permissions, concurrency, immutable state,
evidence, failure recovery, cost, and observability all became first-class
product requirements.
The project is not finished, and that is part of the lesson. We now have a
seller-first platform, a deployed AWS development backend, a real publication
workflow, machine-readable discovery, a safe local payment and fulfillment
demonstration, and a clear list of production gates.
The most valuable outcome was not the number of AWS services we used. It was
learning why each service belonged in the system, what failure it prevented,
and where we still needed to be honest about unfinished work.

Project links

  • Live application: https://agentpay.prathamranka.in/
  • Source code: https://github.com/PrathamRanka/fourGeez
  • Demo video: https://youtu.be/yupTRoTKlgo
# fintech# serverless# terraform# mcp# amazon-dynamodb
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article