Recurring Payment Engine

The AlgoVoi recurring payment engine handles two distinct recurring-payment patterns, each with its own protocol and customer UX. Both tiers run on the same gateway and share the same mandate lifecycle model. Customer self-serve portal: recurr.algovoi.co.uk

Tier 1 — MPP subscription invoicing

Tier 1 uses the MPP protocol to issue scheduled payment invoices. The merchant creates a subscription schedule; AlgoVoi generates invoices on the configured cadence; the customer pays each invoice from their wallet.

Customer portal

The portal at recurr.algovoi.co.uk gives customers a single view of every subscription across every merchant — no email, no password. Authentication is Sign-In-with-Wallet: the wallet address is the identity.

One portal, one wallet connection, every merchant
Cancel or view upcoming invoices without contacting the merchant
Single-use cancel links (/recurr/cancel/{secret}) can be embedded in emails
AlgoVoi never holds the customer’s keys or funds

Protocol

Field	Value
Protocol	MPP (`paymentauth.org/mpp`)
Auth pattern	Sign-In-with-Wallet (challenge/verify)
Invoice cadence	Daily / weekly / monthly (tenant-configured)
Customer scope	`recurr.customer` JWT, sub = wallet address

Chains

All 7 chains are wired. Algorand, VOI, Solana, and Stellar are fully funded for live execution. Base and Tempo require hot-wallet funding before live pulls are enabled.

Tenant API

POST  /v1/subscriptions                  create subscription schedule
GET   /v1/subscriptions                  list
GET   /v1/subscriptions/{id}             get
PATCH /v1/subscriptions/{id}             update
POST  /v1/subscriptions/{id}/cancel      cancel
GET   /v1/subscriptions/{id}/invoices    invoice history

Tier 2 — Standing-authority pull payments

Tier 2 implements PSD2-aligned standing authorities. The customer signs a one-time authorisation granting the platform permission to pull up to a capped amount on a recurring schedule. The executor pulls automatically — no per-payment customer interaction after the initial sign.

Lifecycle

created → active → paused ⇄ active → revoked
                         ↘ errored → revoked

The customer signs the spending-cap vault transaction on-chain during the created → active confirmation step. From that point, the executor pulls at the configured interval without further customer input.

Authority API

POST  /v1/recurring/authorities                  create + return customer-signing payload
GET   /v1/recurring/authorities                  list (filter by subscription_id, status)
GET   /v1/recurring/authorities/{id}             get
POST  /v1/recurring/authorities/{id}/confirm     mark active after on-chain landing
POST  /v1/recurring/authorities/{id}/revoke      revoke (active / paused / errored)
POST  /v1/recurring/authorities/{id}/pause       pause (active → paused)
POST  /v1/recurring/authorities/{id}/resume      resume (paused → active)
POST  /v1/recurring/pulls                        trigger manual pull (operator)

Chain support

Chain	Vault type	Status
Algorand	`algorand_spending_cap_vault_v1` (spending-cap box)	Live
VOI	`algorand_spending_cap_vault_v1` (AVM-compatible)	Live
Solana	EVM-equivalent authority	Live
Base	EVM USDC approve	Hot wallet required
Tempo (ARC)	EVM USDC approve (18dp precompile)	Hot wallet required

SDK integration

The customer-signing payload returned by POST /v1/recurring/authorities is interchangeable with the SDK chain providers. Both sides stay shape-equivalent — the e2e suite asserts parity.

pip install algovoi-python-sdk   # Python
npm install @algovoi/sdk         # TypeScript / Node

See Native SDKs for full SDK documentation.

Get started

Platform

Concepts

Keystone

Substrate 2

Commercial

Open substrate

Payment protocols

Chains

Integrations

Help

Company

Tier 1 — MPP subscription invoicing

Customer portal

Protocol

Chains

Tenant API

Tier 2 — Standing-authority pull payments

Lifecycle

Authority API

Chain support

SDK integration

See also

​Tier 1 — MPP subscription invoicing

​Customer portal

​Protocol

​Chains

​Tenant API

​Tier 2 — Standing-authority pull payments

​Lifecycle

​Authority API

​Chain support

​SDK integration

​See also

Tier 1 — MPP subscription invoicing

Customer portal

Protocol

Chains

Tenant API

Tier 2 — Standing-authority pull payments

Lifecycle

Authority API

Chain support

SDK integration

See also