Network Working Group J. Moxey Internet-Draft B. Ryan Intended status: Informational T. Meagher Expires: 4 September 2026 Tempo Labs 3 March 2026 Charge Intent for HTTP Payment Authentication draft-payment-intent-charge-00 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. 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction 1.1. Relationship to Payment Methods 2. Requirements Language 3. Terminology 4. Intent Semantics 4.1. Definition 4.2. Properties 4.3. Flow 4.4. Atomicity 5. Request Schema 5.1. Shared Fields 5.1.1. Required Fields 5.1.2. Optional Fields 5.2. Currency Formats 5.3. Method Extensions 5.4. Examples 5.4.1. Traditional Payment Processor (Stripe) 5.4.2. Blockchain Payment (Tempo) 5.4.3. Lightning Network 6. Credential Requirements 6.1. Payload 6.2. Single-Use 7. Verification 7.1. Server Responsibilities 7.2. Settlement 8. Security Considerations 8.1. Amount Verification 8.2. Recipient Verification 8.3. Replay Protection 8.4. Finality 9. IANA Considerations 9.1. Payment Intent Registration 10. Normative References Authors' Addresses 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: * Invoice-based systems (preimage revelation) * Signed transaction authorization * Token-based payment confirmation * Traditional payment processor confirmation 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 +=====================+====================================+ | Property | Value | +=====================+====================================+ | *Intent Identifier* | charge | +---------------------+------------------------------------+ | *Payment Timing* | Immediate (before or with request) | +---------------------+------------------------------------+ | *Idempotency* | Single-use per challenge | +---------------------+------------------------------------+ | *Reversibility* | Method-dependent | +---------------------+------------------------------------+ Table 1 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 +==========+========+==============================+ | Field | Type | Description | +==========+========+==============================+ | amount | string | Payment amount in base units | | | | (smallest denomination) | +----------+--------+------------------------------+ | currency | string | Currency or asset identifier | | | | (see Section 5.2) | +----------+--------+------------------------------+ Table 2 5.1.2. Optional Fields +===============+========+=============================+ | 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 | +---------------+--------+-----------------------------+ Table 3 5.2. Currency Formats The currency field supports multiple formats to accommodate different payment networks: +================+==============+=============================+ | Format | Example | Description | +================+==============+=============================+ | ISO 4217 | "usd", "eur" | Fiat currencies (lowercase) | +----------------+--------------+-----------------------------+ | Method-defined | (varies) | Payment method-specific | | | | currency identifiers | +----------------+--------------+-----------------------------+ Table 4 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: +==============+=========================+=================+ | Proof Type | Description | Example Methods | +==============+=========================+=================+ | Preimage | Hash preimage proving | Lightning | | | invoice payment | | +--------------+-------------------------+-----------------+ | Signature | Signed transaction | Tempo, EVM | | | authorization | | +--------------+-------------------------+-----------------+ | Confirmation | Payment processor | Stripe | | | confirmation identifier | | +--------------+-------------------------+-----------------+ | Ledger | Transaction hash on | Bitcoin, | | transaction | public ledger | Ethereum | +--------------+-------------------------+-----------------+ Table 5 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]: +========+============================+===============+ | Intent | Description | Reference | +========+============================+===============+ | charge | One-time immediate payment | This document | +--------+----------------------------+---------------+ Table 6 10. 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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [I-D.httpauth-payment] Moxey, J., "The 'Payment' HTTP Authentication Scheme", January 2026, . Authors' Addresses Jake Moxey Tempo Labs Email: jake@tempo.xyz Brendan Ryan Tempo Labs Email: brendan@tempo.xyz Tom Meagher Tempo Labs Email: thomas@tempo.xyz