FxPay
A payment flow where settlement, reversal and dispute are explicit
FxPay is the planned commerce surface for checkout, settlement receipts, merchant reconciliation and dispute grammar. It describes payment authority before a payment is accepted.
Typical 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.
- 3FxChain admits, executes or refuses the payment claim.
- 4FxPay displays settlement receipts and denial reasons to both sides.
- 5Refund and dispute paths follow declared grammar instead of informal exceptions.
Checkout intent
A payment request becomes an FxIntent with amount, recipient, expiry, settlement rules and permitted reversal paths.
Settlement receipt
Merchants receive evidence of what settled, when it settled and which state transition backs it.
Dispute grammar
Refunds, reversals and disputes are modeled as bounded claims instead of after-the-fact customer support improvisation.
Reconciliation export
Merchant books can consume payment evidence, fees, settlement windows and refusal reasons.
Signed is not delivered
FxPay is designed over the settlement-truth law: a payment leaves a trail of facts, and no flag stands in for them.
- Signed
- Consent, with amount, recipient, expiry and permitted reversal paths declared.
- Executed
- On the protocol, with a receipt of what was observed.
- Finalised
- By consensus, on the plane the payment declared - a design, since no network exists.
- Delivered
- On the external rail: a separate fact, evidenced by the rail, never inferred from finality.
- Legally effective, economically complete
- Two further facts the protocol never claims; missing evidence is recorded as missing, not as false.
What is real, stated plainly
Proven today
- Nothing - no payment service, no merchants, no cards
In development
- Nothing yet - staged behind chain and wallet surfaces
Later gates
- Payment semantics over FxChain intents
- Merchant flow design with explicit boundaries
Not claimed
- No payment processing of any kind today
- No merchant onboarding, no card program
- No regulatory authorization - and none implied
Proven today, or practised on the lineIn development / qualifiedDirection: planned or researchLater gateNot claimed
The problem
Payments need what chains rarely give: settlement you can rely on, native refund and dispute semantics, and compliance that is designed in rather than bolted on.
Merchants get probabilistic finality and a support inbox. That is not a payment rail.
The Flowesome answer
FxPay is designed over provable settlement and the FxChain intent grammar: a payment is a claim with action, constraints, expiry and authorization - so refunds and disputes are part of the grammar, not exceptions.
Merchant flows are designed with their boundaries first: what settles, what can be reversed, and under whose authority - all explicit.
Designed capabilities - nothing here is shipped
Provable settlement
A payment is final when the chain can prove it - and says exactly when that is.
Dispute grammar
Refunds and disputes designed as claim semantics, not customer-service improvisation.
Merchant flows
Checkout and reconciliation surfaces built on evidence, exportable to accounting.
Compliance by design
The compliance posture of each flow stated before the flow exists.
Where it sits, and why that matters
FxPay is the everyday-money surface of the network: where the ecosystem meets commerce.
It builds on FxWallet for user access and on FxBank research wherever regulated rails are involved.
Products
Foundation
FxChainSecurity and authority boundaries
What this product will not do, stated before what it will.
- No live payment flow before its compliance posture is explicit and public.
- Where regulated rails are involved, FxPay follows the FxBank staged path - never shortcuts it.
- Merchant promises are limited to what settlement can prove.
Gates, not dates
- 01
Payment design
PlannedClaims, settlement and dispute grammar for commerce.
- 02
Devnet flows
ReservedExperimental flows on a running deployment.
- 03
Live payments
ReservedOnly behind explicit regulatory boundaries.
Talk to us about FxPay.
info@flowesome.com - we answer with what is provable today and what is staged for tomorrow.