Technical Specification
Comprehensive technical documentation of the RetainPay AI platform — an autonomous revenue recovery system for the subscription economy. This document details the system architecture, security model, data schema, and operational workflows.
Domain Ownership & Corporate Identity
RetainPay AI
Autonomous Revenue Recovery for the Subscription Economy
Chief Executive Officer
Peter Kwakpovwe
MSc Data Science, CSPO
Registered Legal Entity
RETAINPAY AI LIMITED · Company No. 17355838
Location
United Kingdom
Sector
FinTech / B2B SaaS / Payments
Domain Ownership Proof
This page serves as verifiable proof that the domain retainpay.online is owned and operated by the proposed RetainPay AI UK Limited, registered through NameCheap LLC and activated on 10 February 2026, under the leadership of Peter Kwakpovwe. This documentation is maintained as part of the Innovator Founder Visa application portfolio.
System Architecture
Frontend Layer
React 18 · TypeScript · Vite · Tailwind CSS
- Single-page application with client-side routing (React Router v6)
- Component library built on Radix UI primitives for accessibility
- Real-time UI updates via TanStack Query with automatic cache invalidation
- Responsive design system with semantic HSL design tokens
- Code-split routes with lazy loading for optimal performance
Backend Layer
Supabase Edge Functions · Deno Runtime · PostgreSQL
- Serverless edge functions for webhook processing and retry execution
- CRON-based scheduler for time-optimised retry attempts
- RESTful API endpoints with automatic OpenAPI schema generation
- Horizontally scalable with zero-downtime deployments
- 99.9% uptime SLA with automatic failover
Data Layer
PostgreSQL 15 · Row-Level Security · Realtime
- Fully managed PostgreSQL with automatic backups and point-in-time recovery
- Row-Level Security (RLS) policies on every table for tenant isolation
- Immutable audit trail — DELETE operations blocked on financial tables
- Real-time subscriptions for live dashboard updates
- Optimised indexes on frequently queried columns (merchant_id, status, created_at)
Security Layer
RLS · RBAC · Encrypted Storage · Webhook Signatures
- Mandatory provider webhook signature verification (HMAC-SHA256)
- API keys encrypted at rest before database storage
- Role-Based Access Control (RBAC) with admin, merchant, and user roles
- Idempotency keys on every retry to prevent duplicate charges
- System-only tables (retry_logs, billing_records) restricted to service role
Database Schema & Security Policies
Core tenant table storing company details, encrypted API keys, and retry settings.
Columns
id, user_id, company_name, encrypted_api_key, stripe_account_id, settings_smart_retries, settings_max_retry_attempts, onboarding_completed
RLS Policies
SELECT/INSERT/UPDATE by authenticated owner · DELETE blocked
Tracks every failed payment with decline analysis, retry scheduling, and recovery status.
Columns
id, merchant_id, stripe_invoice_id, amount, currency, status, decline_code, decline_reason, ai_analysis, ai_recommended_retry_time, retry_count, scheduled_for, recovered_at
RLS Policies
SELECT by merchant owner · INSERT/UPDATE by system · DELETE blocked
Immutable audit log of every retry attempt with full payment provider responses.
Columns
id, transaction_id, merchant_id, attempt_number, status, error_message, stripe_response, executed_at
RLS Policies
SELECT by merchant owner · All writes restricted to service role
Monthly billing records tracking recovered revenue, fee calculations, and invoice references.
Columns
id, merchant_id, period_start, period_end, recovered_total, fee_percentage, fee_amount, status, stripe_invoice_id
RLS Policies
SELECT by merchant owner · All writes restricted to service role
RBAC table mapping users to roles. Modifications restricted to admin users only.
Columns
id, user_id, role (admin | merchant | user)
RLS Policies
SELECT by authenticated · INSERT/UPDATE/DELETE by admin only
Edge Functions & Business Logic
Ingests Stripe and Adyen payment-failure notifications, verifies signatures, creates transaction records, and triggers retry-timing analysis.
HMAC-SHA256 signature verification · Idempotency key deduplication
CRON-scheduled function that queries pending retries, executes them through the originating provider with unique idempotency keys, and updates transaction status with full audit logging.
Service role only · Idempotency keys · Rate limiting
Security Model
Tenant Isolation
Every database query is scoped to the authenticated user's merchant via RLS. No cross-tenant data access is possible.
Immutable Audit Trail
DELETE operations are blocked on merchants, transactions, retry_logs, and billing_records tables to maintain regulatory compliance.
Encrypted Credentials
Payment provider credentials are encrypted before storage. Keys are never logged or exposed in API responses.
Webhook Verification
Every inbound provider notification is signature-verified before processing. Invalid signatures are rejected.
Idempotency Protection
Every retry attempt uses a unique idempotency key to prevent duplicate charges, even in case of network failures.
RBAC Enforcement
Role modifications are restricted to admin users via security-definer functions, preventing privilege escalation.
Product Demo — End-to-End Workflow
The following walkthrough demonstrates the complete lifecycle of a failed payment recovery, from initial detection through to successful recovery and billing. This represents the core value proposition of RetainPay AI.
Merchant Onboarding
A SaaS business signs up, provides company details, and connects Stripe, Adyen, or both using restricted provider credentials. The system creates a merchant record and assigns the 'merchant' role via RBAC.
Merchant dashboard becomes active with real-time monitoring.
Payment Failure Detection
When a subscription payment fails, the connected provider sends a signed notification. The system verifies the signature, deduplicates the event, and creates a transaction record with full decline analysis.
Transaction appears in dashboard as 'pending' with decline code analysis.
AI-Powered Retry Scheduling
The AI engine (Claude 3.5 Sonnet) analyses the decline code, BIN data, transaction history, and banking hours to determine the optimal retry window. The system schedules the retry for maximum approval probability.
Transaction status changes to 'scheduled' with predicted retry time.
Automated Retry Execution
The CRON scheduler picks up due retries, executes them through Stripe or Adyen with unique idempotency keys, and logs every attempt in the immutable retry_logs table. If successful, the transaction is marked 'recovered'.
Revenue recovered automatically. Full audit trail preserved.
Reporting & Billing
The dashboard provides real-time analytics: recovery rate, total recovered, pending amounts, and trend analysis. Monthly billing records are generated with transparent fee calculations.
Merchant sees ROI immediately. Billing is usage-based and transparent.
Interactive Demo — Chrono-Retry Engine
Experience RetainPay's AI-powered retry scheduling in real time. Select a decline scenario below and watch the Chrono-Retry Engine determine the optimal retry window — demonstrating genuine intelligence over static "+24 hour" logic.
Simulate Failed Payment
Card issuer declined without specific reason
AI Verdict
Configure a scenario and run the analysis to see the AI recommendation.
Innovation & Market Differentiation
AI-Optimised Timing
Unlike rule-based competitors, RetainPay uses machine learning to predict the optimal retry window based on decline codes, BIN data, and historical patterns.
Low-Integration Setup
Merchants connect Stripe or Adyen with restricted credentials and a signed webhook — no change to their existing billing system.
Immutable Financial Audit
Every transaction and retry attempt is logged in an append-only audit trail, meeting regulatory requirements for financial services.
Success-Based Pricing
Merchants only pay when revenue is actually recovered. This aligns incentives and removes upfront risk for adoption.