> ## Documentation Index
> Fetch the complete documentation index at: https://docs.useabyss.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Merchant Payments and Transaction History Minimization.

> Explains how Abyss enables private, compliant payments by eliminating counterparty access to historical financial data.

A core real-world failure of public blockchains is that **payments expose far more information than necessary**. In standard on-chain transfers, a merchant receiving funds immediately gains visibility into the payer’s full transaction history, balance patterns, counterparties, and behavioral signals. This is not required for settlement. It is an artifact of address-based accounting.

Abyss replaces this model with **proof-based payment authorization**.

In an Abyss-mediated payment, the merchant does not receive funds from a long-lived account. They receive funds from a **withdrawal event** that is cryptographically valid but historically unlinked. The merchant learns exactly three things:

1. That they were paid
2. The amount paid
3. The asset received

They do not learn:

* The payer’s balance
* The payer’s prior transactions
* The payer’s identity graph
* Whether the payer has interacted with the merchant before

This is information minimization by design.

### VI.2.1 Payment Flow Abstraction

A typical Abyss payment flow can be represented as:

```
User Deposit → Privacy Pool → ZK Withdrawal → Merchant Address
```

At no point does the merchant interact with the user’s deposit address. The withdrawal may be executed by the user, a relayer, or even the merchant themselves if delegated credentials are provided.

This enables multiple payment models:

* One-time checkout payments
* Invoice-based settlement
* Subscription withdrawals
* Programmatic payouts

All without account reuse.

### VI.2.2 Delegated Withdrawal Credentials

Because withdrawal authorization is credential-based, users may issue **limited-scope withdrawal keys** to merchants or applications:

```
withdrawal_key_i := H(secret_key || i)
```

Each key authorizes a bounded withdrawal and is consumed on use. This mirrors cash-like behavior without shared custody or persistent access.

Merchants do not hold balances. They hold **rights to withdraw a specific amount once**.

### VI.2.3 Compliance Implications

From a compliance standpoint, this model is superior to address-based payments. Merchants can:

* Prove receipt of funds
* Record transaction amounts
* Maintain auditable books

Without storing sensitive customer financial histories. Data minimization reduces liability, breach impact, and regulatory exposure.

### VI.2.4 Economic Consequences

By removing history leakage, Abyss enables:

* Safer consumer payments
* Merchant adoption without privacy risk
* On-chain commerce that resembles real-world norms

Privacy here is not adversarial. It is **functional**.

***