Skip to content

[Pr.2.1.c] As a payer, I should be able to pay one or multiple request safely - via a self hosted (IPFS) front end preventing contract spoofing for subscription transactions #142

@tristanwallaert-netizen

Description

This user story extends the IPFS-secured payment enclave already validated for same-chain execution under [Pr.2.1.a] and cross-chain execution under [Pr.2.1.b] by adding subscription payment support. The enclave is now able to securely orchestrate recurring payment executions using the same deterministic, verifiable payment page, while preserving all previously validated security guarantees. Subscription payments reuse the same trusted smart contract allowlist and enclave integrity model, ensuring that recurring executions remain safe, predictable, and non-spoofable over time.

As a payer, I want my subscription payments to be executed through the same secured payment enclave used for one-off payments, so that the security guarantees remain identical across payment types.

As a payer, I want each subscription payment execution to be restricted to known and trusted smart contracts, using the same enclave protections validated in [Pr.2.1.a] and [Pr.2.1.b], so that recurring payments cannot be redirected maliciously.

As a payer, I want to clearly understand the execution steps of a subscription payment, including approval, execution, and validation, so that I know what I am authorizing for both the initial setup and each recurring charge.

As a payer, I want to be able to trust the subscription payment flow even if the originating platform or Request Network infrastructure were compromised, relying on the enclave’s integrity guarantees.

As a payer, I want to be redirected back to the platform or application where I initiated the subscription after each payment execution or failure, so that the subscription experience remains continuous and controlled.

As a payer, I want the enclave to automatically apply the appropriate execution path for each subscription cycle, without requiring additional actions from me, so that recurring payments remain seamless over time.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    Status

    No status

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions