Internet-Draft Payment Intent Charge March 2026
Moxey, et al. Expires 4 September 2026 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-payment-intent-charge-00
Published:
Intended Status:
Informational
Expires:
Authors:
J. Moxey
Tempo Labs
B. Ryan
Tempo Labs
T. Meagher
Tempo Labs

Charge Intent for HTTP Payment Authentication

Abstract

This document defines the "charge" payment intent for use with the Payment HTTP Authentication Scheme [I-D.httpauth-payment]. The "charge" intent represents a one-time payment where the payer provides proof of payment immediately in exchange for resource access.

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 4 September 2026.

▲

Table of Contents

1. Introduction

The "charge" intent is the most fundamental payment pattern: a one-time exchange of payment for resource access. The payer provides proof of payment (or a signed authorization to collect payment), and the server grants access to the requested resource.

This intent applies to any payment method that supports immediate payment verification, including:

1.1. Relationship to Payment Methods

This document defines the abstract semantics of the "charge" intent. Payment method specifications define how to implement this intent using their specific payment infrastructure.

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

Charge

A one-time payment where the payer provides proof of payment immediately in exchange for resource access.

Base Units

The smallest denomination of a currency or asset. For USD, this is cents (1/100). For tokens, this is the smallest transferable unit defined by the token's decimal precision.

4. Intent Semantics

4.1. Definition

The "charge" intent represents a request for immediate, one-time payment of a specified amount in exchange for resource access.

4.2. Properties

Table 1
Property Value
Intent Identifier charge
Payment Timing Immediate (before or with request)
Idempotency Single-use per challenge
Reversibility Method-dependent

4.3. Flow

  1. Server issues a 402 response with intent="charge"

  2. Client fulfills the payment (method-specific)

  3. Client submits credential with proof of payment

  4. Server verifies payment and grants access

  5. Server returns Payment-Receipt header

4.4. Atomicity

The "charge" intent implies atomic exchange: the server SHOULD NOT provide partial access if payment verification fails. Either the full resource is provided (payment succeeded) or access is denied (payment failed).

5. Request Schema

The request parameter for a "charge" intent is a JSON object with shared fields defined by this specification and optional method-specific extensions in the methodDetails field.

5.1. Shared Fields

All payment methods implementing the "charge" intent MUST support these shared fields, enabling clients to parse and display payment requests consistently across methods.

5.1.1. Required Fields

Table 2
Field Type Description
amount string Payment amount in base units (smallest denomination)
currency string Currency or asset identifier (see Section 5.2)

5.1.2. Optional Fields

Table 3
Field Type Description
recipient string Payment recipient in method-native format
expires string Expiry timestamp in ISO 8601 format
description string Human-readable payment description
externalId string Merchant's reference (order ID, invoice number, etc.)
methodDetails object Method-specific extension data

5.2. Currency Formats

The currency field supports multiple formats to accommodate different payment networks:

Table 4
Format Example Description
ISO 4217 "usd", "eur" Fiat currencies (lowercase)
Method-defined (varies) Payment method-specific currency identifiers

Payment method specifications MUST document which currency formats they support and how to interpret amounts for each format.

5.3. Method Extensions

Payment methods MAY define additional fields in the methodDetails object. These fields are method-specific and MUST be documented in the payment method specification. Clients that do not recognize a payment method SHOULD ignore methodDetails but MUST still be able to display the shared fields to users.

5.4. Examples

5.4.1. Traditional Payment Processor (Stripe) 

{
  "amount": "5000",
  "currency": "usd",
  "description": "Premium API access",
  "externalId": "order_12345",
  "methodDetails": {
    "businessNetwork": "bn_1MqDcVKA5fEO2tZvKQm9g8Yj",
    "destination": "acct_1MqE1vKB6gFP3uYw"
  }
}

5.4.2. Blockchain Payment (Tempo) 

{
  "amount": "1000000",
  "currency": "0x20c0000000000000000000000000000000000000",
  "recipient": "0x742d35Cc6634C0532925a3b844Bc9e7595f8fE00",
  "expires": "2025-01-06T12:00:00Z",
  "methodDetails": {
    "chainId": 42431,
    "feePayer": true
  }
}

5.4.3. Lightning Network 

{
  "amount": "100000",
  "currency": "sat",
  "expires": "2025-01-15T12:05:00Z",
  "methodDetails": {
    "invoice": "lnbc1000n1pj9..."
  }
}

Payment method specifications define the complete methodDetails schema for their implementation of the "charge" intent.

6. Credential Requirements

6.1. Payload

The credential payload for a "charge" intent MUST contain proof that payment has been made or authorized. The proof type is method-specific:

Table 5
Proof Type Description Example Methods
Preimage Hash preimage proving invoice payment Lightning
Signature Signed transaction authorization Tempo, EVM
Confirmation Payment processor confirmation identifier Stripe
Ledger transaction Transaction hash on public ledger Bitcoin, Ethereum

6.2. Single-Use

Each credential MUST be usable only once per challenge. Servers MUST reject replayed credentials.

7. Verification

7.1. Server Responsibilities

Servers verifying a "charge" credential MUST:

  1. Verify the id matches an outstanding challenge

  2. Verify the challenge has not expired

  3. Verify the payment proof using method-specific procedures

  4. Verify the payment amount matches the request

  5. Verify the payment recipient matches the request

7.2. Settlement

Settlement semantics differ by method:

  • Immediate settlement: Payment is final upon verification (e.g., Lightning preimage, confirmed blockchain transaction)

  • Deferred settlement: Server submits payment after verification (e.g., signed authorization submitted to chain)

  • Processor settlement: External processor handles settlement (e.g., Stripe PaymentIntent)

8. Security Considerations

8.1. Amount Verification

Clients MUST verify the requested amount is appropriate for the resource before authorizing payment. Malicious servers could request excessive amounts.

8.2. Recipient Verification

Clients SHOULD verify the payment recipient when possible. For methods that support recipient verification (e.g., known merchant addresses), clients SHOULD warn users about unknown recipients.

8.3. Replay Protection

Servers MUST implement replay protection. Each challenge id MUST be single-use. Servers MUST NOT accept the same credential twice.

8.4. Finality

The finality of a "charge" payment depends on the payment method:

  • Some methods provide instant finality (Lightning)

  • Some methods may have delayed finality (blockchain confirmations)

  • Some methods may be reversible (card chargebacks)

Servers SHOULD understand the finality guarantees of their accepted payment methods and adjust resource access accordingly.

9. IANA Considerations

9.1. Payment Intent Registration

This document registers the "charge" intent in the "HTTP Payment Intents" registry established by [I-D.httpauth-payment]:

Table 6
Intent Description Reference
charge One-time immediate payment This document

10. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <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, , <https://www.rfc-editor.org/info/rfc8174>.
[I-D.httpauth-payment]
Moxey, J., "The 'Payment' HTTP Authentication Scheme", , <https://datatracker.ietf.org/doc/draft-httpauth-payment/>.

Authors' Addresses

Jake Moxey
Tempo Labs
Brendan Ryan
Tempo Labs
Tom Meagher
Tempo Labs