Collect a Payment

Receiving payments traditionally means building a separate integration for every payment network, every QR standard, every alias directory. Each rail has its own format, its own onboarding process, and its own way of telling you that money arrived. Adding a new channel means months of work.

With Minka, you register a single anchor — a mapping between a simple identifier and a wallet — and the ledger handles everything else. Payments arrive through any connected network, settle automatically, and credit the right account without you writing a single line of routing logic.

What you're building

In this guide you'll generate a QR code for a checkout at the Great Coffee store from Create a Wallet. A customer orders a coffee, your POS creates a QR with the exact amount, the customer scans and pays. One API call to generate the code, one scan to collect the money.

Generate a QR at checkout

A dynamic QR is generated per transaction — at the POS, on an invoice, or in a mobile app. It embeds the exact amount so the customer just confirms rather than typing a number. Each code is single-use: once the payment settles, the anchor is consumed.

curl -X POST "https://{ledger-host}/v2/anchors" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer {your-token}" \
  -H "x-ledger: {your-ledger}" \
  -d '{
    "data": {
      "handle": "qr0000002@greatcoffee.co",
      "schema": "qr-dynamic",
      "target": "store1@greatcoffee.co",
      "amount": 850000,
      "symbol": { "handle": "cop" },
      "custom": {
        "reference": "ORDER-4521"
      }
    }
  }'

curl "https://{ledger-host}/v2/anchors/qr0000002@greatcoffee.co" \
  -H "Authorization: Bearer {your-token}" \
  -H "x-ledger: {your-ledger}"

What happens when a customer pays

Once the QR is live, the entire payment flow is automatic.

The customer scans and pays. Their bank sends a payment through the connected network. The payment carries the paymentId embedded in the QR code.

The ledger resolves and routes. The ledger matches the paymentId to your anchor, finds the linked wallet, and coordinates settlement using a two-phase commit — every participant confirms before any balance changes become permanent.

The merchant is credited. The bridge reads the merchant's settlement account from the wallet profile and creates a credit intent. The merchant's bank account is funded automatically.

Why this matters

One registration, any network. You register the anchor once. Payments arrive from any connected network — a national switch, a card scheme, a mobile money platform — without building a separate integration for each one. When a new network connects, existing anchors work with it automatically.

The bridge handles compliance. The QR bridge reads the merchant's country from the wallet profile and generates a payload that is valid for that country's payment network — EMVco for Colombia, PIX for Brazil, PromptPay for Thailand. Switching to a new market means updating the merchant wallet's country field and adding the country profile to the bridge. No code changes, no new integrations.

Automatic settlement. Every payment settles atomically through the two-phase commit. Both sides commit or both sides roll back. Reconciliation is built into every transaction.

What you learned

• How to generate a QR code for a specific checkout amount
• How the bridge reads the wallet hierarchy and generates a network-compliant payload
• How the ledger resolves, routes, and settles inbound payments automatically

Next steps

• Get Payment Notifications — subscribe to events when payments arrive
• Collect with a Static QR — permanent QR for store counters with the full settlement flow
• Collect with a Dynamic QR — per-transaction QR with tax overrides and amount encoding
• About Anchors — how anchors resolve identifiers to accounts across networks