VeriFund owns the billing record. Providers execute rails.
R9 separates subscription authority from payment-provider execution so external processors can change without becoming the authoritative subscription system.
Subscription → VeriFund Billing Engine → Provider Adapter
Plans, prices, invoices, payments, entitlements, renewal dates, credits, adjustments, and access state belong to VeriFund. Provider identifiers and execution state are secondary metadata used for processing and reconciliation.
Flexible payment workflows with clear operational controls.
VeriFund supports structured payment workflows designed to help organizations manage financial activity with greater visibility, consistency, and accountability. Available payment methods are clearly identified within the platform, while additional payment integrations are introduced as they become available.
Payment credentials stay out of the platform whenever provider tokenization can carry the risk.
The intended architecture does not intentionally persist raw card PAN/CVV, full bank-account credentials, crypto private keys, or seed phrases. Provider-hosted components and tokenization are preferred where available.
Webhook boundary
Verified provider events are designed to be signature checked, replay protected, persisted, deduplicated, and reconciled before changing authoritative VeriFund state.
Idempotency
Stable idempotency keys and unique settlement references support repeat-safe operations and reduce duplicate state changes.
Reconciliation
The billing core is designed to fetch authoritative provider state and route ambiguous mismatches to manual review rather than granting access from a browser redirect alone.
Separate money domains
VeriFund SaaS billing records remain separate from campaign contribution and campaign-finance ledgers, permissions, reconciliation, and reporting.