Path 01 · Merchants

Accept payments.
Keep the relationship.

Fabric-based payment flows let you accept money from any bank or wallet without routing through a proprietary network that owns the customer data, sets the rules, and takes a cut on every transaction.

0
Proprietary intermediaries required in the payment path
100%
Of transactions are cryptographically verifiable by you, without contacting any authority
Free
To implement — Apache 2.0, no licensing fees, no certification costs

How it works

A payment in four steps.

A Fabric payment follows the same pattern as any payment you know — but with a verifiable, tamper-evident record at every step that belongs to you, not to the network.

01

You generate a signed payment request

Your system creates a structured payment request — amount, currency, your receiver address, and an expiry — and signs it. This object is the checkout session. You can present it as a QR code, a deep link, or embed it in a payment page. No API call to a third-party network is required to create it.

Merchant-side
02

The payer authorises from their bank or wallet

The payer scans or opens the request. Their bank or Fabric-compatible wallet presents the payment details and collects their authorisation through the institution's own authentication flow. You never handle the payer's credentials. The payer's bank doesn't need a bilateral relationship with yours.

Bank or wallet
03

You receive a cryptographic payment proof

The authorising institution issues a signed payment proof. You can verify it independently — without calling a payment network, without a webhook that might fail, and without waiting for a batch settlement file. The proof is the receipt. It does not require trust in any intermediary.

Open verification
04

Settlement happens on existing rails

Fabric governs the messaging layer — the structured request and proof formats — not the money movement. Your bank receives funds through the same interbank settlement infrastructure it uses today. Nothing changes in the core banking stack. The Fabric layer adds verifiability, not a new payment network.

Existing rails

Why it matters

What changes when the standard is open.

No proprietary network lock-in

You are not dependent on the rules, pricing, or uptime of a single card network or PSP. Any institution that implements the Fabric standard can participate in your payment flow.

Your customer data stays yours

Fabric payment flows do not route through an intermediary that aggregates transaction data, profiles payers, or sells insights. The payment proof is yours. The customer relationship is yours to own.

Independently verifiable receipts

Every payment produces a cryptographically signed proof you can verify without contacting anyone. It does not expire. It cannot be forged or altered. That is a stronger guarantee than a webhook or a settlement report.

No chargebacks by design

Payments authorised by cryptographic signature are irreversible at the protocol level. There is no card-network-initiated chargeback. Dispute resolution, where needed, happens under rules you agree to — not rules imposed by a network.

Works with your existing bank

Fabric is a messaging standard, not a new bank. Your receiving account stays at the institution you already work with. Adding Fabric support does not require switching banks or opening new accounts.

Free to implement

The standard is published under Apache 2.0. No licensing fees to implement it, no certification costs to comply with it, no royalties on transactions. The Foundation's only job is to maintain the standard.

How it compares

Not a replacement. An alternative.

Fabric does not exist to replace card payments. It fills gaps that existing rails do not serve well — where privacy matters, where cross-border costs are prohibitive, or where a verifiable audit trail is required.

Property
Fabric standard
Card networks
Independently verifiable payment proof
Yes
No
Customer data stays with merchant
Yes
No
No proprietary network dependency
Yes
No
Works cross-border without bilateral agreements
Yes
Partial
Chargeback exposure
None
Significant
Widespread consumer adoption today
Growing
Yes

Need privacy-preserving payments? CashPack is built for that.

The CashPack Protocol defines digital bearer instruments — like physical cash, but with a tamper-evident chain and full Operator auditability. Useful for merchants who issue gift instruments, run voucher programmes, or operate in contexts where buyer privacy is a genuine product feature. Works over any settlement infrastructure — core banking, tokenized deposits, or public blockchains.

Ready to integrate?

Talk to a Fabric-compatible processor, or start with the specification to understand how the payment flow works in detail.