Introduction

Every payment system is different. Banks run proprietary core banking platforms with their own APIs, data formats, and transaction models. Payment networks use messaging standards that vary by country and scheme. Settlement systems, card processors, mobile wallets — each one speaks its own protocol, handles errors differently, and has its own idea of what "confirmed" means.

Traditionally, connecting these systems means building bespoke point-to-point integrations. Each new participant requires months of development: mapping protocols, handling edge cases, building reconciliation logic to figure out what actually happened when the two sides disagree. The result is a web of brittle connections where every new integration multiplies the complexity.

Bridges change the equation.

One protocol to connect them all

A bridge is a standard interface between the Minka Ledger and any external system. Instead of each participant learning the protocol of every other participant, each one implements a single, well-defined REST interface. The ledger handles the orchestration — routing intents, coordinating participants, managing the transaction lifecycle. The bridge handles only one thing: translating ledger operations into whatever the external system requires.

This is payment orchestration at scale. A new bank connects to an existing payment network by implementing one bridge, not by integrating with every other bank individually. The protocol is the same whether the external system is a core banking platform in Colombia, a card processor in Mexico, or a mobile wallet in Southeast Asia. What would take months of custom integration collapses to days.

Built-in reconciliation through two-phase commit

The hardest part of payment integration is not moving money — it is knowing what happened. When two systems process a transaction independently, they can end up in inconsistent states. Did the debit go through? Did the credit land? Traditional systems paper over this with end-of-day reconciliation files, manual matching, and exception queues that someone reviews the next morning.

The ledger eliminates this problem at the protocol level. Every bridge operation follows a two-phase commit protocol where each participant submits a cryptographic proof with a core transaction ID at every step. The ledger knows — in real time, not next day — exactly what happened on each side of a transaction. Reconciliation is not a batch job. It is a property of the protocol itself.

When a bridge prepares a debit, it reports the banking core's transaction ID. When it commits a credit, it reports that ID too. These proof chains create an unbroken audit trail from intent to settlement, signed by every participant. If something goes wrong, you do not grep through log files — you read the proofs.

Complexity stays where it belongs

Every external system has its own complexity — retry logic, error codes, authentication flows, idempotency requirements. Without bridges, all of that complexity leaks into the ledger. With bridges, it stays contained behind the bridge interface.

The ledger does not know or care that Bank A uses OAuth2 and Bank B uses mTLS. It does not know that one core banking system requires reservations before debits while another does immediate deductions. It does not need to map between a dozen different error taxonomies. The bridge absorbs all of that, exposing a clean, predictable interface to the ledger.

This separation means you can change, upgrade, or replace the external system behind a bridge without touching the ledger or any other participant. The bridge is the boundary.

What this section covers

Prerequisites

• Start Here — Understand ledger basics
• Moving Money — Familiarity with intents and wallets
• About Signers — Signing keys and authentication