Accept USDC and USDT Payments from AI Agents: Merchant Setup and Verification
To accept USDC and USDT payments from AI agents, establish which token deployments your merchant account accepts, give the agent precise payment terms, and connect verified payment evidence to your fulfillment system. The agent is software using an authorized payer wallet; it still needs the right asset, network, signing permissions, and gas.
Begin with one supported receiving pair rather than advertising every network that carries a familiar stablecoin symbol. Merchant configuration determines availability. A token balance on another chain, a successful wallet popup, or a transaction hash does not complete a sale.
The setup below uses GOAT Flow's documented merchant workflows to connect receiving configuration, wallet checks, purchase creation, and delivery. Its public crypto path uses DIRECT receiving. Specific networks, contracts, limits, and enabled integration surfaces must come from your merchant account and selected environment, not from examples.
Retrieve The Merchant's Active Receiving Terms
Start in the Merchant Portal for the environment you intend to use. Confirm that the merchant is approved and enabled, then inspect its configured crypto receiving options. The merchant receiving setup separates account access, receiving configuration, and service-fee balance. Opening an account does not establish that either USDC or USDT is available on a particular chain.
For a programmatic integration, use the deployment's merchant configuration lookup; for an agent-facing link, use its trusted merchant manifest for discovery. Check the origin and merchant identity before relying on the response. A public product website, a payment-page origin, and an authenticated merchant API base serve different purposes. Package versions do not choose your deployment; runtime configuration controls the options offered.
Build an acceptance record containing the information needed to create and reconcile a purchase:
Environment and merchant: the intended deployment, merchant identifier, and trusted service origins.
Asset identity: the chain identifier and exact token contract, with reviewed decimals for amount interpretation.
Receiving terms: the instructed recipient, amount in integer base units, applicable amount limits, and expiry where provided.
Purchase identity: your internal purchase reference and the returned order, session, or challenge identifiers for the chosen flow.
Payer binding: the expected authorized payer where the payment contract requires one.
These are information requirements for your integration, not a claim that one endpoint returns every field. Configuration discovery tells you what may be offered. A subsequent order, session, or challenge supplies the terms for a particular purchase. Persist that association before presenting a payable request; do not reconstruct it later from a buyer's screenshot or an arbitrary transaction.
Keep business and payment identifiers as separate fields. One purchase may need a replacement payment attempt after reconciliation, but it should not become a second product purchase merely because the platform assigned another order ID. Recording both levels lets the backend explain which attempt funded the sale and which attempts remain unresolved. Return only the payment information needed by the buyer; merchant API credentials stay on your server.
Your backend should select the price and permitted asset from trusted configuration. Compare the returned payment requirements with that saved intent. If the recipient, contract, chain, or amount conflicts, stop and resolve the mismatch. If precision is missing, obtain reviewed token metadata before computing an amount. A missing value is not permission to reuse a sample default.
DIRECT means the buyer transfers the specified token on the selected chain to the merchant's instructed receiving address. It does not establish a swap, bridge, automatic cross-chain route, or conversion into your preferred treasury asset. Any such service requires its own verified route and terms. Hosted Checkout is also a separate choice: it supplies a purchase interface, not evidence of asset conversion. Decide what you receive before deciding how the payment screen looks.
Validate The Token Deployment And Exact Amount
Treat the environment, chain, and contract together as the asset identity. A symbol such as USDC or USDT is a display label, not a globally unique payment destination. Two balances with the same ticker can belong to different contracts or networks and cannot be substituted merely because both represent a dollar-denominated token.
Check USDC against Circle's contract-address tables, distinguishing mainnet from testnet. Circle lists Ethereum and Base deployments separately and distinguishes native USDC from bridged USDC.e where applicable. Those distinctions explain how to identify an asset; they do not say that a GOAT Flow merchant accepts either deployment. Match the relevant issuer information with the actual receiving configuration rather than copying an issuer's network list into your checkout.
For USDT, consult Tether's supported protocols and integration guidelines. Ethereum USDt and Tron USDt use different network interfaces. A TRC-20 balance cannot satisfy an EVM DIRECT requirement by changing the network label in the payment request. Tether's page also distinguishes currently supported and deprecated protocols, so a historical entry is not sufficient evidence of current issuance or redemption support.
Where an asset is bridged rather than issued natively on the receiving chain, verify its provenance and the exact registered contract separately. Neither issuer support on the origin chain nor a successful bridge deposit identifies every destination representation. Do not describe a wrapped asset as issuer-native or promise a redemption path without evidence for that specific asset.
Next, resolve precision. ERC-20 defines transfers using integer amounts; symbol() and decimals() are optional metadata methods in the token standard. A missing decimals field therefore needs a reviewed metadata source or contract-specific resolution. If you cannot resolve it reliably, do not guess from the symbol.
For a hypothetical token whose precision has been verified as six decimals, a price of 12.50 tokens becomes 12500000 base units: 12.50 multiplied by ten to the sixth power. This is an arithmetic example, not a live receiving configuration or a rule that all USDT deployments have six decimals. With that precision, an amount requiring seven fractional digits cannot be represented exactly. Reject or reprice it explicitly rather than silently rounding the customer's obligation.
Keep amounts as validated decimal strings and integer base units throughout the payment path; avoid binary floating-point arithmetic for money. Compare the integer requirement with the verified payment, not just the rounded amount shown on screen.
A field called amountWei should not lead your integration to assume eighteen decimals. For token transfers, interpret its integer value using the selected token's verified precision. Keep the human-readable price alongside the saved integer amount so a reconciliation screen can show both, and validate that converting between them is exact before making the request payable.
Custom contract integrations also need token-specific transfer handling. Tether notes that Ethereum USDt's transfer behavior lacks the Boolean return expected by some ERC-20 wrappers. That is an interface compatibility concern, not a blanket reason to reject USDT or assume every wallet fails. Confirm the behavior of the actual integration that will submit or process the transfer.
Prepare An Authorized Wallet And The Right Gas Asset
Separate the merchant's prerequisites from the payer's. The merchant needs enabled receiving configuration and sufficient service credits where applicable. The payer needs the selected token on the requested chain, authority to sign, and that chain's native gas asset for a DIRECT transfer. Merchant fee credits are not customer funds and do not automatically cover the buyer's network transaction.
Check wallet compatibility at the interface level. A browser integration needs the provider expected by its client, such as an EIP-1193-compatible provider for the documented browser path. A headless agent needs a supported signer and network connection. In both cases, verify that the signer can submit the required transaction on the requested chain. A wallet's brand name or its appearance on a bridge compatibility list does not answer those questions.
A Tron-only signer cannot execute an EVM ERC-20 transfer. A multi-chain wallet may support both networks, but its selected account, provider, and funded balance still need to match this purchase. The same caution applies to hardware signing, smart accounts, delegated session keys, and paymasters: validate the chosen combination rather than treating support for one component as certification of the whole payment path.
Before authorizing a transfer, compare the request with the saved purchase terms: connected payer, chain, contract, recipient, amount, and expiry. Check token and native gas balances independently. The developer wallet example leaves payer, chain, and expiry checks to the calling application; invoking PaymentHelper does not establish all of them. An agent should reject a changed recipient or expired requirement instead of attempting to make it work automatically.
Treat this preflight as a fresh check at the point of signing. A previously connected wallet can change accounts or networks while a payment page remains open. When a check fails, identify the specific condition to correct and obtain valid requirements again where necessary; do not automatically switch the payer or substitute another token while retaining the original purchase authorization.
For transactions specifically on GOAT Network, native BTC is the gas asset; BTCB is not a substitute for it. That fact does not mean every network a merchant might accept uses BTC gas. A USDC or USDT balance also does not, by itself, fund native gas. Identify the actual payment chain before arranging funding, and do not import gas sponsorship from an unrelated facilitator implementation.
Receiving tokens at an existing merchant address does not mean the merchant must submit or fund the buyer's transfer. Later treasury movements are separate transactions with their own requirements. If either party needs to move funds between networks first, verify the current official route, destination asset, and gas requirements separately. A bridge example is neither a receiving option nor a wallet certification.
Keep the agent's signing authority bounded to its intended purchases. An owner-authorized DIRECT transfer differs from granting a spender an ERC-20 allowance; merchant onboarding approval is unrelated to either operation. Nothing here requires unlimited spending permission. Store signing secrets securely and keep them out of prompts, command-line arguments, and logs.
Connect The Sale Through A Link, Checkout Or API
Choose the purchase surface by who controls the offer and the delivery workflow. The stablecoin ticker does not determine whether you need a hosted link, application checkout, or paid API. Keep one integration contract intact rather than combining convenient fragments from different examples.
Merchant-managed links: QuickPay suits products or services configured in the portal. Use the portal-provided links and enable the documented PayKit/agent entry for machine-readable discovery. An individual product supplies a configured offer; an Any Amount link lets the buyer enter an amount within limits. These are different pricing arrangements. The QuickPay fulfillment guidance requires comparing the payment with the intended purchase; an Any Amount success does not establish that a particular invoice was paid in full. Your business still delivers the service.
Application checkout: Use this when your application owns the cart, price, customer context, and delivery. Create payment terms on the backend, then expose the returned payment entry point. A hosted page reduces UI work; a custom crypto integration owns the wallet interaction. DIRECT crypto Checkout Sessions additionally require quickpay_enabled, while ordinary createOrder() calls do not inherit that session-specific prerequisite. A session's creation also does not guarantee that its later payment order will pass every token, fee, and limit check.
Optional React components or checkout helpers do not change receiving configuration. Check that the selected package artifact and deployment support the UI you intend to use; a source example is not proof of a published package. Navigating to a returned hosted session URL does not require adopting a React component.
Paid API: Keep client authentication, request validation, price selection, and the result in your backend's purchase record. A custom order-based integration can issue payment requirements and later resolve that order. The GOAT-specific MPP route uses a challenge and signed receipt presented with the protected request. It requires operator-enabled deployment and merchant access, a registered route, configured terms, and a deployment-matched verifier; middleware alone does not enable the route.
Protocol terminology is not a compatibility guarantee. x402 describes an open payment handshake, not an exclusive GOAT capability or one universal asset list. CDP's facilitator documents EIP-3009 and Permit2 mechanisms with conditional sponsorship on supported configurations. Those are CDP-specific capabilities, not proof of GOAT DIRECT gas behavior or GOAT MPP receipt compatibility. Select the payment surface, client, verification contract, and environment together.
Authorize Delivery From The Correct Backend Evidence
Payment evidence becomes useful only when your server associates it with the purchase you intended to sell. Before requesting payment, persist the customer or authorized client, requested product or operation, price, payer binding where required, payment terms, and a stable internal purchase ID. Save the returned platform identifiers against that record. Do not let a later browser request replace the saved order ID with another one that happens to be paid.
Keep order status, session status, and your own delivery status separate. In the documented Checkout completion contract, an associated order reaches INVOICED, or its Checkout Session reports COMPLETED, before the merchant applies its purchase checks. A session handle is not an order ID. A QuickPay crypto session uses PAYMENT_CONFIRMED for successful payment; EXPIRED, FAILED, and CANCELLED are not success. Read that session and its purchase association rather than applying an order enum to a session field. The platform status contracts distinguish these objects.
The custom API Crypto DIRECT example has a narrower predicate: it explicitly accepts PAYMENT_CONFIRMED or INVOICED for its saved crypto order. That does not make PAYMENT_CONFIRMED a universal completion rule for Checkout or other rails. A polling helper can return failure states as well as success; receiving a response is not itself a successful payment. Use the documented completion rule for the integration you actually chose.
After checking that rule, reconcile the evidence with the saved merchant, product or request, asset, chain, amount, recipient, and payer conditions. Reject an unrelated paid order, a wrong amount, or a wrong token even if another part of the response looks successful. For a webhook integration, authenticate the exact raw request bytes with the configured endpoint secret before processing the event. A valid signature establishes event authenticity; your purchase association and completion checks still determine whether anything may be delivered.
Route both polling and webhook processing through the same durable fulfillment operation. For example, claim a purchase for fulfillment in persistent storage, generate or provision its result once, and save the result for subsequent authorized reads. Two workers observing payment must not create two entitlements. This is a merchant implementation responsibility, not a promise that a wallet helper supplies exactly-once business delivery. A process-local flag is insufficient when requests can reach multiple workers or survive restarts.
Plan the failure between claiming work and recording its result. For an external provisioning system, use a stable purchase reference and a recovery path that can determine whether provisioning already happened before repeating it. Otherwise, a crash can leave a paid purchase stuck or duplicate the side effect on restart. Reopening access to an already-saved result also needs customer authorization; knowing a paid order identifier is not permission to retrieve someone else's purchase.
The GOAT MPP path uses a different credential. Your resource server verifies the signed Payment-Receipt with the trusted key for that deployment, then checks merchant, route/request binding, expiry, access rights, and replay policy before returning the resource. A proof digest, a transaction hash, or a field named signature is not automatically that receipt. Obtain the verification key through the operator's trusted channel, not from the buyer. Multi-instance single-use enforcement needs shared atomic receipt-consumption storage; failing to reach that store must not silently permit access. The API payment and receipt contracts describe the two integration paths.
Distinguish platform evidence from network finality. A hash identifies a transaction to investigate; it does not prove successful execution. A payment receipt records verification under its deployment's policy; it is not an independent measurement of finality. GOAT's transaction lifecycle further distinguishes network inclusion, Bitcoin publication, and Bitcoin finality. None of those states is the same as your application delivering a report or unlocking access.
Choose the deployment's confirmation policy and your delivery risk policy deliberately. A signed receipt must not be described as proof that every GOAT payment has finalized on Bitcoin L1. Conversely, a lost delivery response does not undo a valid payment. Persist both payment and delivery evidence so each can be reconciled without pretending they share one clock.
Reconcile Uncertain Payments Before Retrying
Consider a hypothetical report purchase whose wallet broadcasts a transfer, but whose verification request times out. Preserve the original purchase, order or challenge ID, chain, contract, amount, payer, attempt time, and transaction hash. Keep the purchase pending reconciliation while checking the original transaction and backend record. Do not turn the timeout into a second transfer request.
Separate retrying a safe status read from repeating an action that can move money. A fresh browser session, a process restart, or a customer clicking again should load the saved purchase rather than silently create another payable order. Ordinary Server SDK order creation rejects a duplicate business order identifier; it is not a replay endpoint that returns the original order. Keep the returned platform ID when available and retain unresolved creation attempts for investigation.
The same principle applies to a session whose creation response was lost: do not change its reference merely to bypass a duplicate error. If the original identifier was not saved, reconcile using the merchant and attempt details rather than assume no order exists. A replacement needs an explicit decision about the first attempt's payability and any funds already transferred.
For MPP responses indicating pending inclusion or finality, honor Retry-After and retry verification of the original challenge and transaction. An expired challenge after broadcast is also a reconciliation problem, not proof that the customer owes another payment. If the payment succeeded but its receipt was consumed or the resource response was lost, recover the saved delivery result. Do not sell the same purchase again to repair delivery.
Wrong-chain, wrong-token, underpaid, or late transfers require investigation against the saved terms. Do not automatically release the product because some value arrived, and do not promise automatic recovery of every mistaken transfer. Preserve the evidence, determine what actually moved, and apply the relevant operational policy. For invoice-style sales, explicitly resolve any amount shortfall before treating the obligation as satisfied.
Cancellation and expiry change payment workflow state; they do not reverse crypto already transferred. A return is a separate authorized transaction. Verify its destination, chain, token, amount, and applicable policy, and record it against the purchase. Merchant service-fee credits remain separate bookkeeping, not a pool of customer funds to refund.
Before enabling real purchases, verify your actual receiving terms and limits, applicable service fees and refund terms, merchant eligibility, signer behavior, completion checks, and durable delivery/replay storage. Exercise timeout, expiry, incorrect payment, and concurrent notification cases in the relevant environment. The useful result is one recoverable purchase record from quoted terms through delivery, with unresolved money movement investigated before anyone is asked to pay again.
