"usdc" Payment Method for HTTP Payment Authentication

1.1. Scope of This Version

Normatively specified:¶

• EVM direct USDC charges, by reference to [I-D.evm-charge].¶

• Solana direct USDC charges, by reference to [I-D.solana-charge].¶

• Stacks direct USDCx charges using SIP-010 transfers.¶

• Gateway Transfer charges through Circle Gateway that settle on the merchant's selected destination network before a successful receipt is returned.¶

• USDC-specific asset identity, token-control, replay, and receipt requirements.¶

1.2. Relationship to Other Methods

This document does not replace the EVM or Solana charge methods. It profiles them for USDC.¶

For EVM, the request and credential envelope inherits from [I-D.evm-charge]. The usdc profile restricts the token to native USDC, restricts the v00 credential payload to EIP-3009 authorization, and adds USDC-specific asset identity and control checks. Deployments that want Permit2, raw transaction, or hash-based EVM settlement SHOULD advertise method="evm" directly.¶

For Solana, the request and credential semantics inherit from [I-D.solana-charge]. The usdc profile restricts the token to the native USDC SPL mint published by Circle and the legacy SPL Token program in v00.¶

For Stacks, this document defines USDCx on Stacks directly because it is not covered by a generic MPP chain method today.¶

For Gateway Transfer, this document defines a Circle Gateway-specific cross-chain charge profile. The merchant sets the destination network where it wants to receive USDC. The payer chooses one of the advertised source networks, signs a Gateway authorization, and the server submits that authorization to Circle Gateway. A successful charge receipt means Gateway has completed settlement on the merchant's destination network.¶

6.1. Shared Request Fields

For EVM, currency follows [I-D.evm-charge] and is the native USDC token contract address published by Circle [CIRCLE-USDC-ADDRESSES].¶

For Solana, currency follows [I-D.solana-charge] and is the native USDC mint address published by Circle [CIRCLE-USDC-ADDRESSES].¶

For Stacks, currency MUST be the full USDCx SIP-010 [SIP-010] asset identifier, <contractAddress>.<contractName>::<assetName>. methodDetails.stacks carries the same identity as parsed fields for transaction verification.¶

For Gateway Transfer, currency MUST be the case-sensitive literal usdc. This is a method-defined asset identifier, not an ISO currency code. The concrete source and destination token identities are resolved through Circle Gateway discovery and estimate APIs or a conforming SDK.¶

6.2. Method Details

methodDetails.type selects the active usdc profile. Its value MUST be one of evm, solana, stacks, or gateway.¶

The methodDetails object MUST include exactly one profile details object, and that object MUST use the same name as methodDetails.type. For example, when methodDetails.type = "solana", methodDetails.solana MUST be present and methodDetails.evm, methodDetails.stacks, and methodDetails.gateway MUST be absent.¶

This methodDetails.type discriminator with a nested per-profile object is intentionally not the flat methodDetails shape used by [I-D.evm-charge] and [I-D.solana-charge]. A parser written for the base specs' flat methodDetails will not work here; implementations MUST select the active profile object by methodDetails.type.¶

Identifier formats otherwise follow each profile's base specification. The direct EVM and Solana profiles use the payer and recipient identifier formats defined by [I-D.evm-charge] and [I-D.solana-charge]. CAIP-2 [CAIP-2] network identifiers and CAIP-10 [CAIP-10] account identifiers are used normatively in the Gateway Transfer profile, where one charge can route across chain families and a chain-native identifier alone would be ambiguous, and in the Stacks profile, which has no base MPP chain method to inherit from. The receipt network field is a single, deliberate cross-profile identifier described in Section 10.¶

6.3. EVM Profile

The EVM profile inherits [I-D.evm-charge]. The following restrictions apply:¶

Servers MUST verify that request.currency is the native USDC token contract published by Circle for methodDetails.evm.chainId. EVM credentials for this profile MUST use payload.type="authorization". The authorization nonce MUST bind the selected challenge so a signed authorization cannot be replayed across payment challenges or intents. Servers MUST verify the EIP-3009 signature against the token contract's actual EIP-712 domain. For v00, the token domain MUST match native USDC for the selected chain and contract, including chainId = methodDetails.evm.chainId and verifyingContract = request.currency. Implementations MAY discover the domain through eip712Domain() where available, DOMAIN_SEPARATOR, or a trusted native-USDC registry. Deployments that require an alternate EIP-712 domain shape, including salt-based domains, are out of scope for this profile. Because the client signs an offchain EIP-3009 authorization, the server submits the transaction and pays EVM gas.¶

6.4. Solana Profile

The Solana profile inherits [I-D.solana-charge]. The following restrictions apply:¶

v00 profiles native USDC on the legacy SPL Token program only. Servers MUST reject credentials whose tokenProgram is not:¶

text TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA ¶

The Token-2022 program is out of scope in v00. The field remains in the schema so a later revision can admit Token-2022 USDC without changing the wire shape.¶

Servers SHOULD verify that tokenProgram equals the owner program of the mint account returned by Solana RPC. A mismatch MUST cause credential rejection.¶

Solana credentials for this profile MUST use payload.type="transaction" and inherit base Solana pull-mode verification from [I-D.solana-charge]. The credential echoes the challenge, and the server binds settlement to it through challenge consumption and transaction-signature replay protection as defined by [I-D.solana-charge].¶

Deployments that need third-party verifier or facilitator proof MAY define a stricter challenge-bound authorization profile in a later version.¶

6.5. Stacks Profile

Stacks uses SIP-005 [SIP-005] consensus-serialized transactions.¶

Unlike EVM and Solana, Stacks has no base MPP chain method to inherit from, so this document defines server-broadcast transaction verification directly. The server verifies the SIP-010 transfer, its post-condition, and the origin signature, then binds settlement to the challenge through challenge consumption and transaction-id replay protection.¶

The USDCx on Stacks mainnet token identity at publication time is:¶

text SP120SBRBQJ00MCWS7TM5R8WJNTTKD5K0HFRC2CNE.usdcx::usdcx-token ¶

The USDCx on Stacks testnet token identity used by the examples is:¶

text ST1PQHQKV0RJXZFY1DGX8MNSNYVE3VGZJSRTPGZGM.usdcx::usdcx-token ¶

Servers MUST verify the advertised token tuple against the Circle xReserve registry or an explicit implementation allowlist. Until a public registry is available, a v00 allowlist entry MUST include network, chainId, contractAddress, contractName, assetName, decimals, and the xReserve control surface used for issuance and redemption checks. A token identifier that appears only in a partner-published registry MUST NOT be accepted if it contradicts the Circle xReserve registry or allowlist. The parsed methodDetails.stacks tuple MUST match request.currency.¶

6.6. Gateway Transfer Profile

The Gateway Transfer profile uses Circle Gateway to move native USDC from a payer-selected Gateway source network to the merchant's chosen destination network. The merchant receives USDC on destinationNetwork, so the payer's source-network choice is constrained by acceptedSources rather than by the merchant's settlement network.¶

Gateway network fields use CAIP-2 [CAIP-2] identifiers. Gateway account identifiers use CAIP-10 [CAIP-10] account IDs in the form <CAIP-2 network>:<account address>.¶

Circle Gateway maps source and destination networks to Gateway domains, token identifiers, wallet contracts, minter contracts, recipient setup options, and signing bytes. Those details are resolved by Circle Gateway APIs or a conforming SDK. They are not carried in methodDetails.¶

v00 allows any Circle Gateway-supported source and destination pair, including EVM to Solana, Solana to EVM, and same-family transfers. Servers MUST reject credentials for a route that Circle Gateway does not support at authorization time.¶

For v00, a Gateway Transfer credential selects one source network from acceptedSources. acceptedSources is the merchant's accepted set; payload.sourceNetwork is the payer's selected source for this charge.¶

For Solana destinations, request.recipient identifies the merchant's Solana owner address. The signed Gateway authorization settles to a USDC token account for that owner. Associated token account creation and recipient setup options are Gateway authorization fields, not PaymentAuth methodDetails.¶

maxFee is separate from amount. It is a cap, not the fee paid. The payer pays Gateway Transfer fees from the source depositor's Gateway balance, in addition to the merchant amount. The server MUST reject a Gateway authorization whose fee cap exceeds methodDetails.gateway.maxFee.¶

If maxFeeBps is present, the signed Gateway authorization fee cap MUST also satisfy the ratio cap: authorizationFeeCap * 10000 <= request.amount * maxFeeBps. When both caps are present, the signed fee cap MUST satisfy both.¶

The Gateway TransferSpec value MUST equal request.amount. Circle Gateway validates that the source depositor has enough Gateway balance to cover the TransferSpec value plus the fee charged for the accepted transfer. Clients SHOULD present amount + maxFee as the payer's worst-case spend.¶

Servers verify the Gateway authorization against the PaymentAuth request before submission.¶

This draft relies on Circle Gateway for route discovery [CIRCLE-GATEWAY-INFO], fee estimation [CIRCLE-GATEWAY-ESTIMATE], signing material and submission [CIRCLE-GATEWAY-TRANSFER], transfer status [CIRCLE-GATEWAY-TRANSFER-STATUS], and TransferSpec lookup [CIRCLE-GATEWAY-TRANSFER-SPEC]. It does not copy Gateway attestation bytes, contract ABI details, or SDK routing tables into the PaymentAuth request. Circle Gateway validates Gateway encoding, signatures, Gateway replay, route support, fee calculation, and transfer validity.¶

7.1. Gateway Transfer Credential

For Gateway Transfer, the credential object contains:¶

The Gateway Transfer payload.type MUST be transfer. This value is scoped to methodDetails.type="gateway". The payload carries the selected source for this charge. It does not repeat the full acceptedSources list from the request.¶

The Gateway authorization package represents one Gateway transfer for the selected source network. Its internal encoding is Circle Gateway versioned data, not a PaymentAuth extension point. When this document names Gateway fields such as source depositor, source signer, TransferSpec value, fee cap, destination recipient, recipient setup options, or salt, it refers to their Gateway semantics. The wire object MAY carry those values under versioned Gateway field names. The authorization object MUST expose the signed fields required by Section 8 to the verifier.¶

The surrounding PaymentAuth credential binds that Gateway package to credential.challenge.id and credential.challenge.realm by requiring the signed TransferSpec salt to equal the challenge-bound salt defined in Section 6.6.1. sourceSigner is the account that signs the Gateway authorization. It can be the same account as sourceDepositor, or an account Circle Gateway accepts as an authorized delegate for that depositor. If sourceSigner is a contract account, Circle Gateway also applies its contract-signature validation rules.¶

9.1. Gateway Transfer Non-Success Outcomes

If Circle Gateway reports failed or expired before destination settlement, the server MUST return a new 402 challenge. The client MUST treat the original Gateway authorization as no longer reusable and sign a new credential if it wants to retry the payment.¶

If a Gateway transfer remains pending past the server's payment deadline, the server SHOULD return 402 with Retry-After [RFC9110] and a status reference. The client SHOULD NOT sign a replacement authorization for the same resource until the original transfer reaches a terminal status or the server reports that it is safe to retry.¶

If the server loses transport state while submitting a Gateway authorization, it MUST reconcile with Circle Gateway using any available transfer or TransferSpec reference before requesting a replacement authorization. This profile does not define repeated submission of the same signed Gateway authorization as an idempotent client retry.¶

The server MUST NOT return a successful receipt before the selected profile's settlement has completed. If the server wants admission before onchain settlement, it MUST use a separate deferred-settlement method or intent outside this document.¶

11.1. Supported USDC Asset Forms

This profile defines which USDC asset forms can satisfy method="usdc" in v00. Servers MUST verify that the selected token matches a native USDC deployment published by Circle, or, for Stacks, a USDCx token listed in the Circle xReserve registry or an explicit implementation allowlist. Other bridged, wrapped, or synthetic USDC-like assets need a separate profile or explicit method details.¶

Gateway Wallet deposits remain subject to Circle Gateway recovery and withdrawal rules. Gateway supports delayed trustless withdrawal from Gateway Wallet when the service is unavailable. That recovery path is outside PaymentAuth settlement and does not make a pending Gateway Transfer idempotently retryable.¶

11.2. Blocklist and Pause Controls

Native USDC and USDCx on Stacks have different control surfaces. Native USDC has token-level pause and blocklist controls on the selected chain. For USDCx on Stacks, xReserve [CIRCLE-XRESERVE] source-chain controls gate deposits and withdrawals, but those controls do not freeze same-chain partner token transfers by themselves. Same-chain USDCx transfers depend on the partner-chain token controls.¶

Servers MUST apply every control surface that is relevant to the selected profile before accepting a credential. For native USDC, a payer or recipient present in the applicable token blocklist MUST cause rejection. For USDCx on Stacks, servers MUST check the Circle xReserve control surface and the partner-chain token control surface required by local policy. Cached control data MUST have an explicit freshness bound.¶

11.3. Replay Protection

Servers MUST bind each credential to the selected challenge and MUST maintain replay protection for consumed credentials. Challenge consumption and receipt issuance MUST be atomic: concurrent requests presenting the same valid credential MUST produce at most one successful receipt.¶

For EVM authorization credentials, the persistent replay key MUST include (chainId, verifyingContract, payload.from, payload.nonce). The nonce already commits to method, intent, challenge.id, challenge.realm, and requestHash, so this key protects both onchain replay and cross-context replay.¶

For Solana transaction credentials, replay protection follows [I-D.solana-charge]. Servers MUST maintain consumed transaction signatures and atomically consume the selected challenge before returning a successful receipt. Servers that admit pull-mode transactions before broadcast SHOULD also deduplicate on (network, transactionBytesDigest) to avoid concurrent admission of the same serialized transaction.¶

For Stacks transaction credentials, the replay key MUST include the transaction id after broadcast and (stacks:CHAIN_ID, ORIGIN_PRINCIPAL, ORIGIN_NONCE). Servers that admit transactions before broadcast SHOULD also deduplicate on (stacks:CHAIN_ID, transactionBytesDigest) to avoid concurrent admission of the same serialized transaction.¶

For Gateway Transfer credentials, replay protection MUST cover the selected challenge and the challenge-bound Gateway salt before the server submits the authorization to Circle Gateway. A server that only keys replay protection by source transaction or destination transaction can submit the same signed Gateway authorization more than once before final settlement. Circle Gateway separately enforces Gateway-side replay when it accepts the transfer. The TransferSpec salt binds the Gateway authorization to the PaymentAuth challenge, request, source, destination, recipient, amount, and fee cap, as specified in Section 6.6.1.¶

If a deployment advertises the same merchant order through both method="usdc" and a chain-specific method such as evm or solana, it MUST enforce one logical purchase across those offers. The deduplication key MUST be a stable merchant order key, normally request.externalId when present. If externalId is absent, the deployment MUST maintain an explicit equivalent-offer group outside the credential. This is merchant order deduplication, not a replacement for challenge replay protection. A successful receipt for one offer MUST atomically consume the shared key so that a later credential for the same order is rejected.¶

11.4. Gateway Transfer Fees

Gateway Transfer can charge fees in addition to the merchant amount. The request binds a maximum fee in methodDetails.gateway.maxFee. Servers MUST reject Gateway authorization material that exceeds that fee cap. If methodDetails.gateway.maxFeeBps is present, servers MUST also reject authorization material whose fee cap exceeds that ratio. Clients SHOULD present the payer's worst-case spend as amount + maxFee.¶

Gateway Transfer fees are payer-paid in v00. The merchant server does not sponsor those Gateway fees, even if it waits for destination settlement before returning a successful charge receipt.¶

11.5. Sensitive Fields

USDC credentials are bearer-equivalent between signing and settlement. Servers SHOULD avoid logging raw authorization signatures, serialized transactions, Gateway authorization packages, or full credential headers.¶

13.1. A.1 EVM Direct Charge

The decoded request is:¶

json { "amount": "1000000", "currency": "0x3600000000000000000000000000000000000000", "recipient": "0xc04193C50cD2E6a1C79593e46364496Fe5fcd9b6", "description": "Arc Testnet USDC charge", "externalId": "invoice-evm-001", "methodDetails": { "type": "evm", "evm": { "chainId": 5042002, "decimals": 6, "credentialTypes": [ "authorization" ] } } } ¶

The server advertises the challenge:¶

http HTTP/1.1 402 Payment Required WWW-Authenticate: Payment realm="api.example.com", method="usdc", intent="charge", id="usdc_evm_direct_001", request="eyJhbW91bnQiOiIxMDAwMDAwIiwiY3VycmVuY3kiOiIweDM2MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAiLCJkZXNjcmlwdGlvbiI6IkFyYyBUZXN0bmV0IFVTREMgY2hhcmdlIiwiZXh0ZXJuYWxJZCI6Imludm9pY2UtZXZtLTAwMSIsIm1ldGhvZERldGFpbHMiOnsiZXZtIjp7ImNoYWluSWQiOjUwNDIwMDIsImNyZWRlbnRpYWxUeXBlcyI6WyJhdXRob3JpemF0aW9uIl0sImRlY2ltYWxzIjo2fSwidHlwZSI6ImV2bSJ9LCJyZWNpcGllbnQiOiIweGMwNDE5M0M1MGNEMkU2YTFDNzk1OTNlNDYzNjQ0OTZGZTVmY2Q5YjYifQ", expires="2026-04-01T12:05:00Z" ¶

The client returns an EIP-3009 authorization credential:¶

json { "challenge": { "id": "usdc_evm_direct_001", "realm": "api.example.com", "method": "usdc", "intent": "charge", "request": "eyJhbW91bnQiOiIxMDAwMDAwIiwiY3VycmVuY3kiOiIweDM2MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAiLCJkZXNjcmlwdGlvbiI6IkFyYyBUZXN0bmV0IFVTREMgY2hhcmdlIiwiZXh0ZXJuYWxJZCI6Imludm9pY2UtZXZtLTAwMSIsIm1ldGhvZERldGFpbHMiOnsiZXZtIjp7ImNoYWluSWQiOjUwNDIwMDIsImNyZWRlbnRpYWxUeXBlcyI6WyJhdXRob3JpemF0aW9uIl0sImRlY2ltYWxzIjo2fSwidHlwZSI6ImV2bSJ9LCJyZWNpcGllbnQiOiIweGMwNDE5M0M1MGNEMkU2YTFDNzk1OTNlNDYzNjQ0OTZGZTVmY2Q5YjYifQ", "expires": "2026-04-01T12:05:00Z" }, "source": "did:pkh:eip155:5042002:0xf39fd6e51aad88f6f4ce6ab8827279cfffb92266", "payload": { "type": "authorization", "from": "0xf39fd6e51aad88f6f4ce6ab8827279cfffb92266", "to": "0xc04193c50cd2e6a1c79593e46364496fe5fcd9b6", "value": "1000000", "validAfter": "0", "validBefore": "1775045100", "nonce": "0x03e1d1aa38e2c56a0bb12e2d4562082c1c26496553f838064f3e6b4c3db9d2c2", "signature": "0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee" } } ¶

The server submits the authorization, pays EVM gas, waits for the EVM receipt, and returns:¶

http HTTP/1.1 200 OK Payment-Receipt: BASE64URL_JCS_RECEIPT ¶

The decoded receipt payload is:¶

json { "method": "usdc", "type": "evm", "challengeId": "usdc_evm_direct_001", "reference": "0x3c5b4a1f00000000000000000000000000000000000000000000000000008d0a2c4e6b", "status": "success", "timestamp": "2026-04-01T12:00:04Z", "network": "eip155:5042002", "externalId": "invoice-evm-001" } ¶

14.1. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8785]

Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, <https://www.rfc-editor.org/info/rfc8785>.

[RFC9110]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/info/rfc9110>.

[I-D.httpauth-payment]

Moxey, J., "The 'Payment' HTTP Authentication Scheme", January 2026, <https://datatracker.ietf.org/doc/draft-ietf-httpauth-payment/>.

[I-D.payment-intent-charge]

Moxey, J., Ryan, B., and T. Meagher, "'charge' Intent for HTTP Payment Authentication", 2026, <https://datatracker.ietf.org/doc/draft-payment-intent-charge/>.

[I-D.evm-charge]

"EVM Charge Intent for HTTP Payment Authentication", n.d., <https://paymentauth.org/draft-evm-charge-00.html>.

[I-D.solana-charge]

"Solana Charge Intent for HTTP Payment Authentication", n.d., <https://paymentauth.org/draft-solana-charge-00.html>.

[CAIP-2]

"Chain Agnostic Improvement Proposal 2", n.d., <https://chainagnostic.org/CAIPs/caip-2>.

[CAIP-10]

"Chain Agnostic Improvement Proposal 10", n.d., <https://chainagnostic.org/CAIPs/caip-10>.

[SIP-005]

"Stacks Blocks, Transactions, and Accounts", n.d., <https://raw.githubusercontent.com/stacksgov/sips/main/sips/sip-005/sip-005-blocks-and-transactions.md>.

[SIP-010]

"Stacks Fungible Token Standard", n.d., <https://raw.githubusercontent.com/stacksgov/sips/main/sips/sip-010/sip-010-fungible-token-standard.md>.

[CIRCLE-GATEWAY-INFO]

"Circle Gateway GET /v1/info", n.d., <https://developers.circle.com/api-reference/gateway/all/get-gateway-info>.

[CIRCLE-GATEWAY-ESTIMATE]

"Circle Gateway POST /v1/estimate", n.d., <https://developers.circle.com/api-reference/gateway/all/estimate-transfer>.

[CIRCLE-GATEWAY-TRANSFER]

"Circle Gateway POST /v1/transfer", n.d., <https://developers.circle.com/api-reference/gateway/all/create-transfer-attestation>.

[CIRCLE-GATEWAY-TRANSFER-STATUS]

"Circle Gateway GET /v1/transfer/{id}", n.d., <https://developers.circle.com/api-reference/gateway/all/get-transfer-by-id>.

[CIRCLE-GATEWAY-TRANSFER-SPEC]

"Circle Gateway GET /v1/transferSpec/{transferSpecHash}", n.d., <https://developers.circle.com/api-reference/gateway/all/get-transfer-spec>.

14.2. Informative References

[CIRCLE-GATEWAY-FORWARDING]

"Circle Gateway Forwarding Service guide", n.d., <https://developers.circle.com/gateway/howtos/forwarding-service>.

[CIRCLE-USDC-ADDRESSES]

"Circle USDC Contract Addresses", n.d., <https://developers.circle.com/stablecoins/usdc-contract-addresses>.

[CIRCLE-XRESERVE]

"Circle xReserve architecture", n.d., <https://developers.circle.com/xreserve>.