Gerege Developers¶
Pay with Gerege App — an open API for any system (web shop, mobile app, till, kiosk, vending machine, invoice) to take payments from people with Gerege App. The person scans a QR, taps a sticker or opens a link, sees the amount in Gerege App's own sheet and pays with Face ID; the money goes from their Gerege Wallet account to yours. And mini apps — your web app, opened inside Gerege App.
Server: modules/miniapp 1.9.0 (2026-10-27). API: https://geregeapp.mn/api/v1/miniapp.
The shortest example¶
curl https://geregeapp.mn/api/v1/miniapp/payment-intents \
-u "$GEREGE_CLIENT_ID:$GEREGE_CLIENT_SECRET" -H 'Idempotency-Key: order-1001' -H 'Content-Type: application/json' \
-d '{"amount": 3500, "description": "Order #1001", "presentment": "qr"}'
# → {"id": "pi_…", "status": "requires_confirmation", …, "pay_url": "https://geregeapp.mn/pay/…"}
Draw pay_url as a QR → the person pays → a payment_intent.succeeded webhook. Step by step:
First test payment in 15 minutes.
Four ways to pay¶
| For | How the person pays | |
|---|---|---|
redirect |
web shops, mobile apps | from checkout to pay_url → Gerege App opens on the phone → back to your return_url |
qr |
tills, kiosks, POS, invoices | scans the QR on a screen or on paper with Gerege App |
terminal |
vending machines, permanent stickers, NFC tags | scans the machine's sticker / taps NFC — the amount comes from that moment's basket |
app |
mini apps inside Gerege App | the payment sheet through the bridge |
Which suits you: Choosing a flow. The differences and claims: Presentments and claims.
Start here¶
-
A developer trying it out
Your first payment in 15 minutes with a test key; no money moves.
-
Web shops and apps
«Pay with Gerege App» at checkout:
redirect,return_url, webhooks, refunds. -
Vending, stickers, NFC
Register a terminal, attach a basket, capture if dispensed — cancel if not.
-
Platforms with many owners
Every owner a sub-merchant: their own payout account, their own settlement.
-
Kiosks, tills, POS
A new QR per basket,
payment_intent.claimed→ «confirm on your phone». -
Mini app developers
An app inside Gerege App: manifest, launch → token, bridge, payments.
Concepts¶
| Concepts overview | Every object in one picture; merchants and mini apps; terms |
| Payment lifecycle | Every state, webhooks, holds and capture, windows |
| Test and live | Two environments, test amounts, review and going live |
| Money flow | Payout accounts, settlements, fees, withdrawing to a real bank |
| Security model | Where secrets live, URLs without amounts, registry names on the payment sheet |
| Personal data · Idempotency · Versioning |
Reference: Webhooks · Error codes · Developer sandbox.
Status¶
«удахгүй» (Mongolian for «soon») = in the standard or the plan, not yet built on this platform.
| Part | State |
|---|---|
The Pay with Gerege App API: kind: "merchant", claimless intents (qr, redirect, terminal), terminals, sub-merchants, holder-approved payout links, payment_intent.claimed / .expired |
✓ |
| Gerege App (iOS): the in-app QR button, NFC reader → claim → payment sheet; approving payout links; withdrawals | ✓ (builds after TestFlight 121) |
Scanning with the camera (/pay Universal Links), the desktop /pay page, the App Clip |
«удахгүй» — the person's step can be played through the API (Quickstart) |
Mini apps: registry, manifest check, review, launch, consent (profile.email, profile.phone), tokens, /me, requires_verified / min_age |
✓ |
Payment intents (automatic, manual capture, capture_within), cancel, refunds, test mode, the app's max_amount |
✓ |
Webhooks: ≤ 5 endpoints per environment (event filters, a secret each, automatic disabling), signatures, retries, 24-hour secret rotation overlap, immediate delivery, delivery log, resend, webhook.test; the events API (GET /events, 30 days) |
✓ (API; the console screens are in the core) |
Named, scoped API keys with IP allowlists (gk_… / gks_…), presets, roll, revoke |
✓ test keys; live keys from the new API (behind a fresh sign-in) «удахгүй» — the default pair for now |
| Test users, console test payments, analytics, the launcher's layout | ✓ |
Settlements (the operator's fees and schedules, fee / net, settlement.paid), per (app, sub-merchant) |
✓ (the operator switches them on per app) |
| Gerege Wallet: organisation accounts, withdrawal requests to a real bank | ✓ |
| A «Merchant» registration in the console, simulation without a phone, dashboard payments and statements | «удахгүй» |
| A sandbox organisation for individuals; eID-signed agreements; the business profile (KYB), go-live checklist, limits | «удахгүй» |
| Printable sticker sheets (PDF), terminal batches | «удахгүй» |
Partial capture by amount; long-lived invoices (expires_in > 1800 s) |
«удахгүй» |
| Android and web hosts; SDKs on npm | «удахгүй» |
Standard and SDKs¶
The mini app side is Gerege's implementation of openpay's OMAS 1.0 (OpenPay Mini App Standard): the same manifest,
launch → token, bridge and signatures; what differs is the name (gerege), the path (/api/v1/miniapp) and the
credential prefixes (gma_…). In these docs ЗААВАЛ (MUST), ХОРИГЛОНО (MUST NOT), ЗӨВЛӨЖ БАЙНА (SHOULD)
and БОЛНО (MAY) carry their RFC 2119 meanings.
Server SDKs: @gerege/miniapp-node (TypeScript) and Go (sdk/go: webhook verification and the merchant payments client
miniapp.NewClient; golang.org/x/oauth2 for a mini app's tokens) — not yet published; these docs are enough to write
without them. In the frontend the host injects window.gerege itself (Bridge).