SmartPayEngine
AI-native financial infrastructure
Payments. Intelligence. Control.
An intelligent financial operating layer for payments, multi-currency operations, merchant finance, risk, settlement, reconciliation and payment automation.
What SmartPayEngine is
SmartPayEngine is an AI-native financial infrastructure platform: intelligent payments, multi-currency financial operations, merchant infrastructure, ledger integrity, reconciliation, settlement, risk and operational control in one architecture. It runs today in sandbox/test mode as a technology foundation on which an appropriately licensed, operator-led production financial product can be built. Built solo by a founder-engineer; pre-revenue, with no live production payment volume.
The financial operating layer
Money moves through a defined sequence of components. Each layer is a real part of the codebase, not a marketing abstraction.
Payments
01Payment intents, payment links, QR and merchant-initiated flows.
Transaction engine
02Currency-aware transaction records with controlled state transitions.
Ledger
03Double-entry balances; mutations only through controlled operations.
Risk
04Transaction oversight, risk signals and account-level controls.
Reconciliation
05Matching of transactions, fees and settlement records.
Settlement
06Settlement and payout records tied back to ledger entries.
Merchant operations
07Balances, invoices, refunds, disputes and fees for merchants.
Administrative control
08Role-based administration, audit logging and privileged operations.
An intelligence layer across the financial platform
AI is used to read, explain and score financial activity. It does not make autonomous financial decisions — every money-moving action requires an operator.
Payment intelligence
Natural-language querying of payments, balances and transaction history with full account context.
Transaction analysis
The assistant reads transaction and ledger records to explain what happened on a given payment.
Financial intelligence
Balances, settlement and reconciliation state summarised in plain language for finance and operations teams.
Operational intelligence
Plain-language summaries of dispute, settlement and reconciliation state for operators.
Risk signals
Model-driven scoring of transaction and merchant risk beyond current rule-based checks.
Payment routing
Intelligence-led routing across multiple processors and corridors.
Merchant insights
Portfolio-level analytics and anomaly detection across merchant accounts.
Financial operations automation
Assisted execution of routine reconciliation and payout workflows.
Multi-currency by design
The data model treats currency as a first-class property of every balance, transaction and ledger entry. USD, EUR and GBP are supported in the sandbox build today; no other currencies or live corridors are offered. FX in the sandbox uses fixed constants — it is not live market execution.
- Multi-currency balances held natively per account
- Currency conversion workflows with quote, rate and fee breakdown
- Cross-currency transaction architecture with paired ledger entries
- Currency-aware transaction records end to end
- Payment routing structured for additional corridors
- Global-payment infrastructure readiness — new currencies are configuration, not a rewrite
A merchant financial command center
One operational surface for everything a merchant finance team touches — rather than a dashboard bolted onto a payments API.
All modules operate against sandbox data
Ledger integrity at the core
Balances are derived from a double-entry ledger with append-only protections. Every movement of value is recorded, changeable only through controlled operations, and reconcilable after the fact. This is a conventional double-entry database ledger — not blockchain or distributed-ledger technology.
- Append-only ledger protections — entries are added, never edited in place
- Ledger-based balances — no balance field is written directly
- Controlled balance mutations through defined transaction operations
- Transaction records carrying currency, state and reference IDs
- Auditability: every balance change traces back to paired entries
- Reconciliation between transactions, fees and settlement records
- Settlement records linked to the payouts they represent
- Refund and dispute workflows modelled as first-class state machines
Risk & financial control
Controls implemented in the current build. Risk tooling is operator-assisted, not autonomous.
Risk monitoring
Transaction-level checks surface unusual activity to operators for review.
Fraud operations
Case handling for suspected fraudulent payments and disputed transactions.
Transaction oversight
Full transaction history with state, currency and originating account.
Account controls
Account status controls that gate what an account can initiate.
Administrative controls
Privileged administrative operations separated from merchant-facing actions.
Operational alerts
Notification and email-delivery logging for operationally significant events.
Audit logs
Record of administrative and financial operations for after-the-fact review.
Role-based access
Roles held in a dedicated table and evaluated server-side, never from the browser.
Financial control at the infrastructure layer
Controls are enforced beneath the interface, in the transaction path and the database — and administered from a dedicated Financial Controls console.
PIN enforcement
Financial actions require PIN confirmation before they are executed.
Per-transaction limits
Ceilings applied to the value of any single transaction.
Daily amount limits
Cumulative daily value caps enforced per account.
Daily count limits
Caps on how many transactions an account may initiate in a day.
Velocity controls
Rate-based checks that catch bursts of activity outside normal patterns.
Kill switches
Operational switches that halt classes of financial activity immediately.
Database-level authorization
Role-based access enforced in the data layer, not only in the interface.
Audit trails
Administrative and financial operations are recorded for after-the-fact review.
Control changes are themselves recorded in the audit trail
One place to watch the financial platform
Administrators monitor operational exceptions across the platform from a single console, rather than moving between disconnected screens. Every area below is an existing part of the build, operating on sandbox data.
Reversal monitoring and audit
Reversal handling in the current build is read-only and observational: reversal events can be monitored and audited, with their ledger effects traceable. SmartPayEngine does not execute automatic or autonomous reversals. Refunds and disputes are the transaction-recovery workflows implemented today.
Monitor
Reversal events are surfaced in the Operations Center as they occur in the sandbox.
Audit
Each event carries its record trail, so its ledger effect can be explained after the fact.
Recover
Refund and dispute workflows are the implemented paths for recovering a transaction.
Infrastructure to build financial products on
A typed API surface, a clean-architecture backend and a documented data model — designed to sit underneath another company's financial product.
Built for integration
- ASP.NET Core 8 backend organised in clean-architecture layers
- React 19 · TypeScript · TanStack Start SSR frontend
- Supabase Postgres schema with versioned migrations
- Server-side validation on every public endpoint
- Webhook processing with signature verification
- Capacitor Android project wrapping the web app
Applicable product categories
Digital assets are listed as a potential integration for the infrastructure only. SmartPayEngine does not provide cryptocurrency custody, exchange, brokerage or investment services.
Technology & PlatformBuild. Test. Integrate.
Every environment SmartPayEngine currently runs is a sandbox. Transactions, balances, settlements and disputes are simulated records produced by test flows and seed data — they are not production financial activity and carry no monetary value.
- Simulated transactions and balances
- Test-mode processor credentials
- Seed merchants and cases
- No customer funds at risk
- Requires licensing or a sponsoring PSP
- Requires live processor agreements
- Requires compliance and audit programme
- Operator-led, not provided today
Stripe, integrated in test mode
SmartPayEngine integrates Stripe using test-mode credentials only. There is no live Stripe processing, and no real card payments have been taken.
Test / sandbox infrastructure · no live processing
The USD, EUR and GBP flows, as they run today
Screens from the sandbox build. All amounts, customers and cases are simulated seed data — no production merchant traffic is shown.
USD payments dashboard
- USD balance with settled and pending payment states
- Payment volume charted per day across the sandbox ledger
- Every row is double-entry backed and traceable to a payment ID
Sandbox environment · simulated data
EUR → USD conversion workflow
- Quote, rate, and full fee breakdown before the conversion is confirmed
- Separate native balances held for EUR, GBP, and USD
- Conversions post to the ledger as paired debit/credit entries
Sandbox environment · simulated data
GBP dispute case
- Dispute case view with its full record trail
- Step-by-step timeline from chargeback receipt to decision
- Assistant explains the case in plain language with full context
Sandbox environment · simulated data
Built with financial control in mind
An honest statement of the platform's current security posture — implemented controls on one side, gaps on the other.
Controls implemented today
- Authentication with session handling, and administrative access separated from merchant access.
- Role-based access control with roles held in a dedicated table and evaluated server-side — never from client storage.
- Row Level Security enabled on every database table.
- Privileged operations restricted to server-side execution with secrets held outside the browser bundle.
- Audit logging of administrative and financial operations, plus email-delivery logging.
- Financial record protection: balances change only through controlled double-entry ledger operations.
- Strong HTTP security headers on every response: Content-Security-Policy, HSTS (2 years, preload), X-Frame-Options DENY, X-Content-Type-Options, Referrer-Policy, Permissions-Policy and Cross-Origin-Opener-Policy.
- Server-side validation on all public endpoints, with client-side validation and length limits on every form.
Not in place yet
- No independent penetration test or third-party security audit has been performed.
- No SOC 2, ISO 27001 or PCI-DSS certification — card data is never handled in the sandbox.
- Not licensed or registered as a payment institution in any jurisdiction.
- Multi-factor authentication is available through the identity layer but is not yet enforced platform-wide.
- No formal incident-response, on-call or disclosure programme yet.
- Sandbox data is simulated seed data; there is no production customer data today.
Taking SmartPayEngine to production requires a penetration test, a compliance programme, and the relevant licensing or a sponsoring PSP relationship.
What exists, stated plainly
No transaction volume, revenue, customer counts or performance figures are shown, because none exist. This is what the codebase and sandbox provide today.
Platform capabilities
- Payments, invoices, links and QR
- Multi-currency balances (USD · EUR · GBP)
- Refunds, disputes and reversal monitoring
- Settlements, payouts and fees
Architecture
- Double-entry ledger core
- Clean-architecture .NET 8 backend
- TanStack Start SSR frontend
- Versioned Postgres migrations
Security controls
- Row Level Security everywhere
- Server-side RBAC
- Audit logging
- Hardened HTTP security headers
Sandbox readiness
- Seeded merchants and cases
- Stripe test-mode integration
- End-to-end simulated flows
- Ready for technical due diligence
For builders, operators and acquirers
For developers evaluating the stack
- Full sandbox APIs
- Conversational intelligence layer
- Community support
For operators piloting the infrastructure
- USD, EUR and GBP support
- Merchant command center
- Ledger, risk and settlement modules
- Android build
- Priority support
For acquirers & strategic operators
- Full source & IP transfer
- Rebrand & deploy
- Advisory transition period
- Complete due-diligence package
Due diligence, plainly stated
What a SmartPayEngine acquisition or partnership includes, and what further materials are available on request.
Included in the sale
- Full source code (frontend + .NET 8 backend)
- All IP, brand assets, and the SmartPayEngine mascot
- smartpayengine.com domain
- Capacitor Android project and build configuration
- Supabase schema, migrations, and server functions
- Technical documentation and setup guides
Tech stack
- Frontend: React 19, TypeScript, TanStack Start (SSR)
- Backend: ASP.NET Core 8 (Clean Architecture)
- Data: Supabase Postgres + double-entry ledger
- AI: Anthropic API (Claude), server-side
- Mobile: Capacitor Android project
- Testing: Vitest, Playwright, xUnit
Current stage
- Functional platform, sandbox-only
- Pre-revenue, no live payment volume
- Not licensed as a payment institution
- Suitable for pilots, white-label, or asset acquisition
Available on request
- Architecture and data-model walkthrough
- Repository access with commit history
- Live technical Q&A with the founding engineer
- Deployment / hand-over plan
Request the technical pack
Tell us who you are. Every request is reviewed personally, and the buyer pack is emailed only once the request is approved — architecture, security summary, sandbox status, digital assets and current operating status.
A financial technology foundation, ready for an operator
SmartPayEngine's architecture is designed to support fintech products, embedded finance, payment infrastructure, merchant financial services, cross-border payments, financial marketplaces and — with the appropriate permissions — future regulated financial products. The platform is available for partnership or acquisition by an operator able to take it into production.
Payments. Intelligence. Control.
Explore the platform, review the architecture, or enter the sandbox.