Name of the project
FluxPay
Problem statement in the existing Conflux ecosystem and the proposed solution
A major gap in the current Conflux ecosystem is the lack of simple, merchant-ready payment infrastructure for teams that want to accept on-chain payments without building checkout flows, payment verification, webhook automation, settlement handling, and merchant tooling from scratch.
Today, a developer can build on Conflux, but turning that into a usable merchant payment experience still requires a lot of custom work:
- generating payment links,
- building checkout UX,
- verifying payments reliably,
- managing expirations and retries,
- reconciling transactions with merchant systems,
- handling fragmented assets and network choices.
FluxPay solves this by providing a hosted crypto checkout and payment infrastructure layer for Conflux eSpace. It lets merchants and developers:
- create one-time or reusable payment links,
- accept stablecoin payments,
- verify payments server-side,
- trigger webhooks for business automation,
- integrate checkout using an SDK.
The long-term vision is broader: make Conflux the settlement layer for merchant payments even when users pay from different supported tokens and supported networks. Over time, FluxPay will evolve to:
- support payment in multiple supported tokens while the merchant receives a preferred stablecoin,
- automatically swap the payer’s asset into the merchant’s settlement asset,
- allow users from any supported network where USDT0 is available to pay,
- use Conflux as the final settlement chain for merchants,
- support recurring billing and more advanced payment workflows.
This turns FluxPay from a checkout product into a merchant-friendly payment abstraction layer for the Conflux ecosystem.
Alignment of the project with the Conflux Network
FluxPay is built around Conflux eSpace payment flows and is designed to make Conflux more practical for real merchants, applications, and stablecoin-based transactions.
It aligns with Conflux by:
- increasing the utility of assets like USDT0,
- making merchant payments easier to integrate,
- helping ecosystem apps monetize directly on-chain,
- reducing the barrier for developers who want payment infrastructure on Conflux,
- positioning Conflux as a settlement environment for broader merchant activity.
A particularly important long-term direction is enabling users to pay from multiple supported networks while settlement happens on Conflux. That makes Conflux more valuable not just as an application chain, but as a merchant settlement layer.
Benefit to the Conflux Ecosystem
FluxPay can entice more developers to build on Conflux because it removes one of the most repetitive product layers in crypto: payments.
Instead of rebuilding custom logic for:
- payment creation,
- checkout,
- verification,
- status updates,
- webhook delivery,
- merchant reconciliation,
developers can plug into a reusable infrastructure layer.
This makes Conflux more attractive for:
- SaaS products,
- merchant apps,
- subscription businesses,
- invoicing tools,
- marketplaces,
- consumer apps that need stablecoin checkout.
As FluxPay expands to support token abstraction and cross-network entry, it can reduce one of the hardest problems in crypto payments: forcing customers to already have the exact asset on the exact network the merchant wants.
Economic benefit
FluxPay can increase assets and transactions on-chain by making Conflux the chain where merchant payment settlement happens.
In the short term, it can drive:
- more stablecoin payment volume,
- more repeated merchant transactions,
- more hosted checkout usage,
- more payment-related Conflux eSpace activity.
In the longer term, FluxPay can increase economic activity even more by enabling:
- payment in arbitrary supported tokens,
- automatic swap into merchant-preferred stablecoin,
- cross-network user entry wherever USDT0 is supported,
- final settlement on Conflux,
- recurring and subscription-based on-chain payment flows.
This creates a path toward:
- more stablecoin settlement volume on Conflux,
- more merchant-driven network activity,
- more real-world usage of Conflux beyond speculative transfers,
- stronger demand for ecosystem payment infrastructure.
Demonstrated competitive edge
FluxPay’s competitive edge is that it is not just a simple payment UI or contract demo.
It combines:
- hosted checkout,
- merchant dashboard,
- reusable payment links,
- webhook automation,
- developer SDK,
- a roadmap toward token abstraction and Conflux-based settlement.
That makes it more useful than a basic demo and more practical than forcing each Conflux team to build its own payment system from scratch.
Its strongest differentiator is the merchant-first abstraction model:
- the user can pay with a supported asset,
- the system handles the complexity,
- the merchant receives the preferred stable settlement asset,
- Conflux remains the settlement chain.
Links to the projects webpage, DApp, socials and chat groups
- GitHub: https://github.com/hexdee/fluxpay
- Demo: https://fluxpay-demo.vercel.app
- Backend/API: https://fluxpay-7f5a.onrender.com
- SDK: https://www.npmjs.com/package/fluxpay-checkout-sdk
Conflux eSpace grant recipient wallet address
0x78086a834b6fa4D716a52A0F3Fb451a9DAB4138c
Are you an incorporated startup?
No
Technical Introduction
Functional goals of the system
FluxPay is intended to provide a complete payment flow for merchants and developers on Conflux eSpace.
Current functional goals:
- create payment requests,
- generate checkout links,
- support one-time and reusable payment flows,
- provide hosted checkout UX,
- verify payment completion,
- emit webhook events,
- support developer integration through an SDK.
Future functional goals:
- support payment in multiple supported tokens,
- allow the merchant to receive stablecoin settlement,
- automatically swap payment assets,
- allow users to enter from any supported network where USDT0 is available,
- use Conflux as the final settlement chain,
- support gasless or gas-abstracted checkout flows where feasible,
- support subscriptions, recurring billing, and more advanced payment models,
- provide embeddable checkout components and SDKs in more languages.
Existing solutions and feasibility study
There are broader crypto payment products in the market, but most are not tailored to Conflux and do not directly focus on Conflux-native merchant checkout workflows.
Most existing alternatives fall into one of these categories:
- generic crypto payment gateways without Conflux focus,
- low-level contract tooling without hosted merchant UX,
- wallet-oriented products rather than developer-first merchant checkout infrastructure.
FluxPay is feasible because the MVP already exists and is publicly deployed. The current implementation already demonstrates:
- merchant-facing UI,
- checkout flows,
- backend/API structure,
- SDK packaging,
- public demo deployment.
This proposal is therefore about extending and hardening an existing product, not starting from zero.
Purpose of the system
The purpose of FluxPay is to become reusable payment infrastructure for the Conflux ecosystem.
It should help developers and merchants accept stablecoin payments on Conflux without rebuilding the same payment stack repeatedly.
Scope of the system
Current scope:
- hosted checkout,
- payment creation,
- one-time and reusable payment links,
- merchant payment management UI,
- payment verification,
- webhook support,
- checkout SDK.
Expanded scope with grant support:
- multi-token checkout with merchant stablecoin settlement,
- automatic swap flow during checkout,
- cross-network payment entry where USDT0 is supported,
- Conflux as the settlement chain for merchant payments,
- gasless or gas-abstracted checkout support where feasible,
- embeddable checkout widget/components,
- better webhook reliability and observability,
- improved SDK and integration docs,
- subscriptions / recurring billing / streaming-style payment architecture.
Objectives and success criteria
Main objectives:
- make stablecoin checkout on Conflux easier for developers,
- make merchant payment collection easier on Conflux,
- provide reusable infrastructure instead of one-off demos,
- drive real Conflux payment activity,
- position Conflux as a settlement layer for merchant payments.
Additional long-term objectives:
- allow merchants to define a preferred settlement asset,
- allow customers to pay with more flexible supported assets,
- reduce friction caused by token and network fragmentation,
- expand FluxPay from checkout infrastructure into cross-network payment abstraction,
- support recurring merchant monetization use cases.
Success criteria:
- stable mainnet-ready payment flow,
- documented integration flow for developers,
- reliable webhook-based automation,
- pilot usage by external developers or merchants,
- measurable Conflux payment activity through FluxPay.
Later-stage success criteria:
- successful swap-assisted checkout flow,
- stable settlement into merchant-preferred stablecoin,
- support for users entering from multiple supported networks,
- measurable increase in Conflux settlement activity through FluxPay,
- successful recurring billing flows for merchants.
Definitions, acronyms, and abbreviations
- SDK: Software Development Kit
- API: Application Programming Interface
- UI: User Interface
- UX: User Experience
- MVP: Minimum Viable Product
- USDT0: stablecoin asset used in FluxPay checkout positioning
- PR: Pull Request
References
- GitHub repository: https://github.com/hexdee/fluxpay
- Demo: https://fluxpay-demo.vercel.app
- Backend/API: https://fluxpay-7f5a.onrender.com
- SDK package: https://www.npmjs.com/package/fluxpay-checkout-sdk
Technical Proposal
Functional overview of the system
FluxPay currently has four main layers:
1. Merchant application
This allows merchants to:
- create payments,
- generate one-time or reusable links,
- manage payment records,
- configure checkout behavior,
- manage workspace settings.
2. Hosted checkout
This is the customer-facing payment surface where users:
- review payment details,
- complete stablecoin payments,
- receive success or expired states.
3. Backend/API
The backend handles:
- payment creation,
- verification,
- expiration handling,
- webhook delivery,
- merchant orchestration.
4. SDK
The SDK helps external apps integrate FluxPay checkout more easily.
Core aspects of the system and elements to uphold functionality
Current core system elements:
- payment creation API,
- hosted checkout renderer,
- payment link generation,
- transaction verification,
- webhook generation and delivery,
- merchant settings,
- SDK integration layer.
Future core system elements:
- token-agnostic payment initiation,
- automatic swap execution into merchant settlement asset,
- settlement routing toward Conflux,
- cross-network payment entry for supported USDT0 environments,
- merchant-side stablecoin settlement guarantees,
- unified payment status across multi-step cross-network flows,
- gas abstraction where feasible,
- recurring billing and subscription state management,
- embeddable checkout components for third-party apps.
Legal / licensing aspects
At this stage, FluxPay is positioned as an open developer-facing infrastructure project. Licensing choices will remain compatible with developer adoption and ecosystem usage.
No special legal structure is required for the MVP itself, but merchant-facing production expansion may later require clearer compliance and operating policies depending on the specific payment use case and jurisdiction.
Non-functional overview
Usability
FluxPay is designed to reduce friction for two user groups:
- merchants, who need a straightforward dashboard and checkout creation flow,
- developers, who need clean APIs, SDK setup, and webhook support.
It emphasizes:
- simple checkout UX,
- clear payment states,
- minimal setup for common use cases,
- clean product-oriented flows rather than hackathon-only interactions.
Reliability
Reliability is critical for payment infrastructure. FluxPay needs:
- stable verification,
- reliable webhook delivery,
- safe expiration handling,
- consistent payment state management,
- resilience across retry and failure scenarios,
- strong handling for multi-step cross-token and cross-network flows.
Grant support will help improve:
- webhook retries,
- observability,
- error handling,
- cross-flow consistency,
- operational resilience.
Performance
The system should provide:
- fast checkout link generation,
- responsive merchant UI,
- low-latency API responses,
- efficient verification and webhook processing,
- scalable handling for more complex settlement paths.
Implementation
FluxPay is implemented as a multi-layer product with:
- frontend,
- backend,
- contracts,
- SDK,
- documentation.
It is already live in public MVP form and can now be advanced toward broader ecosystem adoption.
User interface
The UI includes:
- merchant dashboard,
- payment creation flow,
- payment links management,
- payment details,
- webhook tooling,
- API key management,
- customer checkout,
- success and expired states.
Future UI additions include:
- embedded checkout components,
- improved settlement visibility,
- recurring billing flows,
- richer developer tooling for cross-token and cross-network payments.
Total Budget
Grant Size
$10,000
Justification
1. Multi-token checkout and merchant settlement — $2,500
- support multiple supported payment assets,
- merchant-preferred settlement asset logic,
- swap-assisted checkout flow,
- quote and settlement UI/API support.
2. Cross-network payment entry and Conflux settlement routing — $2,500
- supported multi-network payment entry,
- settlement routing toward Conflux,
- payment state tracking across multi-step flows,
- backend orchestration for unified merchant settlement.
3. Gasless checkout and embeddable components — $2,000
- gas abstraction support where feasible,
- embeddable checkout widget/components,
- improved SDK and frontend integration support,
- better checkout conversion and developer usability.
4. Recurring billing / subscriptions / streaming-style payment architecture — $3,000
- recurring payment plans,
- subscription lifecycle management,
- recurring event handling,
- streaming or scheduled continuous-payment foundations,
- dashboard support for recurring revenue workflows.
Development Roadmap
Milestone 1 — Multi-token checkout with merchant stablecoin settlement
Timeline: 4 weeks
Requested funding: $2,500
Major achievement
Allow customers to pay with multiple supported tokens while the merchant receives settlement in a preferred stablecoin.
Deliverables
- support payment in more than one supported token,
- merchant can define preferred settlement asset,
- automatic swap flow into merchant settlement stablecoin,
- updated checkout UI showing payer asset, settlement asset, and final quote,
- backend support for quote generation, verification, and settlement state tracking,
- SDK/API updates for multi-token payment creation.
Secondary work
- improve validation and edge-case handling for payment creation,
- improve quote and settlement error reporting,
- improve docs for multi-token checkout setup.
Milestone 2 — Cross-network payment entry with Conflux as settlement chain
Timeline: 4 weeks
Requested funding: $2,500
Major achievement
Allow users from any supported network where USDT0 is available to initiate payment, while Conflux remains the final settlement chain for the merchant.
Deliverables
- cross-network payment flow design and implementation,
- routing logic for supported network entry points,
- Conflux-based final settlement flow,
- unified payment state tracking across source network and settlement completion,
- merchant-side settlement abstraction so the merchant sees one consistent payment result,
- clear checkout UX for source network, route, and settlement status.
Secondary work
- improve observability for cross-network transactions,
- improve webhook event structure for multi-step settlement flows,
- improve developer docs for cross-network payment creation.
Milestone 3 — Gasless checkout and embeddable payment components
Timeline: 4 weeks
Requested funding: $2,000
Major achievement
Reduce user friction by introducing gasless or gas-abstracted checkout support where feasible, and provide embeddable checkout components for external apps.
Deliverables
- gasless or sponsored-gas payment flow for supported scenarios,
- embedded checkout widget/component for app integration,
- improved checkout SDK support for embedded flows,
- merchant option to choose hosted checkout or embedded checkout,
- checkout state handling for wallet connect, processing, success, expired, and failure,
- better frontend integration path for ecosystem apps.
Secondary work
- improve checkout UX and conversion-oriented design,
- improve SDK examples and frontend implementation docs,
- improve wallet fallback and retry flows.
Milestone 4 — Recurring billing, subscriptions, and streaming-style payment support
Timeline: 4 weeks
Requested funding: $3,000
Major achievement
Expand FluxPay beyond one-time checkout into recurring and continuous payment infrastructure.
Deliverables
- subscription / recurring billing support,
- merchant-defined billing intervals,
- recurring payment links or subscription plans,
- payment lifecycle tracking for active, overdue, cancelled, and renewed billing states,
- initial streaming-payment architecture or scheduled continuous-payment framework,
- webhook support for recurring billing events,
- merchant dashboard support for subscription management.
Secondary work
- improve admin views for recurring revenue monitoring,
- improve receipts, invoice history, and customer payment records,
- improve docs for recurring integration flows.
Team
Saheed Lukman
- Role: Founder / Full-stack builder
- Responsibilities: product architecture, frontend, backend, integration logic, overall system delivery
- Relevant experience: blockchain and full-stack development, hackathon-winning experience, smart contract development, product and infrastructure implementation
- GitHub: https://github.com/hexdee
- Social handle: https://t.me/hexdee
Additional contributors
FluxPay is currently being built primarily by me. If additional contributors are added during the next phase, their roles and profiles will be documented publicly.
Terms of Use
I agree to all of the following terms of use in applying to a Conflux Ecosystem Grant
I have read and understood the Conflux Grants Ecosystem Overview
I have read about and understood that the Conflux Technical Grants are subject to a No-Sale rule
I agree to provide KYC information to the Conflux Foundation for the sake of overall ecosystem security
I understand that I will be required to follow public grant reporting requirements