Capacity reserved for lasting duties
The design considers reconciliation, evidence, audit and recovery across their full lifetimes. It aims to preserve the capacity these duties require while coordinating new activity and existing commitments.
Products · Payments platform
FxPay
The planned Flowesome payments platform and merchant services: accept payments, follow their status and receipts, and manage reconciliation, refunds and disputes.
For merchants and businesses that accept payments and must reconcile them.
PlannedPlanned product. Explore its architectural design and development path.Current status and evidence
FxPay
Powered by FxChain
Product blueprint
A payment flow where settlement, reversal and dispute are explicit
The product vision joins acceptance, payment tracking, receipts, reconciliation, refunds and disputes. Its provider integrations and merchant operations require their own implementation and qualification.
Illustrative product flow
- 1A merchant creates a checkout claim with amount, expiry and settlement terms.
- 2The payer reviews the payment authority in FxWallet or another approved surface.
- 3The applicable qualified integration checks authority and submits or refuses the request.
- 4The product would display observed status, receipts and unresolved outcomes to the relevant parties.
- 5Refund and dispute paths follow the same declared payment grammar.
Checkout intent
A payment request becomes an FxIntent with amount, recipient, expiry, settlement rules and permitted reversal paths.
Settlement receipt
The intended service shows what the applicable provider or protocol confirms, with the source and scope of each receipt.
Dispute grammar
Refunds, reversals and disputes are modelled as bounded claims within the payment design.
Reconciliation export
Merchant books can consume payment evidence, fees, settlement windows and refusal reasons.
Design vision
Payment continuity, designed from the foundations
The FxChain engineering team is exploring how useful action, financial exposure and lasting obligations can work together as a coherent system, giving future merchant services a stronger foundation.
A systemic approach
Make the next useful action part of the design
The design brings the merchant’s next useful step into the foundations: assess which already-authorised action the evidence and applicable provider rules support, with explicit limits for captures, outstanding holds and possible late effects. Repeating a covered request, checking its state or waiting becomes a reasoned decision within that model.
In-depth engineering work connects this decision capability to two supporting ideas: capacity for lasting duties and evidence that remains usable. Together, they aim to turn payment continuity into an intentional property of the system.
Design reviewed
- Design contribution
- Useful authorised continuation, explicit exposure and lifecycle obligations considered together.
- Engineering discipline
- Counterexamples, independent comparison and complete lifecycle accounting.
Evidence with lasting meaning
Supporting payloads, interpretation and provenance belong with the claim they explain. The design considers their continued use through history expiry and migration, while preserving the distinction between record integrity, external facts and custody rights.
From design quality to product value
The evaluation framework considers safety and useful progress together. Comparison with competent existing procedures uses the same evidence, authority and financial assumptions, so that any contribution can be assessed on its engineering merits.
- Safety and usefulness together
- Design progressionEvaluation framework defined.
- Engineering objectiveCompare justified actions, exposure, continuity and complete lifecycle cost under declared rules, equivalent evidence and independent expected results.
- Provider-specific integration
- Design progressionA planned product stage.
- Engineering objectiveTranslate the design into the applicable provider rules, permissions, evidence and control, then implement and qualify that integration.
- Merchant service
- Design progressionFxPay remains planned.
- Engineering objectiveBring product implementation, operational readiness, regulatory requirements and release qualification together.
This is a reviewed design direction within planned FxPay. Product releases and provider integrations follow their own qualification and availability stages. Foundations required by M1 are part of its current complete implementation mandate.
Explore the design vision Why FxChain
What FxPay is designed to address
The problem
Payment services need a coherent journey from authorisation and settlement to refunds, disputes and reconciliation, with evidence at each stage.
Merchants need useful next actions, explicit financial exposure and a clear account of the obligations that continue throughout a payment’s life.
The Flowesome answer
FxPay is designed over provable settlement and the FxChain intent grammar: a payment is a claim with action, constraints, expiry and authorisation, with refunds and disputes handled through the same explicit grammar.
Merchant flows are designed with their boundaries first: what settles, what can be reversed, and under whose authority - all explicit.
Distinct facts
Evidence through the complete payment journey
These six facts need separate evidence. They are not six automatic stages: one can be unknown while another is established. Authority applies across them, and refusal is a possible outcome.
- 1Signed
- A technical signature for a defined payload. It does not alone establish every required legal consent or the authority to act.
- 2Executed
- Execution observed within a specified protocol or provider profile, with its own receipt.
- 3Finalised
- Finality established by the relevant system under its own rules. Production FxChain finality is not claimed.
- 4Delivered
- On the external rail, supported by its own evidence as a distinct delivery fact.
- 5Legally effective
- The applicable legal effect requires its own instrument, context and supporting evidence.
- 6Economically complete
- The obligations and economic outcome are assessed separately, including fees, refunds and unresolved duties.
This explains the design, not an executed service. Its current implementation, availability and limits are described in the claim scope below.
Built on FxChain
Payment capabilities, designed as a coherent whole
The FxChain capabilities this product is designed to use. They are shared, not owned: the same capability can serve other Flowesome products and third-party applications.
Settlement evidence
Protocol finality and external settlement require evidence from their respective systems.
Dispute grammar
Refunds and disputes expressed through explicit claim semantics.
Merchant flows
Checkout, tracking, receipts and reconciliation designed to support the merchant journey.
Useful continuation
Assess permitted next actions when a provider result is incomplete, subject to that integration's rules and evidence.
FxPay is a planned product. This blueprint presents its payment design and the development path from shared protocol foundations to qualified merchant services.
Place in the network
Where it sits, and why that matters
FxPay is the payments and merchant-services direction, presented after FxWallet and FxTrade and before FxBank. This is a proposed product orientation, not a release commitment.
FxPay is intended to use shared FxChain capabilities for payment intents, receipts and reconciliation. Product-specific integrations follow their own design and qualification stages.
Products
FxWalletFxTradeFxPayFxBank
Foundation
FxChainClaim scope
What is real, stated plainly
Proven today
- Published product blueprint and reviewed design direction
In development
- Foundations required by M1, with FxPay product implementation planned separately
Later gates
- Payment semantics over FxChain intents
- Merchant flow design with explicit boundaries
- Evidence-supported continuation under applicable provider rules
Not claimed
- Payment processing and merchant onboarding
- Card programmes
- Regulatory authorisation
- Provider integration, partnerships or measured comparative performance
Proven today, or practised on the lineIn development / qualifiedDirection: planned or researchLater gateNot claimed
Boundaries
Security and authority boundaries
Conditions and responsibilities that must hold for the applicable product or protocol profile.
- Each live payment flow requires an explicit, public compliance posture before release.
- Merchant commitments follow the settlement evidence available.
Staged roadmap
Gates, not dates
- 01
Payment design
PlannedClaims, settlement and dispute grammar for commerce, informed by systemic design work on useful authorised continuation, explicit exposure and lasting obligations.
- 02
Devnet flows
ReservedExperimental flows on a running deployment.
- 03
Live payments
ReservedQualified payment flows within explicit regulatory boundaries.
Related
Explore the family
Discuss a workflow about FxPay.
info@flowesome.com - we answer with what is provable today and what is staged for tomorrow.