Amendment XLS: Direct Debit

[tadejgolobic]

title: Direct Debit
description: Pre-authorized pull payments enabling Payee-initiated debits under per-pull, per-interval, and single-use limits.
author: Tadej Golobic (GateHub)
category: Amendment
status: Proposal
created: 2026-07-01
updated: 2026-07-01

Table of Contents

• 1. Abstract
• 2. Motivation
• 3. Introduction
  • 3.1 Terminology
  • 3.2 Summary
• 4. Specification
  • 4.1 Ledger Entries
    • 4.1.1 Authorization
      • 4.1.1.1 Object Identifier
      • 4.1.1.2 Fields
      • 4.1.1.3 Flags
      • 4.1.1.4 Ownership
      • 4.1.1.5 Reserves
      • 4.1.1.6 Deletion
      • 4.1.1.7 Freeze / Lock
      • 4.1.1.8 Invariants
      • 4.1.1.9 RPC Name
      • 4.1.1.10 Example JSON
  • 4.2 Transactions
    • 4.2.1 AuthorizationCreate
      • 4.2.1.1 Fields
      • 4.2.1.2 Flags
      • 4.2.1.3 Transaction Fee
      • 4.2.1.4 Failure Conditions
      • 4.2.1.5 State Changes
      • 4.2.1.6 Example JSON
    • 4.2.2 AuthorizationUpdate
      • 4.2.2.1 Fields
      • 4.2.2.2 Flags
      • 4.2.2.3 Transaction Fee
      • 4.2.2.4 Failure Conditions
      • 4.2.2.5 State Changes
      • 4.2.2.6 Example JSON
    • 4.2.3 AuthorizationDelete
      • 4.2.3.1 Fields
      • 4.2.3.2 Flags
      • 4.2.3.3 Transaction Fee
      • 4.2.3.4 Failure Conditions
      • 4.2.3.5 State Changes
      • 4.2.3.6 Example JSON
    • 4.2.4 Payment (modified)
      • 4.2.4.1 Fields (additions and modified semantics)
      • 4.2.4.2 Flags
      • 4.2.4.3 Transaction Fee
      • 4.2.4.4 Failure Conditions
      • 4.2.4.5 State Changes
      • 4.2.4.6 Metadata Fields
      • 4.2.4.7 Example JSON
• 5. Rationale
• 6. Backwards Compatibility
• 7. Test Plan
• 8. Reference Implementation
• 9. Security Considerations
• 10. Appendix
  • 10.1 Design Discussion
  • 10.2 FAQ

1. Abstract

This specification introduces the Authorization ledger object and the AuthorizationCreate, AuthorizationUpdate, and AuthorizationDelete transactions to enable Payee-initiated ("pull") payments on the XRP Ledger. A new optional AuthorizationID field on the Payment transaction allows a designated Payee to debit funds from a Payer's account, bounded by a per-pull amount cap, an optional per-interval aggregate cap, and an optional expiration, with an optional single-use flag that terminates the authorization after the first successful pull. An odometer mechanism tracks per-interval consumption on rate-limited authorizations, enabling protocol-level enforcement of limits without external monitoring.

2. Motivation

The XRP Ledger currently supports only "push" payments, requiring the Payer to sign every transaction. This is insufficient for recurring financial flows — subscriptions, utility billing, payroll-on-chain, automated service fees - where the Payee must pull funds based on a prior agreement.

Existing primitives partially address the need but each has limitations:

• Payment Channels support Payee-initiated claims but require the Payer to pre-fund the channel, locking capital until the channel is claimed or closed. Direct debit keeps capital liquid in the Payer's account until the moment of pull.
• Escrow holds funds for time- or condition-based release, but the release path is fixed at creation and not suitable for recurring variable amounts.
• DepositPreauth authorizes a counterparty to send funds to an account with lsfDepositAuth enabled; it does not authorize pulling.

This proposal complements existing primitives by providing a secure, revocable, just-in-time pull mechanism. It mirrors the semantic model of SEPA Direct Debit mandates: a standing authorization keyed by an identifier, with creditor-initiated debits bounded by mandate terms, and unilateral revocation by the debtor at any time.

3. Introduction

3.1 Terminology

• Payer: The account that owns the Authorization object. The source of funds debited on a successful pull.
• Payee: The account designated as AuthorizedAccount on the Authorization object. The only account permitted to initiate a pull against the authorization.
• Pull payment: A Payment transaction signed by the Payee that includes an AuthorizationID, debiting the Payer and delivering to the transaction's Destination.
• Per-pull cap: LimitAmount acts as an upper bound on the amount of any single pull, whether or not an interval is set.
• Interval-capped: An authorization with Interval > 0. The Payee may pull up to LimitAmount in aggregate per rolling interval, tracked by the odometer.
• Unmetered: An authorization with Interval == 0 and without the single-use flag. Each pull is capped at LimitAmount, but there is no aggregate cap and no odometer state; unlimited pulls are permitted until the Payer revokes or the authorization expires.
• Single-use: An authorization created with tfSingleUse. The object is deleted automatically on the first successful pull.
• Odometer: The DeliveredInPeriod field on the Authorization object, which tracks cumulative pulls within the current interval. Only maintained when Interval > 0.
• Interval rollover: When the time since LastPullTimestamp first exceeds Interval, DeliveredInPeriod is reset to zero. The check is performed on the next pull attempt, against the parent ledger close time.

3.2 Summary

Ledger Entries introduced

• Authorization: stores the terms (Payee, currency, per-pull cap, optional interval, optional expiration, optional single-use flag) under which the Payer permits pulls.

Transactions introduced

• AuthorizationCreate: Payer establishes a pull authorization. Supports a tfSingleUse flag for one-shot authorizations that self-destruct on first pull.
• AuthorizationUpdate: Payer modifies limit, interval, or expiration without rotating the AuthorizationID. The single-use flag is immutable after creation.
• AuthorizationDelete: Payer revokes an authorization, or any account reaps an expired authorization.

Transactions modified

• Payment: gains an optional AuthorizationID field. When present, the transaction is a pull payment whose debit side is bound to the Payer named in the referenced Authorization.

APIs introduced
None. Existing account_objects and ledger_entry RPCs cover the new object via standard typing.

4. Specification

4.1 Ledger Entries

4.1.1 Authorization

The Authorization object stores the terms granted by a Payer to a Payee.

4.1.1.1 Object Identifier

The key space for the Authorization object is 0x0050. (Subject to confirmation against the current reservation table at implementation time.)

AuthorizationID = SHA512Half(
      0x0050        // key space, UINT16
   || Account       // ACCOUNTID, 20 bytes (Payer)
   || Sequence      // UINT32, sequence of the AuthorizationCreate tx
)

If AuthorizationCreate is submitted via a Ticket, Sequence in the above derivation is replaced by the TicketSequence consumed by the transaction.

4.1.1.2 Fields

Field Name	Constant	Required	Internal Type	Default Value	Description
LedgerEntryType	Yes	Yes	UINT16	N/A	0x0050 (Authorization).
Account	Yes	Yes	ACCOUNTID	N/A	The Payer. Owner of the object; debited on each pull.
AuthorizedAccount	Yes	Yes	ACCOUNTID	N/A	The Payee authorized to initiate pulls.
LimitAmount	No	Yes	AMOUNT	N/A	Upper bound on the amount of any single pull. When Interval > 0, also serves as the aggregate cap for the current interval (tracked by DeliveredInPeriod). Defines the currency and issuer for all pulls.
Interval	No	No	UINT32	0	Rolling reset period in seconds. 0 disables the aggregate cap (unmetered — each pull remains capped by LimitAmount, no per-interval accounting). Non-zero values must be >= 60.
Expiration	No	No	UINT32	0	Ripple Epoch timestamp after which the authorization is void. 0 means no expiration.
DeliveredInPeriod	No	No	AMOUNT	0	Cumulative amount pulled in the current interval. Same currency/issuer as LimitAmount. Maintained only when Interval > 0; when Interval == 0 the field is present but never updated.
LastPullTimestamp	No	No	UINT32	0	Parent ledger close time of the last successful pull. Used to determine interval rollover; maintained only when Interval > 0.
OwnerNode	No	Yes	UINT64	N/A	Owner directory page hint.
PreviousTxnID	No	Yes	HASH256	N/A	Hash of the transaction that most recently modified this object.
PreviousTxnLgrSeq	No	Yes	UINT32	N/A	Ledger sequence of the transaction that most recently modified this object.
Flags	Yes	Yes	UINT32	0	Bitfield of lsf flags. See §4.1.1.3.

4.1.1.3 Flags

Flag Name	Flag Value	Description
lsfSingleUse	0x00010000	The authorization is single-use. On the first successful pull, the object is deleted and the owner reserve is returned to the Payer. See §4.1.1.6.

4.1.1.4 Ownership

The Authorization object is owned by the Account (Payer) and is recorded in that account's OwnerDirectory. The AuthorizedAccount is not an owner of the object and has no entry in its own owner directory for this purpose.

4.1.1.5 Reserves

Each Authorization object increments the Payer's owner count by 1, requiring one incremental owner reserve. Standard fee voting applies. There is no deviation from default behavior.

4.1.1.6. Deletion

An Authorization object is deleted in any of the following cases:

• The Payer submits AuthorizationDelete for the object's AuthorizationID.
• Any account submits AuthorizationDelete for the object when parentCloseTime() >= Expiration and Expiration != 0.
• A successful pull Payment is applied against an Authorization with lsfSingleUse set.
  The owner reserve is always returned to the Payer regardless of which path triggers deletion.

The Authorization object is a deletion blocker for its owner: an account holding one or more Authorization objects as Payer cannot be deleted via AccountDelete until all such objects are removed.

4.1.1.7 Freeze / Lock

Authorization itself holds no assets. Freeze and lock semantics apply at pull time to the Payer's trust line for the asset described by LimitAmount, exactly as for an ordinary Payment whose source is the Payer:

• Global freeze on the issuer of LimitAmount's currency blocks pulls.
• Individual freeze on the Payer's trust line for the issued currency blocks pulls.
• MPT locking applied to the Payer for the relevant MPTokenIssuance blocks pulls.

Pulls blocked by freeze/lock fail with the corresponding standard Payment failure code (tecFROZEN, tecLOCKED, etc.). The Authorization object itself is not deleted by a freeze/lock event.

4.1.1.8 Invariants

Let <auth> denote the Authorization object before transaction application and <auth>' after.

• <auth>'.LedgerEntryType == <auth>.LedgerEntryType
• <auth>'.Account == <auth>.Account
• <auth>'.AuthorizedAccount == <auth>.AuthorizedAccount
• <auth>'.Flags == <auth>.Flags (all lsf flags, including lsfSingleUse, are constant after creation)
• currency(<auth>'.LimitAmount) == currency(<auth>.LimitAmount) and issuer(<auth>'.LimitAmount) == issuer(<auth>.LimitAmount)
• After a successful pull: <auth>'.DeliveredInPeriod <= <auth>'.LimitAmount
• If <auth>.Interval > 0, then <auth>'.LastPullTimestamp >= <auth>.LastPullTimestamp
• If <auth>.Interval == 0, then <auth>'.DeliveredInPeriod == <auth>.DeliveredInPeriod and <auth>'.LastPullTimestamp == <auth>.LastPullTimestamp (odometer state is inert)
• For AuthorizationUpdate: if <auth>'.Expiration != 0, then <auth>'.Expiration > parentCloseTime() at application

4.1.1.9 RPC Name

In account_objects and ledger_data type filters: authorization.

4.1.1.10. Example JSON

{
  "LedgerEntryType": "Authorization",
  "Account": "rPayerAccount...",
  "AuthorizedAccount": "rPayeeAccount...",
  "LimitAmount": {
    "currency": "EUR",
    "issuer": "rIssuerAccount...",
    "value": "50"
  },
  "Interval": 2592000,
  "Expiration": 820454400,
  "DeliveredInPeriod": {
    "currency": "EUR",
    "issuer": "rIssuerAccount...",
    "value": "12.50"
  },
  "LastPullTimestamp": 798220800,
  "OwnerNode": "0",
  "PreviousTxnID": "F4D7C9...A2B1",
  "PreviousTxnLgrSeq": 87234901,
  "Flags": 0,
  "index": "9C8E2A..."
}

4.2 Transactions

4.2.1 AuthorizationCreate

Submitted by the Payer to establish a pull authorization.

4.2.1.1 Fields

Field Name	Required?	JSON Type	Internal Type	Default Value	Description
TransactionType	Yes	string	UINT16	N/A	AuthorizationCreate.
Account	Yes	string	ACCOUNTID	N/A	The Payer (signer).
AuthorizedAccount	Yes	string	ACCOUNTID	N/A	The Payee authorized to pull. Must differ from Account and reference an existing, funded account.
LimitAmount	Yes	object or string	AMOUNT	N/A	Per-pull cap. When Interval > 0, also serves as the aggregate cap for the current interval. Must be strictly positive.
Interval	No	number	UINT32	0	Rolling reset period in seconds. Must be 0 or >= 60. 0 = no aggregate cap (each pull remains capped by LimitAmount).
Expiration	No	number	UINT32	0	Ripple Epoch timestamp. Must be strictly greater than parentCloseTime at submission.
Flags	No	number	UINT32	0	Standard transaction flags plus any tf flags defined below (§4.2.1.2).

4.2.1.2 Flags

Flag Name	Flag Value	Description
tfSingleUse	0x00010000	Creates the Authorization with lsfSingleUse set. On the first successful pull, the object is deleted and the owner reserve is returned to the Payer. Compatible with any Interval value (though most commonly used with Interval == 0).

4.2.1.3. Transaction Fee

Standard transaction fee applies; no deviation.

4.2.1.4 Failure Conditions

Data validation (tem):

• temBAD_AMOUNT — LimitAmount is non-positive or malformed.
• temBAD_EXPIRATION — Expiration is not strictly in the future.
• temBAD_INTERVAL — Interval is positive and less than 60.
• temDST_IS_SRC — AuthorizedAccount equals Account.
• temINVALID_FLAG — Reserved tf flag bits are set.

Protocol-level (tec):

• tecNO_DST — AuthorizedAccount does not exist on the ledger.
• tecINSUFFICIENT_RESERVE — Payer cannot meet the incremented owner reserve.

4.2.1.5 State Changes

• A new Authorization ledger entry is created with the fields supplied in the transaction. The lsfSingleUse bit of the object's Flags is set iff tfSingleUse was set on the transaction. DeliveredInPeriod is initialized to zero in the currency/issuer of LimitAmount. LastPullTimestamp is initialized to 0.
• The Payer's owner count is incremented by 1.
• The Authorization's AuthorizationID is added to the Payer's OwnerDirectory.

4.2.1.6 Example JSON

Recurring subscription (€50 per 30 days, fixed 1-year term):

{
  "TransactionType": "AuthorizationCreate",
  "Account": "rPayerAccount...",
  "AuthorizedAccount": "rPayeeAccount...",
  "LimitAmount": {
    "currency": "EUR",
    "issuer": "rIssuerAccount...",
    "value": "50"
  },
  "Interval": 2592000,
  "Expiration": 820454400,
  "Fee": "12"
}

Unmetered per-pull cap for a card-like flow (€500 max per pull, no aggregate cap, expires with card):

{
  "TransactionType": "AuthorizationCreate",
  "Account": "rPayerAccount...",
  "AuthorizedAccount": "rProcessorAccount...",
  "LimitAmount": {
    "currency": "EUR",
    "issuer": "rIssuerAccount...",
    "value": "500"
  },
  "Expiration": 883008000,
  "Fee": "12"
}

Single-use authorization for a one-off invoice (€1,200, must be pulled within 7 days):

{
  "TransactionType": "AuthorizationCreate",
  "Account": "rPayerAccount...",
  "AuthorizedAccount": "rMerchantAccount...",
  "LimitAmount": {
    "currency": "EUR",
    "issuer": "rIssuerAccount...",
    "value": "1200"
  },
  "Expiration": 798825600,
  "Flags": 65536,
  "Fee": "12"
}

4.2.2 AuthorizationUpdate

Submitted by the Payer to modify an existing authorization without rotating its AuthorizationID.

4.2.2.1 Fields

Field Name	Required?	JSON Type	Internal Type	Default Value	Description
TransactionType	Yes	string	UINT16	N/A	AuthorizationUpdate.
Account	Yes	string	ACCOUNTID	N/A	The Payer (signer).
AuthorizationID	Yes	string	HASH256	N/A	ID of the object to modify.
LimitAmount	No	object or string	AMOUNT	N/A	New per-pull cap (also aggregate cap when Interval > 0). Currency and issuer must match the existing object.
Interval	No	number	UINT32	N/A	New rolling reset period in seconds. 0 disables the aggregate cap; non-zero values must be >= 60.
Expiration	No	number	UINT32	N/A	New expiration. 0 removes any existing expiration.

At least one of LimitAmount, Interval, or Expiration must be present. The lsfSingleUse flag is fixed at creation and cannot be modified here (see §4.1.1.8 Invariants).

AuthorizationUpdate does not reset DeliveredInPeriod or LastPullTimestamp. If the new LimitAmount is lower than the current DeliveredInPeriod, subsequent pulls fail with tecAUTH_LIMIT_EXCEEDED until the next interval rollover. Changing Interval from a non-zero value to 0 freezes the odometer at its current value (no further increments, no rollover); changing Interval from 0 to a non-zero value starts the odometer from zero at the next pull.

4.2.2.2 Flags

No tf flags are defined for this transaction.

4.2.2.3 Transaction Fee

Standard transaction fee applies; no deviation.

4.2.2.4 Failure Conditions

Data validation (tem):

• temBAD_AMOUNT — LimitAmount is non-positive or malformed.
• temBAD_CURRENCY — LimitAmount currency or issuer does not match the referenced object.
• temBAD_EXPIRATION — Expiration is positive and not strictly in the future.
• temBAD_INTERVAL — Interval is positive and less than 60.
• temMALFORMED — None of LimitAmount, Interval, Expiration provided.

Protocol-level (tec):

• tecAUTH_NOT_FOUND — No Authorization object with the given AuthorizationID.
• tecNO_PERMISSION — Account is not the Payer of the referenced authorization.

4.2.2.5 State Changes

• The referenced Authorization object's LimitAmount, Interval, and/or Expiration are updated to the supplied values.
• All other fields remain unchanged.

4.2.2.6 Example JSON

{
  "TransactionType": "AuthorizationUpdate",
  "Account": "rPayerAccount...",
  "AuthorizationID": "9C8E2A...",
  "LimitAmount": {
    "currency": "EUR",
    "issuer": "rIssuerAccount...",
    "value": "75"
  },
  "Fee": "12"
}

4.2.3 AuthorizationDelete

Submitted by the Payer to revoke an authorization at any time, or by any account to reap an expired authorization.

4.2.3.1 Fields

Field Name	Required?	JSON Type	Internal Type	Default Value	Description
TransactionType	Yes	string	UINT16	N/A	AuthorizationDelete.
Account	Yes	string	ACCOUNTID	N/A	Signer. Either the Payer, or — if the authorization is past its Expiration — any funded account.
AuthorizationID	Yes	string	HASH256	N/A	ID of the object to delete.

4.2.3.2. Flags

No tf flags are defined for this transaction.

4.2.3.3. Transaction Fee

Standard transaction fee applies; no deviation.

4.2.3.4. Failure Conditions

Protocol-level (tec):

• tecAUTH_NOT_FOUND — No Authorization object with the given AuthorizationID.
• tecNO_PERMISSION — Submitted by a non-Payer while the authorization is unexpired or has Expiration == 0.

4.2.3.5. State Changes

• The referenced Authorization object is removed from the ledger.
• The Payer's owner count is decremented by 1 and the corresponding owner reserve is freed.
• The AuthorizationID is removed from the Payer's OwnerDirectory.

4.2.3.6. Example JSON

{
  "TransactionType": "AuthorizationDelete",
  "Account": "rPayerAccount...",
  "AuthorizationID": "9C8E2A...",
  "Fee": "12"
}

4.2.4. Payment (modified)

A new optional AuthorizationID field is added to Payment. When present, the Payment is a pull payment: the transaction signer is the Payee, but balance and trust-line validation are performed against the Payer named in the referenced Authorization.

4.2.4.1. Fields (additions and modified semantics)

Field Name	Required?	JSON Type	Internal Type	Default Value	Description
Account	Yes	string	ACCOUNTID	N/A	When AuthorizationID is present: the Payee (signer). Must equal Authorization.AuthorizedAccount.
Destination	Yes	string	ACCOUNTID	N/A	Recipient of the pulled funds. May be any account, including a third party such as a billing processor forwarding to a merchant.
Amount	Yes	object or string	AMOUNT	N/A	Amount to debit from the Payer. Currency and issuer must match Authorization.LimitAmount.
AuthorizationID	Conditional (pull only)	string	HASH256	N/A	ID of the Authorization object that the pull is executed against. When absent, the Payment behaves identically to its pre-amendment semantics.
SendMax	No	object or string	AMOUNT	N/A	Must be absent when AuthorizationID is present (see §4.2.4.4).
Paths	No	array	PATHSET	N/A	Must be absent when AuthorizationID is present (see §4.2.4.4).

All other Payment fields retain their standard meanings.

Source-of-funds remapping. When AuthorizationID is present, all standard Payment validation that normally applies to tx.Account for the debit side — balance, trust lines, freeze, RequireAuth, sender DepositAuth — is performed against Authorization.Account (the Payer). The transaction signer remains tx.Account (the Payee), and the transaction fee is paid by the Payee.

4.2.4.2. Flags

No new tf flags are introduced for Payment by this amendment. Existing Payment flags retain their meanings; tfPartialPayment and tfLimitQuality are inapplicable to pull payments because cross-currency and partial-payment semantics are prohibited (see §4.2.4.4) and are rejected as temINVALID_FLAG.

4.2.4.3. Transaction Fee

Standard transaction fee applies, paid by the Payee. No deviation.

4.2.4.4. Failure Conditions

In addition to all existing Payment failure conditions, the following apply when AuthorizationID is present.

Data validation (tem):

• temMALFORMED — SendMax or Paths present alongside AuthorizationID and statically detectable at parse time.
• temINVALID_FLAG — tfPartialPayment or tfLimitQuality set on a pull payment.
• temDISABLED — featureDirectDebit is not enabled.

Protocol-level (tec):

• tecAUTH_NOT_FOUND — No Authorization object with the given AuthorizationID.
• tecAUTH_WRONG_PAYEE — tx.Account does not equal Authorization.AuthorizedAccount.
• tecAUTH_EXPIRED — Authorization.Expiration != 0 and parentCloseTime() >= Authorization.Expiration.
• tecAUTH_BAD_CURRENCY — tx.Amount currency or issuer does not match Authorization.LimitAmount.
• tecAUTH_LIMIT_EXCEEDED — Pull would exceed the applicable limit: either tx.Amount > LimitAmount (per-pull cap, always applied) or, when Interval > 0, DeliveredInPeriod + tx.Amount > LimitAmount (aggregate cap).
• Plus all existing Payment tec codes evaluated against the Payer's balance and trust lines (tecUNFUNDED_PAYMENT, tecNO_LINE, tecPATH_DRY, tecFROZEN, tecLOCKED, tecNO_AUTH, …).

4.2.4.5. State Changes

On tesSUCCESS:

• If Authorization.Interval > 0: Authorization.DeliveredInPeriod is incremented by tx.Amount (after lazy interval reset, per §4.2.4.7) and Authorization.LastPullTimestamp is set to parentCloseTime().
• If Authorization.Interval == 0: no odometer update is made; DeliveredInPeriod and LastPullTimestamp remain unchanged.
• If Authorization.Flags & lsfSingleUse: the Authorization object is removed, its owner reserve returned, and its ID removed from the Payer's OwnerDirectory.
• The Payer's relevant balance or trust line is debited by tx.Amount exactly as in a standard Payment where the Payer is the source.
• The Destination's relevant balance or trust line is credited by tx.Amount.

4.2.4.6. Metadata Fields

A synthetic metadata field is added to the validated transaction to ease indexer and explorer disambiguation:

Field Name	Validated	Always Present?	Type	Description
pulled_from_account	No	Conditional (when AuthorizationID is present and transaction succeeds)	string	The Payer (Authorization.Account) from which funds were debited.

4.2.4.7 Example JSON

{
  "TransactionType": "Payment",
  "Account": "rPayeeAccount...",
  "Destination": "rPayeeAccount...",
  "Amount": {
    "currency": "EUR",
    "issuer": "rIssuerAccount...",
    "value": "12.50"
  },
  "AuthorizationID": "9C8E2A...",
  "Fee": "12"
}

5. Rationale

Why not Payment Channels? Channels require pre-funding, which locks capital for the life of the channel. Direct debit keeps capital liquid in the Payer's account until the moment of pull, mirroring how SEPA Direct Debit and ACH function in traditional finance. A user with a dozen subscriptions should not need a dozen funded channels.

Why not DepositPreauth? DepositPreauth authorizes a counterparty to send funds into an account with lsfDepositAuth enabled — it gates inbound flow, not outbound. It is structurally the inverse of what direct debit requires.

Why reuse Payment instead of a new PullPayment transaction? Reusing Payment ensures pull payments inherit standard semantics (fee model, account flags, freezes, RequireAuth checks). It also keeps the amendment surface minimal and avoids duplicating logic across transactors.

Why an integer-seconds Interval? Deterministic, cheap to compare at consensus, and consistent with existing temporal fields (Expiration on Escrow, CancelAfter on PayChannel). String formats (ISO-8601, RFC 5545 RRULE) would introduce parsing complexity and ambiguity at validator level.

Why three orthogonal knobs (LimitAmount, Interval, lsfSingleUse) instead of overloading Interval? My first idea of this proposal actually overloaded Interval == 0 to mean "single-use authorization." That conflates three independent concerns — per-pull cap, aggregate rate limit, and object lifecycle — into a single field. At GateHub, few people gave me a comment about this and I decided that I will separate them:

• LimitAmount always caps any individual pull.
• Interval optionally adds an aggregate cap over a rolling window (odometer). Absent, only the per-pull cap applies.
• lsfSingleUse optionally terminates the authorization after the first successful pull, regardless of Interval.
  The resulting matrix cleanly covers real-world shapes:

Use case	Interval	lsfSingleUse
Recurring subscription (€X per N days)	> 0	unset
Card-like per-pull cap, unlimited count	0	unset
One-off invoice / pending payment	0 (or any)	set

Why the odometer pattern (DeliveredInPeriod)? Lazy reset on next pull is O(1) per transaction and avoids any per-ledger sweep job. Validators evaluate state only when a pull is attempted, and only for interval-capped authorizations.

Why lazy reset over fixed windows? Lazy reset is simpler and avoids edge cases around the "first" window boundary. A known property of lazy reset is that a Payee may pull LimitAmount at t = Interval − ε and again at t = Interval + ε, effectively doubling the per-interval cap in a short burst. This is judged acceptable because (a) the Payer can revoke at any time, (b) the long-run rate remains bounded by LimitAmount / Interval, and (c) fixed anchored windows introduce their own gameable boundaries without materially better security.

Why is lsfSingleUse immutable after creation? A mutable single-use bit would let a Payer flip an already-existing recurring authorization into a self-destructing one, which effectively achieves cancellation without the transparency of AuthorizationDelete (no Deleted transaction in the metadata trail). Immutability preserves clean audit semantics: authorizations are either created single-use or created recurring, and both paths to termination — expiration and explicit delete — are visible on-chain.

Why allow third-party Destination? Real-world billing flows often involve a payment processor pulling on behalf of an underlying merchant. Restricting Destination to the Payee would force the processor either to become the merchant of record or to immediately forward funds in a second transaction, doubling fees. Security is preserved by the Payer's explicit authorization of the Payee — the Payer trusts the Payee to direct funds appropriately, exactly as with a SEPA mandate.

Why a minimum Interval of 60 seconds? Prevents ledger churn from pathological high-frequency authorizations while remaining far below any plausible legitimate use case. The genuine technical floor is one ledger close (roughly 3–5 seconds); the 60-second minimum is a UX guardrail rather than a protocol requirement.

Why a separate AuthorizationUpdate? Payees and their billing systems typically cache the AuthorizationID as a stable mandate reference. Forcing a delete/recreate cycle to change a limit would invalidate that reference and create a window of revocation, both of which are operationally hostile to legitimate subscription billing.

Why prohibit SendMax and Paths initially? A pull payment is signed by the Payee, but slippage in a cross-currency path is a cost borne by the Payer. The Payer has no way to express slippage tolerance in the current Authorization schema, so cross-currency pulls are deferred until a future amendment extends the schema with an explicit per-authorization slippage bound (see §10).

6. Backwards Compatibility

This proposal is strictly additive. The modified Payment transaction behaves identically to its current form when AuthorizationID is absent. New ledger object and transaction types are introduced behind the featureDirectDebit amendment and have no effect on existing applications until activation.

Before activation:

• Transactions of type AuthorizationCreate, AuthorizationUpdate, or AuthorizationDelete are rejected with temDISABLED.
• Payment transactions containing an AuthorizationID are rejected with temDISABLED.
• No ledger object of type 0x0050 exists.

7. Test Plan

A reference test plan is to be provided alongside the rippled pull request. At minimum it must cover:

AuthorizationCreate

• Success with XRP, IOU, and MPT LimitAmounts.
• Success creating each of the three canonical shapes: interval-capped recurring (Interval > 0, lsfSingleUse unset), unmetered per-pull cap (Interval == 0, lsfSingleUse unset), and single-use (lsfSingleUse set).
• Verify lsfSingleUse is correctly reflected in the resulting Authorization object when tfSingleUse is set on the transaction.
• All tem failure paths (bad amount, bad expiration, bad interval, source-is-destination, invalid flag bits).
• tecINSUFFICIENT_RESERVE against an account at its reserve floor.
• tecNO_DST against an unfunded AuthorizedAccount.
• Ticket-based submission.
• Regular Key and SignerList submission.

AuthorizationUpdate

• Independent updates of LimitAmount, Interval, and Expiration.
• temBAD_CURRENCY on currency mismatch.
• tecNO_PERMISSION on submission by non-Payer.
• Update to lower LimitAmount below current DeliveredInPeriod and verify subsequent pull fails with tecAUTH_LIMIT_EXCEEDED until rollover.
• Transition Interval from non-zero to 0: verify odometer state is frozen and subsequent pulls only enforce the per-pull cap.
• Transition Interval from 0 to non-zero: verify next pull starts a fresh odometer from zero.
• Verify lsfSingleUse is immutable — no update path modifies the object's Flags.

AuthorizationDelete

• Payer-initiated delete: reserve returned, owner directory updated.
• Third-party delete after Expiration: reserve returned to Payer.
• tecNO_PERMISSION on third-party delete before Expiration.

Payment (pull)

• Single-currency XRP pull: success and ledger state changes.
• Single-currency IOU pull with all of: freeze, deep freeze, RequireAuth, RequireDest, DepositAuth on Destination (with and without DepositPreauth of Payer), Clawback-enabled trust line.
• tecAUTH_WRONG_PAYEE when a non-authorized account attempts the pull.
• tecAUTH_EXPIRED at and after expiration time.
• tecAUTH_BAD_CURRENCY against a mismatched amount.
• Per-pull cap: tecAUTH_LIMIT_EXCEEDED when tx.Amount > LimitAmount, on both interval-capped and unmetered authorizations, at exact boundary and over.
• Aggregate cap (interval-capped only): tecAUTH_LIMIT_EXCEEDED when DeliveredInPeriod + tx.Amount > LimitAmount, at exact boundary and over.
• Unmetered pull (Interval == 0, lsfSingleUse unset): verify unlimited successful pulls up to LimitAmount each, and confirm DeliveredInPeriod and LastPullTimestamp are never modified.
• Single-use pull (lsfSingleUse set): first successful pull deletes the object and returns the reserve; second attempt fails with tecAUTH_NOT_FOUND.
• Single-use pull with Interval > 0: object is still deleted on first pull (single-use dominates the object's lifecycle regardless of Interval).
• temMALFORMED with SendMax and with Paths.
• Interval rollover at the second boundary.
• Boundary "2× burst" sequence to confirm and document the lazy-reset property.
• Standard Payment failure paths (unfunded, no line, path dry, frozen, locked) propagate.
• Metadata pulled_from_account is present and correct on success.

Account lifecycle

• AccountDelete of a Payer with outstanding authorizations: blocked.
• AccountDelete of a Payee with an authorization naming it: succeeds; subsequent pulls fail; Payer can still revoke and reclaim reserve.

Amendment gating

• All new transactions and the AuthorizationID field rejected with temDISABLED before activation.

8. Reference Implementation

To be added: link to rippled PR(s) and xrpl.js / xrpl-py support PRs.

9. Security Considerations

Payer authority. Only the Payer can create, update, or unilaterally revoke an Authorization. The Payee has no path to widen the terms or to assign the authorization to a different account.

Signer verification. The ledger validates that only the AuthorizedAccount listed in the object may use the AuthorizationID in a pull Payment. The signature check follows standard transaction signing rules and supports Regular Keys and multisigning via SignerList.

Limit enforcement. Enforced at consensus by all validators. No external monitoring required.

Interval boundary behavior. As discussed in §5, lazy reset permits a 2× burst at the interval boundary. Payers needing strict rate limits should set LimitAmount to half the desired ceiling, or revoke and recreate with a fresh window.

Reserve and spam. Each authorization carries an owner reserve, bounding the number of outstanding authorizations a Payer can hold. Failed pulls still incur the standard transaction fee, paid by the Payee, deterring spam-pulls against revoked or limit-exhausted authorizations.

Griefing vectors.

• A Payer cannot grief the Payee beyond revoking the authorization — which is the design intent, not a flaw.
• A Payee attempting pulls when funds are insufficient or limits are exhausted pays the fee on each attempt.
• A third party cannot interact with the authorization in any way other than reaping it after expiration.

Expired-authorization reaping. Any account may delete an expired authorization, with the reserve returned to the Payer. This avoids reserve-lock by neglect, mirroring the EscrowCancel reaping pattern.

Account deletion as Payer. Blocked while authorizations exist, preventing dangling references and ensuring the reserve is properly accounted for at account deletion.

Replay protection. Standard XRPL Sequence / TicketSequence semantics on the pull Payment prevent replay.

Path injection. Paths and SendMax are prohibited on pull payments in this version, eliminating an entire class of pathfinding-based attacks. When cross-currency pull semantics are added in a future amendment, they will require explicit per-authorization slippage bounds set by the Payer.

Interaction with DepositAuth. Standard DepositAuth rules apply to the Destination account exactly as for ordinary Payments. If the Destination has lsfDepositAuth set, the Payer (as the effective sender of funds) must be on the Destination's DepositPreauth list. A Payer with lsfDepositAuth set may still create authorizations: AuthorizationCreate is the Payer's explicit consent and is independent of inbound-deposit gating.

Interaction with Clawback (XLS-39). If LimitAmount is an IOU whose issuer has lsfAllowTrustLineClawback set, balances delivered to the Destination remain subject to clawback exactly as with ordinary Payments.

Amendment safety. Gated behind featureDirectDebit. Before activation, all new transaction types and the AuthorizationID field on Payment are rejected with temDISABLED.

10. Appendix

10.1. Design Discussion

Cross-currency pulls are deferred. The natural way to support them is to add a MinDeliveredAmount field (or equivalent slippage bound) to the Authorization object. The Payer thereby expresses, at authorization time, the minimum acceptable delivered amount for any pull, decoupling the Payee's slippage choices from the Payer's exposure. This is left to a future amendment to keep the present surface area minimal and focused.

Why 0x0050? Chosen as a plausible-looking unused value at the time of writing; subject to confirmation against the live reservation table at PR time.

Why a Default Value of 0 for Interval? 0 reads as "no aggregate rate limit" — the authorization enforces only the per-pull LimitAmount. This makes the most permissive setting (from the Payee's perspective) the default, while the Payer still bounds exposure through LimitAmount, Expiration, and revocation. Recurring authorizations must be explicit about their reset period, which is the right default given that stating an Interval is a deliberate rate-limiting choice.

Why not a MaxPerPull field in addition to LimitAmount? Because LimitAmount already serves this role uniformly across all three authorization shapes. For interval-capped authorizations, LimitAmount acts as both per-pull cap and aggregate cap; for unmetered authorizations, it acts as per-pull cap only. Splitting these into two fields would double the schema surface without adding expressive power, since a Payer wanting distinct per-pull and aggregate caps can compose two Authorization objects.

Card-like flows. For card programs the recommended shape is Interval == 0 with LimitAmount set to the per-transaction cap and Expiration set to the card expiry. Per-day, per-month, and MCC restrictions are enforced by the card processor off-chain, inside the trust envelope the on-chain authorization establishes. This mirrors how existing card networks operate: the network primitive expresses cardholder-to-issuer trust; program rules are enforced by the issuer, not the network.

10.2. FAQ

Q. Can the Payee assign or sublicense the authorization?

No. The AuthorizedAccount field is constant after creation and the Payee has no transaction available to modify or delegate it.

Q. What happens if the Payer's account is reorganized via SetRegularKey after authorization?

Nothing changes from the authorization's perspective. The Account field references the AccountID, not a particular key. Subsequent AuthorizationUpdate / AuthorizationDelete from the Payer use whatever signer is currently valid for that AccountID.

Q. Can the same (Payer, Payee) pair have multiple Authorization objects?

Yes. Each AuthorizationCreate creates a distinct object with its own AuthorizationID derived from the Payer's Sequence. This allows, for example, separate authorizations per currency or per service line, or one small-per-pull authorization plus one large single-use authorization.

Q. Why isn't there an AuthorizationFreeze to temporarily suspend pulls without losing the ID?

AuthorizationUpdate setting LimitAmount to a one-drop minimum, or setting an Expiration in the very near future, can achieve effective suspension. A dedicated freeze field can be added in a later revision if real-world usage shows demand.

Q. How does this handle card-like flows with both per-transaction and per-day limits?

The on-chain primitive expresses one cap dimension. Card processors typically want per-transaction, per-day, per-month, and per-MCC caps simultaneously — those layered rules are enforced by the processor off-chain, using the on-chain authorization only as the outer trust envelope (e.g., Interval == 0 and LimitAmount = per-transaction cap). A Payer wanting layered on-chain caps can hold multiple Authorization objects with different Interval and LimitAmount combinations, but the ledger will only enforce whichever AuthorizationID the Payee references on a given pull.

AI Disclosure: I used ClaudeAI model Opus 4.7 only for grammar issues and for using it to conform to the https://github.com/XRPLF/XRPL-Standards/tree/master/XLS-0001-xls-process.

[sappenin]

Interesting proposal! This seems very close to a check, but is there something different in your proposal?

For pull-payments, Checks are pretty nice but they do have one drawback in the general case: they're tied to a single payee account. That's actually what you want in a check, however I've thought a lot that a derivative idea would be something like a bearer instrument. So, imagine a check but where there's no single (or even predefined) payee. So, anyone with the instrument can redeem it. This reduces to something like a "bearer token" in some sense.

All that to say, is your goal to crate a type of "pull payment" on XRPL, or instead to replicate a sort of "e-cash" on XRPL (or neither)?

[tadejgolobic]

Hi @sappenin
you are correct. Checks are indeed the closes existing primitive to what I proposed here. They overlap in some ways. For example, both are authorized by payer and flow is initiated by the payee. They both have amount limit and expiration set and they settle at the time of the pull. So yes, they are in same neighborhood.

So let's check where they diverge:
Checks are a single shot. When calling CheckCash, funds will be transfered and Check object will be destroyed. So for any recurring flows, the sender has to call CheckCreate for every billing cycle thus requiring sender's signature each time. For example, a 12-month $50 subscription on Checks would require 12 separate CheckCreate transactions, each signed by the Payer. And there is no protocol level guarantee about the rate - aka nothing prevents 12 checks being cashed in a single day or some xy month in a year.

With direct debit, we would have only one AuthorizationCreate transaction and then payee can do 12 Payment transactions and sign them + provide the AuthorizationID.

This is also something called mandate vs per payment distinction and is also compliance relevant. Regimes like SEPA explicitly separate "the mandate", which is a durable authorization instrument from "the debits executed under it". The Authorization ledger object matches that shape, a Check per billing cycle does not.

And to say a few words why at GateHub are thinking about this:

• We have possibility to issue Mastercard Debit cards
• Now we need option, to bring this cards to the non-custodial wallets, so people can spend RLUSD for example, or any other EMTs.
• We also have possibility to open a bank account and user can get it's own IBAN. So we can create SEPA transaction to XRPL and vice-versa. So it would be nice to have this kind of possibility on XRPL.

Yes, this is strictly pull payment on XRPL.

[mvadari]

Is there a difference between this and XLS-78?

[xrpl365]

Thanks Tadej,

I think you provided a balance breakdown of the differences between the 2 proposals, and I agree with the broad framing that Direct Debit is a more general pull-payment primitive.

Having looked at the differences, my view is that the two specs can and probably should be merged. There is a lot of overlap, and if you have a real intention to fund the development of the Direct Debit proposal, and a commitment to ensure it incorporates the full subscription functionality from XLS-78, then I would support a collaborative merge into a single spec rather than progressing two competing amendments.

One clarification I would make is around the naming and intent behind XLS-78. Subscriptions were modelled heavily on UK Direct Debits. The reason we avoided the name “Direct Debit” was not because the concept was unrelated, but because “Direct Debit” is a UK-originated banking term and not necessarily universally understood internationally. “Subscriptions” felt more intuitive and globally recognisable to normal users and developers.

That said, I would be happy for the Direct Debit proposal to become the natural evolution of the subscriptions work, provided the final paper/spec recognises the XLS-78 contribution and incorporates the subscription functionality properly rather than replacing it with a narrower or materially different model.

On naming, I would personally leave that to consensus from the validator/community process. My only concern is that the final name should be something people can understand. From a user and developer perspective, “Subscriptions” may still be the clearer name. The fact that the Direct Debit model broadens the technical scope is important architecturally, but most users and many developers will care more about whether the feature name describes what they can actually use it for.

A few technical points from the XLS-78 side:
The biggest thing I would clarify is the “one claim per Frequency window” point. Having just re-read it, XLS-78 does currently say “Single Claim per Period” in the rationale, so I understand why you read it that way. This however is a remnant from an earlier version that should have been cleaned up. The state-machine text around Balance, partial claims, and only advancing NextClaimTime when Balance reaches zero arguably permits multiple partial claims inside the same period.

On the other differences, I think your points are mostly fair.

Direct Debit’s LimitAmount + Interval + lsfSingleUse model is more flexible. It can represent fixed recurring billing, card-style per-transaction caps with no aggregate interval, and one-time pull invoices. XLS-78 does not naturally support the latter two.

I also agree that separating AuthorizedAccount from Destination is a meaningful real-world improvement. Processor-pulls-to-merchant is a valid shape, and XLS-78 currently collapses the puller and receiver into the same account. I’d see this as a natural evolution to support both.

Reusing Payment is attractive too, especially because it inherits standard payment semantics and future Payment-level improvements. The trade-off is that pull-payment use of Payment needs very careful constraint handling around paths, partial payments, SendMax, flags, metadata, source remapping, and future amendment interactions. But architecturally, I can see the appeal.

The one XLS-78 semantic that Direct Debit does not currently replicate is the explicit subscription-style accounting model where unused allowance is forfeited at period rollover. I am not yet convinced that belongs in the base primitive, but if subscriptions are being absorbed into this proposal, then that behaviour should either be supported directly or explicitly ruled out.

So, my current view is: Direct Debit may be the better base amendment, with XLS-78’s subscription behaviour either merged into it or defined as a constrained profile of it. The important thing is that we do this collaboratively, avoid splitting effort across two overlapping specs, and make sure the final proposal preserves the use cases XLS-78 was designed to support.

My overarching view would be that we need this type of primitive. Subscription’s already has momentum and support, but if you are prepared to bring this enhanced version to main net, subject to the key features of XLS-78 not being lost, it would have my full support.

Kris

[tadejgolobic]

Hi Kris,
I really appreciate your constructive framing and willingness to converge. So here are my answers on your points:

Regarding the commitment, sure - This is one of the big things that GateHub needs and wants, for both the banking part of the products and the cards part of the product + everything else. And also based on how many GateHub people gave thumbs up to proposal, I don't think that we will have shortage of manpower for implementation of this :) And here, for commitment, I am talking about specification work, xrpld (ex rippled) implementation, client library support,... to get the amendment enabled.

Regarding the preservation of XLS-78 subscription semantics. Ofcourse. The merger should have or incorporate the XLS-78 subscription functionality not as an afterthought, but as a first class. I did have much thought yet on the forfeit-on-arrears behaviour, but my current / quick thinking is to make an explicit opt-in flag on the Authorization object (something like lsfForfeitOnRollover) so XLS-78 functionality can be enabled through this flag. Happy to work through the exact flag surface and default behaviour with you.

I completely agree, regarding the "attribution", that the "merged" / new spec that incorporates also the XLS-78 must explicitly credit XLS-78 as a predecessor and list both you and Denis as co-authors. I am not fan of deleting stuff, just because a broader model absorbs previous one :)

Regarding the "single claim per period" correction - thank you for the clarification. Based on your explanation (and my poor thinking) I must retract when I listed that as a differentiator.

You are also correct regarding the careful constraint handling of Payment transaction. The current draft prohibits SendMax and Paths, blocks both tfPartialPayment and tfLimitQuality, defines a pulled_from_account meta marker,... The constraints around any potential future Payment amendment interactions is just the part where I would really benefit from second pair of eyes.

I am not emotionally attached to the naming. You gave a fair point that Subscriptions is moer intuitive for end users and developers even if it undersells technical scope. I am happy to brainstorm with you the ideas regarding the naming and accept whatever name lands out of that process.

If it is ok with you, I will try and merge XLS-78 into this amendment, send it to you on Matermost and then we can discuss this further in private, and if we are happy with what we created, we can update this spec.

[xrpl365]

This sounds very reasonable, I'll wait to just make sure @dangell7 is also ok with this and if so, let's take this discussion into MM.

[dangell7]

Hey Tadej, Kris,

I don't like reusing Payment because every signing UI, delegation grant, indexer, and accounting pipeline already makes assumptions about the Payment Transactor. I would like wallet teams to weigh in before this is settled.

Direct Debit with limits is a subscription. That is what XLS-78 already specifies, what the branch implements, and, as Kris said on naming, "Subscriptions" is the product people immediately understand and makes the most sense to me.

Kris, you listed one-time pulls as something XLS-78 lacks, and that is true, but the ledger does not lack it. A one-shot deferred pull with a cap, an expiration, and payee-timed settlement is a Check.

On arrears: this is already on our branch, missed periods remain claimable, and the XLS needs updating to say so.

Some months ago I changed it, so there is both drawdown in the current month and you can claim in arrears.

My suggestion: Subscriptions as the spec and the product, absorbing the genuinely new mechanics from this proposal as v2, with full credit. "Direct Debit" is a feature you can enable by creating a subscription that has an interval of 0.

[dangell7]

"Another thing is that XLS-78 collapses Payee and Destination into a single field. Direct Debit keeps them separate. AuthorizedAccount on the Authorization names who is allowed to pull. Destination on the Payment names where will the funds land...."

Subscriptions could still handle this with delegate. Also, the AccountID on the object for DD is immutable so if the merchant ever changes processors you will need to update them all. Delegate wouldn't have this issue.

[mvadari]

Overriding the existing Payment transaction introduces significant ecosystem risks. A dedicated transaction type (e.g., AuthorizationClaim) should be used instead.

A new optional AuthorizationID field is added to Payment. When present, the Payment is a pull payment: the transaction signer is the Payee, but balance and trust-line validation are performed against the Payer named in the referenced Authorization.

This fundamentally changes what a Payment is. For over a decade, the Account field has strictly meant "the signer who initiated the push." Legacy indexers, tax tools, and accounting scripts will miss the new AuthorizationID field entirely, incorrectly logging a merchant pull as a user-initiated push and causing massive reconciliation errors.

The modified Payment transaction behaves identically to its current form when AuthorizationID is absent.

This is not true when it comes to tooling.

Why reuse Payment instead of a new PullPayment transaction? Reusing Payment ensures pull payments inherit standard semantics (fee model, account flags, freezes, RequireAuth checks). It also keeps the amendment surface minimal and avoids duplicating logic across transactors.

This logic is already used across many transactors - e.g. AMMDeposit and Token Escrow already need to process freeze and Deposit Auth checks. Adding another transactor that needs to use these features is not a problem, as there are already a number of helper functions for this logic, and more can be added if needed.

Since this design doesn't use pathing/cross-currency payments, this applies even moreso.

Also, when future amendment touches the Payment, pull payments come along automatically.

This is actually a disadvantage, not an advantage. Given how different pull payments operate from regular payments, you don't want any integration to be happening automatically - you want it to be carefully reasoned about. It's likely that an automatic integration would be incorrect, given how different pull payments are from push payments.

[golobitch]

Hi @dangell7 and @mvadari
Thank you both for the review and feedback. Since some of the things overlap, I decided that I will reply to you both here.

Regarding Payment reuse - after taking into consideration both of your "pushbacks" I concur with you. And yes, the ecosystem already knows how to absorb value moving types that are not Payment like CheckCash, EscrowFinish, PaymentChannelClaim,... I would like to add here one small admission. This specs prohibits SendMax / Paths which were main mechanical benefit of reuse. And I also introduced pulled_from_account metadata field that was just patching around a problem that design itself created :)
So we will have AuthorizationClaim (Payee signs; fields AuthorizationID, Amount, Destination, optional DestinationTag). And I will also rewrite section "Why reuse Payment" to "Why dedicated claim transaction".

@dangell7 on AuthorizedAccount immutability, I need more information there. What do you mean by "delegate"? I can think of two: XLS-75 Permission Delegation where merchant stays the AuthorizedAccount and delegates claim rights to the processor or Off-chain delegation where merchant hands operationsl keys to the processor (Regular Key, SignerList,...)? I personally, don't like off-chain delegation, because in terms of setting regular key, you give access to the wallet for example. I think that both of these addresses your critique, but the specification text and our conversation with you and previous @xrpl365 differ.

Regardless of the answer, I can see some benefits of the underlying point. In that way, AuthorizedAccount will become Payer updatable through AuthorizationUpdate. When I was lookin at SEPA, per my brief check of it, does exactly this. If your intent was XLS-75 then the two composes realy cleanly.

@dangell7 regarding Checks, I partially agree there. As you mentioned, ledger has Checks for one time pull and is payee timed, capped, expiring, single use,... And for the plain one-shot case it is the right tool. However there are some gaps worth mentioning in my opiniont - now I am thinking about some additional fields if we merge both XLS-78 and direct debit - adding StartTime to AuthorizationCreate and to the Authorization ledger object:

• A Check cannot be post dated. If we use StartTime + lsfSingleUse flag, this give us option to do one pull, but not before StartTime
• A Check cannot deliver to third party
• Recurring billing can also be done by creating a Check every month, yet XLS-78 exists because a standing mandate is better primitive than a stream of one shot checks. Here, I would say that same logic applies to the post dated one shot case being a configuration of this mandate rather than the separate object type.

On the arrears, I need the branch semantics before responding properly. I think this is the most consequential technical point in your post and now we have three incompatible description of XLS-78 period accounting in this thread: the published text (single claim per period - Kris flagged that as a remnamt), Kris's description (multiple partial claims, forfeit at rollover) and yours (missed periods remain claimable in arrears). I would say that before doing anything in terms of accounting, can you please write up what the branch actually implements? More specifically, I would like to know

• What accumulates and where? Per period balance or cumulative entitlement?
• Are arrears claims bounded (N periods back) or unbounded since StartTime?
• What happens to unclaimed arrears on cancellation or expiry?

Based on my understanding of everything, I would say that unbounded arrears are absobable into the merged model at zero state cost. Cumulative accounting (TotalDelivered vs windows_elapsed x LimitAmount) is still O(1) and one AMOUNT field would need to be there either way.

Regarding the XLS-78 as a base, this is the only thing where I would push back. A subscription ojbect expresses one shape: anchored periods, per-period allowance. The current proposal (+draft that I have with StartTime in the AuthorizationCreate and Authorization) expresses that as one configuration (LimitAmount + Interval + StartTime, + one accounting flag once arrears discussion is settled) alongside shapes a subscription object doesn't natively express - unmetered per pull cap for card-style programs, one-shot mandates, post-dated pulls, rolling windows. Generalising subscription object to cover everything mentiones meaning that it is growing into exactly what is specced here. That would be same destination, but longer road.

I do need to point out also one small corection: Interval == 0 in the current spec is the unmetered mode (per pull cap, no aggregate) and not "direct debit as a subscription with interval 0". Direct debit / Pull payments is the whole mandate family in this propose and not the zero-interval case.

Regarding naming, I am not emotionally attached to it :) What I am holding is that the ledger object be the general mandate, not the label on the amendment. If the community reads "Subscriptions" better than "Direct Debit" or pull payments or whatever for a mandate primitive, no reservation from my side.

I am open to a call between us, to lock the merge structure after the arrears discussion is locked down.

Please note, I will also update the original spec with draft that I wrote during the end of previous week and during the weekend, that incorporates some of the XLS-78 core functionalities into this one.