Integration Grants Application '26: FluxPay

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

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


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

1 Like