Open-source, self-hosted payment gateway

The payment gatewayyou deploy and own.

Run it on your own servers. Connect payment providers and stablecoins as peer rails on one double-entry ledger, onboard your merchants, and turn on a Chainlink CRE workflow when you want anyone to check that the gateway holds what it owes.

Open the appSee the checkout
Payminto merchant dashboard home with paid payments, paid by asset, payments received per day and recent payments (sample data)Payminto merchant dashboard home with paid payments, paid by asset, payments received per day and recent payments (sample data)
Hosted checkout confirming a USDC payment on Solana, with the Received, Final, Settled rail (sample data)Hosted checkout confirming a USDC payment on Solana, with the Received, Final, Settled rail (sample data)
  • Self-hosted
    Your servers, your keys, your database.
  • One ledger
    Every rail posts the same double-entry lines.
  • MIT licensed
    Read it, run it, change it.

Why this exists

Stablecoins became a rail.
Open gateways did not follow.

Merchants who want stablecoins next to cards choose between closed, custodial processors and open-source tools that cover one rail. And a merchant who lets a gateway hold money has to trust its balance sheet.

How a payment flows

One payment,
every line
accounted for.

  1. 01Payer pays on any rail

    Card, UPI or a stablecoin on Solana: each rail is a connector behind the same switch.

  2. 02The switch routes it

    An intent and an attempt, an idempotency key, and an exclusive claim so a capture is never sent twice.

  3. 03Ledger lines post

    The payment lands as balanced double-entry lines. Balances are derived from lines, never stored.

  4. 04The fee posts

    From a versioned fee rule, never edited in place. The payment records the rule version it paid.

  5. 05Settlement

    Settlement is lines too, so the journal still balances and history is append-only.

RailsIllustrative figures
Card
UPI
USDC · Solana
USDT · Solana
Payment switchprocessingsucceeded
intent pi_8f2c · attempt 1
Idempotency-Key ord-1042
claim exclusive · connector solana
Journal · USDC.SOLANA
  • Dr Clearing · SolanaPayment100.00
  • Cr Merchant balance100.00
  • Dr Merchant balanceFee · rule v3, 1%1.00
  • Cr Fee revenue1.00
  • Dr Merchant balanceSettlement99.00
  • Cr Clearing · Solana99.00
Debits 200.00 = Credits 200.00Balanced ✓

Chainlink CRE · optional

Proof the gateway
can pay what it owes.

Proof of Reserve shows what is held, not what is owed. A CRE workflow compares the ledger's liabilities with reserves on chain, writes a signed report through Chainlink's forwarder, and the gateway re-verifies it from its own RPC before showing it.

signed reportonReportSolvencyAttestedre-verifiedLedger liabilities1,250 USDCcheckpoint + hashOn-chain reserves1,300 USDCat finalizedChainlink CRE workflowDON consensusKeystone forwarderdelivers the signed reportGatewayAttestationsreplay-checked, storedGateway verifierre-reads it from its own RPC✓ Attestedstored and shown

Figures are from the local end-to-end run (Anvil chain, Chainlink's Keystone mock forwarder).

  • Reserve addresses come from the workflow's configuration, never from the gateway.
  • A figure that does not match what the gateway served is stored as a mismatch, never shown as attested.
  • Simulated reports are labelled as simulated and refused in live.
  • Off by default. With CRE off, the gateway behaves exactly as it does without the module.

Stablecoins on Solana

USDC and USDT,
booked like any rail.

Each payment gets its own deposit account. The credit is the observed balance change, never the instruction amount. Wrong tokens are recorded as anomalies, never credited. Sweeps to your hot wallet survive crashes, lagging nodes and racing workers.

The deposit

Confirmed means seen. Finalized means credited.

$Payer walletSPL transferDeposit accountone per paymentWatcherRPC A + RPC BLedgerUSDC.SOLANA
  • A null answer from a lagging node never moves the cursor.
  • A deposit is dropped only when two distinct endpoints agree.
  • Live refuses to boot with fewer than two RPC providers.

The sweep

A state machine that can be rebuilt from the database and the chain alone.

processingclaim in one txpendingsignature saved, sentcompletedbooked oncefailedproven dead
  • Every signature is saved with its blockhash before it is sent.
  • One sweep in flight per token account, enforced by a unique lock row.
  • Every transition is a compare-and-set, so a stale worker changes nothing.
  • Deposits become swept only when a finalized attempt is booked.

Full rules and tests ship with the Solana track write-up. RPC is treated as evidence: a deposit is credited only when two distinct providers agree.

The product

Real screens,
not renders.

A payment link with its checkout preview built by the server, so the fee shown is the fee charged, and the hosted checkout a payer sees once a USDC payment is final. Development previews with sample data.

Payment link detail: item, payment methods with the fee rule version, and a live checkout preview
Hosted checkout showing a paid USDC payment on Solana with received and final steps
app.payminto.io checkout.payminto.io

What you get

The parts a gateway
gets wrong first.

  • 01

    One ledger for every rail

    Card and stablecoin payments land as the same double-entry lines. Balances are derived, never stored, and the application role cannot rewrite history.

  • 02

    Fees you can audit

    Versioned fee rules, never edited in place. Every payment records the rule version it paid.

  • 03

    A payment switch

    Intents and attempts, idempotency keys, exclusive claims so a capture is never sent twice, and a reconciler that resolves unknown outcomes from the provider.

  • 04

    Payment links

    A six-step builder with a checkout preview built by the server, unguessable short links and QR codes.

  • 05

    Live and test isolation

    One environment per process. Live refuses to boot with development keys, mock providers, test databases or testnets.

  • 06

    RPC as evidence

    Live needs two distinct RPC providers per chain. A deposit is dropped only when both agree.

Status

What is built,
what is not yet.

Every merged module went through independent review rounds; the findings and fixes are in the commit history.

Built and in main

  • Double-entry ledger and versioned fee rules
  • Live and test isolation
  • Payment switch
  • Payment links and the six-step builder
  • Hosted checkout
  • USDC and USDT on Solana
  • Chainlink CRE contract, module and solvency workflow
  • Design system and merchant dashboard

On branches, not merged

  • Custody providers: self-custody fence, BitGo next
  • Kuberpays (card) and Payvang (UPI) connectors
  • Routing across rails
  • Payment links on the switch with every method
  • NOWNodes RPC preset
  • One-command compose and CI

Self-host

Your servers.
Your ledger.

Install each Node workspace once, then run each service in its own terminal. The backend target loads backend/.env.

terminal
$ git clone <your-payminto-remote> payminto
$ cd payminto
$ make backend   # API on :8090
$ make frontend  # dashboard on :3003
$ make checkout  # hosted checkout on :3002
$ make smoke-local

Tests, the CRE simulation and the full repository map are in the repository README.

Hackathon tracks

One product,
four tracks.

  • Chainlink

    A CRE workflow attests what the ledger owes against reserves on chain, and the gateway re-verifies every report from its own RPC.

  • Solana

    USDC and USDT accepted as separate assets on one ledger, with sweeps that survive crashes and racing workers.

  • NOWNodes

    RPC treated as evidence: two distinct providers for every money decision.

  • AWS

    Runs inside the merchant's own account, with isolated keys per environment.

Business model

Open core.
Paid operations.

  • Core

    Self-hosted

    Payment core, dashboard, API and MCP server, plus community connectors. The merchant runs it on their own infrastructure.

  • Licence

    Enterprise

    Managed operations and monitoring, audit reporting and compliance support, priority connectors and an SLA.

  • Services

    Connectors

    New acquirer and chain connectors, written from the provider's API docs and paid per integration.

Proposed model. Pricing to be validated with pilot merchants.

Questions,
answered.

Who holds the money?
Payminto is software you run. Card and UPI money moves through the payment providers you connect. Stablecoins arrive at deposit accounts derived from keys you configure and are swept to your hot wallet. Custody providers such as BitGo are in progress on branches.
What does Payminto cost?
The code is MIT licensed. The payment providers and networks you connect charge their own fees. The fees you charge are versioned rules, and every payment records the version it paid.
Do I need Chainlink to run it?
No. The CRE module is off by default (CRE_ENABLED=false), and with it off the gateway behaves exactly as without it. Running the workflow in production needs Chainlink CRE Early Access; the steps are in cre/README.md.
What happens if a worker crashes mid-sweep?
The claim, its links and its lock are written in one transaction before anything is signed, and every signature is saved before it is sent. A restarted or second worker resumes from the database and the chain, and every transition is a compare-and-set, so nothing is sent twice.
Why two RPC providers?
A single node can lag or briefly lose a transaction, which makes a live deposit look missing or dropped. Live refuses to boot with fewer than two distinct endpoints, and a deposit is dropped only when both agree after finalization.

Run your own
payment gateway.

Open the app and the hosted checkout.

Open the app Open the checkout