AgentCore payments went GA on 18 August 2026 with a $0.005 fee AWS calls no charge
Summary. AWS made AgentCore payments generally available on 18 August 2026, letting agents pay for APIs and MCP endpoints on their own. The pricing page says the capability is "provided at no additional charge by AWS", then documents a $0.005 per-wallet-operation fee, and bills it against an API called CreateInstrument that does not exist in the service. The real API is CreatePaymentInstrument. Coinbase gives you 5,000 free wallet operations a month and charges $0.005 after that, with a transaction send counting as 2 operations, not 1. Three further costs appear nowhere on the pricing page: a mandatory AWS Marketplace subscription for Coinbase, on-chain gas fees paid from your own wallet balance, and the fact that the AWS Service Terms clause governing the whole thing is still titled "Preview" four days after GA. AgentCore payments is live in 12 Regions. Mumbai is not one of them.
What actually shipped on 18 August 2026
The What's New post is dated 18 August 2026 and describes "the general availability of AgentCore payments, a capability within Amazon Bedrock AgentCore that enables AI agents to autonomously discover, access, and pay for paid APIs, MCPs, and content with just a few lines of code."
Preview landed in May 2026 with support for the x402 protocol only. GA added the Machine Payment Protocol, an upto scheme inside x402 that lets an agent set a ceiling rather than a fixed price, Quick Create for Coinbase credential provisioning in the console, and a Coinbase Bazaar MCP server routed through AgentCore Gateway.
Two wallet providers are supported: Coinbase CDP and Stripe Privy. The developer guide is blunt about what a wallet is here: "The only supported instrument type is EMBEDDED_CRYPTO_WALLET." Payments settle in stablecoin. There is no card rail.
The guardrail is a payment session. Per the docs, "Each PaymentSession has a configurable budget limit (maxSpendAmount, currency) and an expiry time. When the session expires or the budget is reached, further payment requests are denied." The documented examples use maxSpendAmount of 100.00 USD and expiry windows of 60 and 120 minutes. No maximum for either value is published anywhere.
The pricing page bills an API that does not exist
This is the part to check before you model anything. The AgentCore pricing page states: "The developer would be charged only for two APIs: CreateInstrument, which generates a unique wallet address for the end user, and ProcessPayment, which signs the transaction to execute the payment."
CreateInstrument appears 19 times on that pricing page and zero times across the 21 payments pages of the developer guide. The IAM reference lists bedrock-agentcore:CreatePaymentInstrument. The API reference page for CreatePaymentInstrument returns HTTP 200; the page for CreateInstrument returns a 302. The pricing page is describing an API surface that was renamed before launch and never updated.
That matters beyond pedantry, because the same page carries the fee math you will use to forecast spend.
What a wallet operation really costs
AWS's own line is "AgentCore payments is provided at no additional charge by AWS. Wallet operations performed through the AgentCore Payments API are charged by the wallet provider (e.g., Coinbase CDP) per their published pricing at $0.005 per wallet operation."
Coinbase's pricing page confirms $0.005 and adds a free tier AWS does not mention: "The first 5,000 wallet operations per month are free." It also publishes an operation table AWS's per-invocation mapping does not survive.
| Item | AWS pricing page | Coinbase primary | Gap |
|---|---|---|---|
| Price per wallet operation | $0.005 | $0.005 | None |
| Free monthly allowance | Not mentioned | First 5,000 free | AWS omits it |
| Sign a message or payload | 1 operation | 1 operation | None |
| Send a transaction (sign + broadcast) | 1 per ProcessPayment | 2 operations | 2x on the send path |
| CreateInstrument on Stripe Privy | No charge | Not applicable | Provider-specific |
The gap is not theoretical. AWS states that for the upto scheme, "AgentCore payments submits an on-chain approve transaction before signing." An approve-then-sign flow cannot be a single wallet operation under Coinbase's own table. Model the upto path at two operations per payment, not one.
The pricing page's worked example has an arithmetic problem of its own: it prints "270,000 payments x $2.50 avg per request / 3 payments per request = $675,000". The stated formula evaluates to $225,000. The printed answer is the undivided product. The same error repeats in the larger example.
Three costs the announcement does not mention
A mandatory Marketplace subscription. The developer guide: "To use Coinbase as a payment provider with AgentCore payments, you must subscribe to the Coinbase Wallets for AgentCore Payments listing in AWS Marketplace... The subscription is mandatory. Until an active subscription exists in your AWS account, AgentCore payments rejects Coinbase connector creation and Coinbase wallet operations with a SubscriptionRequiredException error." Stripe Privy connectors do not require it.
On-chain gas. From the ProcessPayment page: "When you set this field, AgentCore payments submits an on-chain approve transaction before signing. This transaction incurs blockchain network (gas) fees paid from the wallet's native token balance." Gas is not mentioned once on the pricing page. Your agent will stop paying when the native token balance runs out, and nothing in the session budget model tracks that.
Unlimited allowance as a documented pattern. The same page tells you how to grant one: "To grant an unlimited allowance, pass the maximum uint256 value as a string: 115792089237316195423570985008687907853269984665640564039457584007913129639935." That is a supported input, not a warning.
No published quota, but limits are enforced
The AgentCore quotas page has no payments section at all. Its topic list runs from Runtime through Memory, Identity, Gateway, Browser, Code Interpreter, Evaluations and on to the Agent Registry, with no payments entry. The only payment-adjacent quotas sit under Identity: 50 resource payment credential providers per account per Region, 20 TPS on each credential-provider API, and 200 TPS on GetResourcePaymentToken. All adjustable.
Meanwhile the payments troubleshooting page documents the errors you get when you hit limits that are never published: "The service returns "{limitType} limit exceeded for account {accountId}" when you reach the maximum number of payment managers or connectors for your account." And the Service Terms reserve the right to add more: "AWS may impose limits on your use of AgentCore Payments, such as limits on transaction amounts, frequency, or volumes at any time."
There is no published numeric quota for ProcessPayment, CreatePaymentSession, CreatePaymentInstrument, payment managers, connectors or active sessions. You cannot capacity-plan a payment agent from the documentation AWS has published.
GA on one page, Preview on two others
Four days after the GA announcement, two live AWS pages still call it a preview. The Service Terms clause reads "50.15. Amazon Bedrock AgentCore Payments (Preview)". The pricing-page section carrying the $0.005 figure is headed "Payments (Preview)". Procurement teams that read Service Terms before signing off on a payment rail will find a preview clause governing a GA service.
That clause is also where the liability lands. Section 50.15.1: "AWS does not provide regulated financial services as part of AgentCore Payments. AWS is not a party to or in the flow of funds for any payment facilitated by your use of AgentCore Payments." Section 50.15.3 puts disputes on you: "You are solely responsible for any transactions, disputes, or payments liability arising from or related to your use of AgentCore Payments."
Where it runs, and where it does not
The regions table marks AgentCore payments available in 12 Regions: N. Virginia, Ohio, Oregon, Frankfurt, Ireland, London, Milan, Paris, Spain, Stockholm, Singapore and Sydney. It marks Mumbai, Tokyo, Seoul, Malaysia, Thailand, Canada Central, Sao Paulo and GovCloud US-West as unavailable.
The endpoints reference tells a different story. AgentCore publishes data-plane endpoints in nine Regions only: us-east-1, us-east-2, us-west-2, ap-southeast-1, ap-southeast-2, ap-south-1, ap-northeast-1, eu-west-1 and eu-central-1. ProcessPayment is a data-plane call on bedrock-agentcore.<region>.amazonaws.com. London, Milan, Paris, Spain and Stockholm are marked available with no published endpoint. Mumbai and Tokyo have endpoints but are marked unavailable.
For Indian teams the practical reading is that ap-south-1 has an AgentCore endpoint while the payments regions table says no. Do not plan a Mumbai-resident payment agent on the strength of that endpoint alone. Under India's DPDP Act 2023 the payer identity you attach to a session is personal data, and a cross-Region call to Singapore or Ireland is a design decision your privacy notice has to carry.
The security model the announcement summarises as "guardrails"
Three statements from the security best-practices page are worth reading before an agent touches real money.
"On an IAM-configured inbound authorization payment manager, your backend asserts the X-Amzn-Bedrock-AgentCore-Payments-User-Id header, and AgentCore payments does not verify it. You are responsible for setting this value correctly."
"The payTo address specifies the recipient wallet. AgentCore payments does not enforce payTo restrictions server-side, so your application must validate the address before calling the ProcessPayment API." The same page adds, in bold: "Never let the model generate payTo addresses."
"With the IAM-configured payment manager, AgentCore payments does not verify end-user identity."
The IAM model does carry one genuinely good control. The management policy "explicitly denies ProcessPayment to enforce separation of duties", and the docs warn: "Do not include PaymentSession write permissions (for example, CreatePaymentSession) and ProcessPayment in the same role, or the caller can bypass payment limits by creating new sessions with elevated budgets." That is the single most important line in the whole guide. A role that can create sessions and process payments has no budget at all.
Human approval is off by default. The framework integration page: "When auto_payment is False, the middleware surfaces 402 responses to the agent without processing them, allowing custom logic or human approval before payment." The shipped Strands and LangGraph examples pass plugins=[plugin], # enables automatic payments.
What to do this week
Subscribe to the Coinbase Marketplace listing before you write any code, or your first connector call fails with SubscriptionRequiredException. Split CreatePaymentSession and ProcessPayment into different roles today. Validate payTo against an allowlist in your own code. Fund the native token balance for gas and alarm on it separately from maxSpendAmount. Budget the upto path at two Coinbase wallet operations per payment, and subtract the 5,000 free monthly operations AWS does not mention. If your workload is Indian, confirm the ap-south-1 endpoint behaviour with AWS Support rather than the regions table, because the two AWS pages disagree.
The real cost here is not the $0.005. It is that the only page telling you what you will pay is the one page that is wrong about the API, the operation count, the free tier and the arithmetic.
FAQ
Does AWS charge anything for AgentCore payments?
AWS states the capability is provided at no additional charge and that you pay only the wallet provider. In practice you also pay a mandatory AWS Marketplace subscription for the Coinbase provider, and on-chain gas fees drawn from your wallet's native token balance. Neither appears on the AgentCore pricing page.
What does a wallet operation cost?
Coinbase publishes $0.005 per wallet operation, with the first 5,000 operations each month free. AWS quotes the same $0.005 but omits the free allowance. Coinbase counts a transaction send as two operations rather than one, so the x402 upto path costs more than AWS's one-invocation-equals-one-operation mapping suggests.
Which API does AgentCore payments actually use to create a wallet?
CreatePaymentInstrument. The AWS pricing page names CreateInstrument nineteen times, but that string appears nowhere in the developer guide and its API reference page returns a redirect rather than content. Build against bedrock-agentcore:CreatePaymentInstrument, which is the action listed in the IAM role documentation.
Is there a published quota for ProcessPayment?
No. The AgentCore quotas page has no payments section, and publishes only Identity-side credential-provider limits of 50 providers per account and 20 to 200 transactions per second. The troubleshooting page nonetheless documents limit-exceeded errors for payment managers and connectors, so limits exist without published values.
Is AgentCore payments available in Mumbai?
No, according to the AgentCore regions table, which marks payments unavailable in Asia Pacific (Mumbai). The AWS general reference contradicts it by listing a live bedrock-agentcore.ap-south-1.amazonaws.com data-plane endpoint, and ProcessPayment is a data-plane call. Because two AWS pages disagree, confirm the behaviour with AWS Support before designing an India-resident payment agent around ap-south-1.
Who is liable if an agent pays the wrong party?
You are. AWS Service Terms section 50.15.3 states you are solely responsible for any transactions, disputes, or payments liability arising from your use of AgentCore Payments. Section 50.15.1 states AWS is not a party to, or in the flow of funds for, any payment the service facilitates.
Does a payment session cap actually stop an agent overspending?
Only if the role model is right. The docs warn that a role holding both CreatePaymentSession and ProcessPayment can bypass payment limits by creating new sessions with elevated budgets. Separate those permissions across two roles, or the session budget is advisory rather than enforced.
Is human approval required before a payment?
No, human approval is opt-in rather than required. Setting auto_payment to False surfaces the HTTP 402 response to the agent, so custom logic or a person can approve the charge first. The Strands and LangGraph integration examples AWS ships enable automatic payments by default, meaning the shipped path pays without asking anyone.
How eCorpIT can help
Our senior engineering teams build and review agent platforms on Amazon Bedrock AgentCore, including the IAM separation-of-duties model that makes a payment session budget enforceable rather than advisory. We work through the same questions covered in our guides to Bedrock AgentCore production observability and AgentCore Runtime instance cost decisions, and we design against DPDP Act 2023 requirements for Indian deployments. eCorpIT is CMMI Level 5, MSME Certified and ISO 27001:2022 certified. Talk to us via /contact-us/.
References
- AgentCore payments is now generally available in Amazon Bedrock AgentCore, AWS What's New, 18 August 2026
- Amazon Bedrock AgentCore payments is now generally available, AWS Machine Learning Blog, 18 August 2026
- AgentCore payments overview, Amazon Bedrock AgentCore Developer Guide
- AgentCore payments concepts
- Process a payment, AgentCore payments
- AWS Marketplace subscription for Coinbase, AgentCore payments
- AgentCore payments IAM roles
- AgentCore payments security best practices
- AgentCore payments troubleshooting
- Amazon Bedrock AgentCore quotas
- AgentCore supported Regions
- Amazon Bedrock AgentCore endpoints and quotas, AWS General Reference
- Amazon Bedrock AgentCore pricing
- AWS Service Terms, section 50.15
- Coinbase Developer Platform wallets pricing
- Create a payment session, AgentCore payments
- AgentCore payments framework integrations
- Connect to the Coinbase Bazaar MCP server
Last updated: 22 August 2026.
Top comments (0)