Design and qualification
Treasury policies, approval flows, invoicing, Pay API contracts and reconciliation are defined as product directions. A production Bloch Pay service is not live.
DESIGN STAGETREASURY + PAY / PRODUCT ROADMAP
Control the decision.
Trace the payment.
Bloch Pay brings together proposed treasury controls and native BLCH payment workflows for organizations that need clear authorization, visible status and records they can reconcile.
Stage: design only. The wallet is in public beta and network data tools exist; the organizational Treasury and Pay services described here are not live.
PROPOSED PAYMENT JOURNEY CONCEPT
01
RequestInvoice or treasury instruction
CREATED02
AuthorizePolicy, approvals and device signing
REVIEW03
ObserveTransaction, inclusion and finality
NETWORK04
ReconcileReceipt, books and exceptions
EVIDENCEThe illustration is a target workflow, not a live product screen.
Two connected productsBloch Treasury — policy-led authorization for teamsBloch Pay API — invoices, payment status and reconciliation
CURRENT STATUS / SEPTEMBER 2026
In development.
Clear about the stage.
These products and partner programs are being designed. The current portfolio classifies Treasury + Pay as design-stage software.
Foundation work continues
Wallet hardening, complete transaction indexing, stable status APIs, finality evidence and documented credit rules are required before a controlled pilot.
GATES OPENPartner model in development
Potential partner roles are being scoped for integrations and, later, authorized payment rails. No production partner integration or signed commercial relationship is asserted here.
NO LIVE RAILS01 / THE PRODUCT LINES
From instruction to evidence.
A coordinated design for controlling value movement and explaining what happened afterward.
P2 / DESIGN ONLY01
Bloch
Treasury.
Organizational controls for preparing and approving native BLCH transfers. Policies sit before signing; the audit trail records who proposed, reviewed and authorized each action.
- Multi-step approvals and distinct roles
- Limits and approved recipients
- On-device signing and recovery design
- Exportable decision history
P2 / DESIGN ONLY02
Bloch
Pay API.
Native BLCH payment workflows for platforms and operations teams. Connect a request to the resulting transaction, track status and reconcile it against the originating business record.
- Invoices and payment references
- Confirmation and finality receipts
- Reconciliation and exception states
- Idempotent events and webhooks
02 / A SINGLE WORKFLOW
Every movement has a reason, a signer and a result.
Keep operational intent, network execution and accounting evidence connected.
01 / PREPARE
Define the request
Bind an invoice, payout or treasury instruction to an amount, destination, reference and network identity.
02 / APPROVE
Apply the policy
Evaluate roles, recipient rules and limits before a designated device signs the transaction.
03 / TRACK
Follow the network
Distinguish submitted, included, confirmed and qualified-finality states rather than collapsing them into “paid.”
04 / RECONCILE
Close the loop
Match transaction outputs and status to the originating instruction; preserve exceptions and an audit export.
All four steps describe the target product workflow. They depend on a hardened wallet, complete indexing and verified status data.
03 / CONTROLS + EVIDENCE
Designed for responsible operations.
Make decisions reviewable and payment states explicit before expanding to partner systems.
01Authorization by policy
Separate preparation, approval and signing; record the rule version and decision for each transfer.
02Device-held keys
Use native wallet signing without assuming an initial Bloch Pay custody role.
03Finality-aware receipts
Link a payment reference to transaction inputs, outputs, amounts, height, slot and a qualified status.
04Reconciliation by design
Compare business instructions, network records and internal books with visible exception handling.
04 / ECOSYSTEM FIT
Payment workflows need more than a wallet.
Bloch Pay builds on existing ecosystem components and on data services still being qualified.
Postern Wallet
Public-beta native signing informs the proposed organization approval and device-signing model.
Explore the ecosystem ↗Bloch L1
Genesis-4 transactions and public explorer records provide the network evidence behind receipts.
View the explorer ↗Bloch Data
Complete indexing, versioned APIs and reliable events are prerequisites for managed Pay workflows.
See the data roadmap ↗05 / PARTNERSHIP DEVELOPMENT
Integration paths built with the right operators.
Partner roles are product requirements, not a claim of completed agreements or enabled rails.
Organizations and platforms
Define approval, invoice, payout and reconciliation needs with treasury teams, exchanges and application operators.
Target: controlled workflow pilots after technical qualification.Wallet and data integrators
Connect device signing, indexed transaction records and status events through documented interfaces.
Target: stable contracts and support procedures.Financial institutions
Any future fiat, regional or payment-network connection requires authorized institutions and jurisdiction-specific legal and operational review.
Target: partner-led research; no live rail access.Partnership status
The site does not name partners because no specific agreement, launch date or production integration has been verified for these product lines.
06 / DELIVERY GATES
Qualify the foundations before payment claims.
Product stages follow the Bloch Inc portfolio and the evidence required for real value flows.
Reliable base
Regular checkpoints, independent node comparison and reproducible network releases.
Usable records
Harden the wallet, complete indexing and document stable transaction-status APIs and events.
Controlled pilot
Test policies, invoices and reconciliation with documented credit rules, recovery and support.
Qualified expansion
Consider fiat rails and regional connections only with authorized partners, legal review and settlement controls.
Current boundary
Bloch Pay is a product proposal. No live merchant acquiring, fiat transfer, Pix/Open Finance connection, custody, credit or regulated payment-institution service is claimed.
PAYMENTS THAT CAN BE EXPLAINED
Move from a transaction
to a complete account of it.
Explore the network and the roadmap behind organizational Treasury and Pay workflows.