NEAR Intents Charge Intent for HTTP Payment Authentication

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 1 January 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶

This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC or to translate it into languages other than English.¶

Table of Contents

1. Introduction

HTTP Payment Authentication [I-D.httpauth-payment] defines a challenge-response mechanism that gates access to resources behind payments. This document registers the "charge" intent for the "nearintents" payment method.¶

NEAR Intents is an intent-based settlement system in which a network of competing solvers fulfills user-expressed swap intents. The 1Click Swap API [ONECLICK-API] is a hosted interface to this system: a caller requests a quote for converting a source asset into a destination asset, receives a unique deposit address on the origin chain, sends the source asset to that address, and the solver network delivers the destination asset to a specified recipient — potentially on a different chain. A list of supported origin and destination chains is maintained at [NEAR-INTENTS-CHAINS].¶

This document specifies how to use that settlement system to fulfill the "charge" intent: a one-time payment of a specified amount, as defined in [I-D.payment-intent-charge]. The server may settle the payment any time before the challenge expires auth-param timestamp.¶

This specification inherits the shared request semantics of the "charge" intent from [I-D.payment-intent-charge]. It defines only the NEAR Intents-specific methodDetails, payload, verification, and settlement procedures for the "nearintents" payment method.¶

Client                  Server            Origin Chain      1Click / Solvers
  |                        |                    |                  |
  | (1) GET /resource      |                    |                  |
  |----------------------->|                    |                  |
  |                        | (2) quote          |                  |
  |                        |-------------------------------------->|
  |                        |   depositAddress, maxAmountIn, ...     |
  |                        |<--------------------------------------|
  | (3) 402 Payment Req    |                    |                  |
  |     intent="charge"    |                    |                  |
  |     recipient=deposit  |                    |                  |
  |<-----------------------|                    |                  |
  |                        |                    |                  |
  | (4) Send deposit tx    |                    |                  |
  |------------------------------------------->|                  |
  | (5) Confirmation       |                    |                  |
  |<-------------------------------------------|                  |
  |                        |                    |                  |
  | (6) Authorization:     |                    |                  |
  |     Payment (txHash)   |                    |                  |
  |----------------------->|                    |                  |
  |                        | (7) Verify deposit on origin chain    |
  |                        |--------------------|                  |
  |                        | (8) Submit + await swap finality      |
  |                        |-------------------------------------->|
  |                        |   status: SUCCESS (merchant paid)     |
  |                        |<--------------------------------------|
  | (9) 200 OK + Receipt   |                    |                  |
  |<-----------------------|                    |                  |

2. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Terminology

1Click Swap API

A hosted interface to the NEAR Intents settlement system [ONECLICK-API]. Exposes quote generation, deposit notification, and status endpoints used by this method.¶

Deposit Address

A unique address generated by the 1Click backend for a single quote. The client sends the source asset to this address. Each address corresponds to exactly one quote and is single-use.¶

Solver Network

The set of competing agents that fulfill NEAR Intents swap intents by sourcing the destination asset and delivering it to the recipient.¶

EXACT_OUTPUT

A 1Click quote mode in which the destination output amount is fixed and the maximum source input amount required to guarantee it is computed by the quote. This method uses EXACT_OUTPUT so the merchant receives a deterministic amount.¶

Origin Chain

The chain on which the client holds the source asset and broadcasts the deposit transaction. Identified by a CAIP-2 [CAIP-2] network identifier.¶

Destination Chain

The chain on which the merchant receives the destination asset. Identified by a CAIP-2 [CAIP-2] network identifier.¶

Settlement Finality

For this method, the point at which the merchant has received the destination asset, signalled by the 1Click terminal status SUCCESS. See Section 10.¶

Base Units

The smallest transferable unit of an asset, determined by its decimal precision (e.g., USDC with 6 decimals uses 1,000,000 base units per 1 USDC).¶

4. Request Schema

The request parameter in the WWW-Authenticate challenge contains a base64url-encoded [RFC4648] JSON [RFC8259] object. The JSON MUST be serialized using JSON Canonicalization Scheme (JCS) [RFC8785] before base64url encoding, per [I-D.httpauth-payment].¶

This specification implements the shared request fields defined in [I-D.payment-intent-charge].¶

{
  "amount": "1005000",
  "currency": "eip155:42161/erc20:0xaf88d065e77c8cC2239327C5EDb3A432268e5831",
  "recipient": "0x76b4c56085ED136a8744D52bE956396624a730E8",
  "description": "Cross-chain premium data access",
  "externalId": "order_12345",
  "methodDetails": {
    "originNetwork": "eip155:42161",
    "destinationNetwork": "near:mainnet",
    "destinationAsset": "near:mainnet/nep141:17208628f84f5d6ad33f0da3bbbeb27ffcb398eac501a31bd6ad2011e36133a1",
    "destinationRecipient": "merchant.near",
    "amountOut": "1000000",
    "minAmountIn": "1000000",
    "depositMemo": null,
    "slippageTolerance": 100,
    "timeEstimate": 120,
    "refundTo": "0x2527D02599Ba641c19FEa793cD0F9a6e8457C317",
    "settlementBackend": "near-intents",
    "credentialTypes": ["hash"]
  }
}

5. Credential Schema

The credential in the Authorization header contains a base64url-encoded JSON object per [I-D.httpauth-payment].¶

{
  "challenge": {
    "id": "qB3wErTyU7iOpAsD9fGhJk",
    "realm": "api.example.com",
    "method": "nearintents",
    "intent": "charge",
    "request": "eyJ...",
    "expires": "2026-06-25T15:10:00Z"
  },
  "payload": {
    "type": "hash",
    "hash": "0x9bcff372aee89b648c922b850573b22387c31d693079f5e37cd255814e2d615a"
  },
  "source": "did:pkh:eip155:42161:0x2527D02599Ba641c19FEa793cD0F9a6e8457C317"
}

6. Challenge Expiry and Deposit Deadline

The challenge expires auth-param ([I-D.httpauth-payment]) MUST be set to the 1Click quote deadline, or to a slightly earlier time, so that a deposit made before expires is still within the quote's validity window.¶

Clients MUST NOT broadcast a deposit transaction after the challenge expires timestamp. A deposit that arrives at the deposit address after the quote deadline may be refunded to methodDetails.refundTo rather than swapped.¶

Servers SHOULD set expires such that the remaining window before the quote deadline accommodates origin-chain confirmation plus methodDetails.timeEstimate. Because the deposit address is time-limited, servers SHOULD cache the challenge for a given resource until the quote deadline and reissue the same challenge (including the same recipient) for repeated requests, regenerating only when the deadline passes.¶

7. Challenge Binding

The challenge id binds the challenge parameters per [I-D.httpauth-payment], including request, which carries recipient (the deposit address), amount, and currency. Servers MUST verify that the credential echoes a challenge whose recomputed binding matches the id they issued (for example, via the HMAC-SHA256 mechanism in [I-D.httpauth-payment]), and MUST reject credentials presenting an unknown, expired, modified, or already-settled id.¶

Because the 1Click backend issues a unique deposit address per quote, the recipient in each challenge is challenge-specific. A deposit transaction observed at that address is therefore implicitly bound to the single challenge that advertised it — an attacker cannot present the same deposit against a different challenge, because a different challenge has a different recipient. This gives push mode under this method a stronger practical binding than hash credentials whose recipient is a static merchant address shared across many challenges. See Section 13.3.¶

8. Verification

Upon receiving a request with a credential, the server MUST first validate that payload.type is "hash", then perform the following checks. If any check fails, the server MUST return a verification-failed error per [I-D.httpauth-payment] (or a more specific code from Section 9).¶

If the origin-chain RPC or the 1Click status endpoint is unavailable for a required check, servers MUST treat this as a server error (HTTP 5xx) rather than a verification-failed response, and MUST NOT settle the credential.¶

1. The challenge id matches an outstanding, unsettled challenge issued by this server, the recomputed challenge binding matches id (Section 7), and the current time is before the challenge expires auth-param.¶

2. payload.hash has not been previously consumed (see Section 12).¶

3. The transaction identified by payload.hash exists on methodDetails.originNetwork, is confirmed to that chain's policy (see Section 10), and transfers at least methodDetails.minAmountIn of currency to the challenge recipient (the deposit address), including methodDetails.depositMemo when non-null. This confirmation MUST be performed either by querying the origin chain directly, or by querying the 1Click status endpoint and observing that the backend has detected a qualifying deposit at recipient. Relying solely on client-asserted payload fields does not satisfy this requirement.¶

4. The deposit address (recipient) corresponds to an active, non-expired, non-settled quote in the server's state.¶

5. Claim payload.hash as in-flight for this challenge, rejecting any concurrent or later submission of the same hash while settlement runs. The hash is permanently consumed only on a terminal settlement state (see Section 10 and Section 12); verification alone does not burn the credential. On a non-success terminal state the client recovers with a fresh challenge (see Section 10.1).¶

Verification confirms that the client has paid the origin-chain leg. The cross-chain swap that delivers the destination asset to the merchant is driven during settlement (Section 10); a Payment-Receipt is issued only after that delivery completes.¶

9. Error Codes

This specification defines the following additional error code beyond those in [I-D.httpauth-payment]:¶

Other failure conditions map to the standard problem types of [I-D.httpauth-payment]:¶

As required by [I-D.httpauth-payment], every rejection returns HTTP 402 with a fresh WWW-Authenticate: Payment challenge and a Problem Details [RFC9457] body with Content-Type: application/problem+json.¶

10. Settlement Procedure

After successful verification, the server drives the swap to finality before granting access. The server:¶

1. Notifies the 1Click backend of the deposit (optional but recommended, as it accelerates processing; the backend also detects deposits automatically). This corresponds to the 1Click deposit-notification endpoint, supplying the transaction hash and deposit address.¶

2. Polls the 1Click status endpoint for the deposit address until a terminal status is reached, or until the time implied by the challenge expires window is exceeded. Terminal statuses are SUCCESS, FAILED, REFUNDED, and INCOMPLETE_DEPOSIT.¶

3. On SUCCESS — the merchant has received methodDetails.amountOut of methodDetails.destinationAsset on methodDetails.destinationNetwork — returns the resource with a Payment-Receipt header per Section 11.¶

4. On FAILED or REFUNDED, returns a settlement-failed error per Section 9. On INCOMPLETE_DEPOSIT, returns payment-insufficient. In all non-success terminal cases the backend refunds the deposit to methodDetails.refundTo; the server MUST NOT grant access.¶

5. On reaching any terminal status, permanently consume payload.hash (see Section 12). After a terminal state the quote and its deposit address are spent — the deposit was either delivered (SUCCESS) or refunded — so the same hash MUST NOT be accepted again.¶

11. Receipt

Upon successful settlement, servers MUST return a Payment-Receipt header per [I-D.httpauth-payment]. Servers MUST NOT include a Payment-Receipt header on error responses.¶

The receipt payload fields:¶

Example (decoded):¶

{
  "method": "nearintents",
  "challengeId": "qB3wErTyU7iOpAsD9fGhJk",
  "reference": "FtChYxxQh1k6vKjQ9wq5q1f8s2n3p4r5t6u7v8w9x0yz",
  "status": "success",
  "timestamp": "2026-06-25T15:12:11Z",
  "originTxHash": "0x9bcff372aee89b648c922b850573b22387c31d693079f5e37cd255814e2d615a",
  "destinationNetwork": "near:mainnet",
  "externalId": "order_12345"
}

12. Replay Protection

Per [I-D.httpauth-payment], payment proofs MUST be single-use. This method enforces replay protection on two layers:¶

• Deposit address as nonce: each quote yields a unique deposit address, and the 1Click backend processes at most one swap per address. The server MUST reject any credential whose recipient (deposit address) does not correspond to an active, non-expired, non-settled quote in its state.¶

• Single-use transaction hashes: the server MUST track each payload.hash and reject any hash that is already in-flight or consumed. At verification the hash is claimed as in-flight (atomically, satisfying the concurrency requirement below); it is permanently consumed only when settlement reaches a terminal state — SUCCESS or any failure/refund — so a credential is never burned before its outcome is known and is never reusable afterward. On a non-success terminal state the client obtains a fresh challenge to retry (see Section 10.1).¶

When a single origin transaction is one of several deposits aggregated by the backend to one address (e.g., a top-up after an under-deposit), each individual transaction hash remains single-use; the server MAY accept any one qualifying hash provided the aggregate meets methodDetails.minAmountIn.¶

Servers MUST also satisfy the concurrency requirement of [I-D.httpauth-payment]: concurrent requests bearing the same credential MUST result in at most one settlement and one resource delivery.¶

13. Security Considerations

14. IANA Considerations

15. References

Appendix A. ABNF Collected

nearintents-charge-challenge = "Payment" 1*SP
  "id=" quoted-string ","
  "realm=" quoted-string ","
  "method=" DQUOTE "nearintents" DQUOTE ","
  "intent=" DQUOTE "charge" DQUOTE ","
  "request=" base64url-nopad
  [ "," "expires=" quoted-string ]

nearintents-charge-credential = "Payment" 1*SP base64url-nopad

; Base64url encoding without padding per RFC 4648 Section 5
base64url-nopad = 1*( ALPHA / DIGIT / "-" / "_" )

Appendix B. Examples

HTTP/1.1 402 Payment Required
Cache-Control: no-store
Content-Type: application/problem+json
WWW-Authenticate: Payment id="qB3wErTyU7iOpAsD9fGhJk",
  realm="api.example.com",
  method="nearintents",
  intent="charge",
  request="eyJ...",
  expires="2026-06-25T15:10:00Z"

{
  "type": "https://paymentauth.org/problems/payment-required",
  "title": "Payment Required",
  "status": 402,
  "detail": "Payment required for access."
}

{
  "amount": "1005000",
  "currency": "eip155:42161/erc20:0xaf88d065e77c8cC2239327C5EDb3A432268e5831",
  "recipient": "0x76b4c56085ED136a8744D52bE956396624a730E8",
  "description": "Cross-chain premium data access",
  "externalId": "order_12345",
  "methodDetails": {
    "originNetwork": "eip155:42161",
    "destinationNetwork": "near:mainnet",
    "destinationAsset": "near:mainnet/nep141:17208628f84f5d6ad33f0da3bbbeb27ffcb398eac501a31bd6ad2011e36133a1",
    "destinationRecipient": "merchant.near",
    "amountOut": "1000000",
    "minAmountIn": "1000000",
    "depositMemo": null,
    "slippageTolerance": 100,
    "timeEstimate": 120,
    "refundTo": "0x2527D02599Ba641c19FEa793cD0F9a6e8457C317",
    "settlementBackend": "near-intents",
    "credentialTypes": ["hash"]
  }
}

GET /resource HTTP/1.1
Host: api.example.com
Authorization: Payment eyJ...

{
  "challenge": {
    "id": "qB3wErTyU7iOpAsD9fGhJk",
    "realm": "api.example.com",
    "method": "nearintents",
    "intent": "charge",
    "request": "eyJ...",
    "expires": "2026-06-25T15:10:00Z"
  },
  "payload": {
    "type": "hash",
    "hash": "0x9bcff372aee89b648c922b850573b22387c31d693079f5e37cd255814e2d615a"
  },
  "source": "did:pkh:eip155:42161:0x2527D02599Ba641c19FEa793cD0F9a6e8457C317"
}

HTTP/1.1 200 OK
Cache-Control: private
Payment-Receipt: eyJ...
Content-Type: application/json

{"data": "..."}

{
  "method": "nearintents",
  "challengeId": "qB3wErTyU7iOpAsD9fGhJk",
  "reference": "FtChYxxQh1k6vKjQ9wq5q1f8s2n3p4r5t6u7v8w9x0yz",
  "status": "success",
  "timestamp": "2026-06-25T15:12:11Z",
  "originTxHash": "0x9bcff372aee89b648c922b850573b22387c31d693079f5e37cd255814e2d615a",
  "destinationNetwork": "near:mainnet",
  "externalId": "order_12345"
}

{
  "amount": "38000",
  "currency": "bip122:000000000019d6689c085ae165831e93/slip44:0",
  "recipient": "bc1qxy2kgdygjrsqtzq2n0yrf2493p83kkfjhx0wlh",
  "methodDetails": {
    "originNetwork": "bip122:000000000019d6689c085ae165831e93",
    "destinationNetwork": "near:mainnet",
    "destinationAsset": "near:mainnet/nep141:17208628f84f5d6ad33f0da3bbbeb27ffcb398eac501a31bd6ad2011e36133a1",
    "destinationRecipient": "merchant.near",
    "amountOut": "1000000",
    "minAmountIn": "37500",
    "depositMemo": null,
    "slippageTolerance": 150,
    "timeEstimate": 1800,
    "refundTo": "bc1qm34lsc65zpw79lxes69zkqmk6ee3ewf0j77s3h",
    "settlementBackend": "near-intents",
    "credentialTypes": ["hash"]
  }
}

GET /resource HTTP/1.1
Host: api.example.com
Accept-Payment: nearintents/charge

HTTP/1.1 402 Payment Required
Cache-Control: no-store
WWW-Authenticate: Payment id="qB3wErTyU7iOpAsD9fGhJk", realm="api.example.com", method="nearintents", intent="charge", request="eyJ...arbitrum...", expires="2026-06-25T15:10:00Z"
WWW-Authenticate: Payment id="nH6xJkLpO3qRtYsA6wDcVb", realm="api.example.com", method="nearintents", intent="charge", request="eyJ...bitcoin...", expires="2026-06-25T15:40:00Z"

Appendix C. Acknowledgements

The author thanks the Tempo Labs and Stripe teams for the Machine Payments Protocol framework, and the NEAR Intents and Near One teams for the 1Click Swap settlement system.¶

Author's Address