BLIPS

BLIPS Meridian · Payment interlinking & orchestration

Local payment systems. Global payment reach.

Meridian connects local rails, fiat currencies, and supported digital-asset paths so payment providers can extend cross-border reach without replacing local systems.

Your institution serves the customer. Meridian coordinates the payment across networks.

Developer documentation
01 · Why Meridian

Extend what your payment business can do.

One interlinking model connects institutions, local rails, and corridor-specific providers.

01

Reach beyond your domestic network

Connect local collection and payout through one reusable model.

02

Connect fiat and digital money

Coordinate accounts, conversion, and supported digital-asset paths.

03

Serve smaller, frequent payments

Target end-to-end economics—not only the network fee.

02 · Payment services

Build the payment services your customers need.

Reference services for banks, PSPs, VASPs, exchanges, and payment platforms.

01

Cross-border remittances

Familiar send experience. Local account or payout delivery.

02

Business and platform payouts

Traceable delivery to suppliers, contractors, creators, and sellers.

03

Stablecoin-funded local payouts

Regulated conversion from supported funding to local currency.

04

Wallet and exchange fiat access

One provider, quote, and evidence model across supported flows.

03 · Payment backbone

A shared settlement backbone between local payment systems.

Local rails stay at the edges. Meridian coordinates providers, a Lightning middle leg, and delivery evidence.

Meridian coordination plane

Identity, terms, readiness, state, and cross-leg evidence.

  1. Stage 01

    Source edge

    Sending institution

    • Customer channel
    • Accounts · IPS / ACH / RTGS
  2. Stage 02

    Gateway

    Conversion and liquidity

    • Executable pricing
    • Funded conversion
  3. Stage 03

    Shared network

    Lightning middle leg

    • Conditional routed reach
    • Off-chain execution
  4. Stage 04

    Gateway

    Conversion and delivery

    • Destination liquidity
    • Local-currency delivery
  5. Stage 05

    Destination edge

    Receiving institution

    • Account or payout
    • Local rail · delivery evidence

Local access at the edges. A common execution network in the middle.

Why Lightning

Open access

Compatible implementations, not one operator.

Routed reach

Bilateral channels form wider paths.

Off-chain execution

Repeated transfers without base-ledger writes.

Small-payment objective

Economics beyond the network fee.

BTC-only Lightning carries BTC. Stablecoin paths need compatible channels or gateways. Fiat legs retain their own finality.

04 · Institutional fit

Keep your institution at the center of the service.

Adapters connect existing channels, ledgers, controls, and treasury to the shared payment model.

Bank view: existing channels, ledgers, controls, SWIFT and domestic rails remain in place. Generic reference architecture.
05 · Execution confidence

Make the whole payment visible—not just the network transfer.

Pre-validation, terms, settlement, and delivery stay visible under one payment identity.

01

Check the destination

Resolve the receiver and required checks before commitment.

02

Make terms clear

Show send, receive, FX, fees, and expiry together.

03

Follow local delivery

Separate network settlement, payout, and exception evidence.

Payment identity

MER-2026-04-17-7F3A
Quote
Terms · expiry
Source
Provider · amount
Lightning
Hash · preimage
Payout
Provider · outcome

PENDINGNetwork settled · payout unresolved

COMPLETEDestination delivery confirmed

Illustrative UI. Shared identity correlates evidence; it does not make independent fiat legs atomic.

Inspect payment pre-validation
Meridian payment pre-validation capability summary
01Receiver identity and alias resolutionResolve the recipient and use Confirmation of Payee where available.
02Account and destination readinessCheck eligibility, currency, limits, and account information.
03Compliance-data coordinationExchange required compliance information between accountable institutions.
04Payment-data mappingPreserve payer, beneficiary, and instruction data across systems.
05Quote and route readinessCheck pricing, expiry, funding, liquidity, and route conditions.

An unavailable required check is not a pass. Institutions retain their legal decisions.

Reference-design workflow; protocol labels are illustrative.
06 · Product evidence & developers

Explore the design behind the product.

01

Developer documentation

Operations and schemas.

Inspect
02

Public Test

Try It and bounded sandbox.

Inspect
03

Corridor research

Dated assumptions and inputs.

Inspect
Developer details · Verified operation sequence

Customer setup, addressing, pre-validation, quotes, execution, and readback.

Execution is a body-less POST with an optional Idempotency-Key. Acceptance is not delivery.

Review the current API reference
Verified operations2026-04-08
  1. 01POST/customers
  2. 02POST/customers/{customerId}/payment-address
  3. 03GET/receiver/ppv/{ppvAddress}
  4. 04POST/quotes
  5. 05GET/quotes/{quoteId}/current
  6. 06POST/quotes/{quoteId}/execute
  7. 07GET/transactions/{transactionId}

Current stage

Functional design-stage MVP: documentation, prototypes, sandbox workflows, and reference architectures. No live external volume or production banking integrations.

07 · Meridian and Parvia

Connect today’s payment systems. Extend to tokenized bank money.

BLIPS Meridian

Interlink existing rails and supported digital-asset routes.

BLIPS Parvia

Extend controlled connectivity to issuer-specific tokenized deposits.

Explore Parvia

BLIPS Meridian

Extend the reach of your payment business.

Connect your accounts, rails, and customer journeys.

Discuss MeridianReview the architecture