NEW → PENDING → terminal
Every operation is a versioned state, not a screenshot. Webhooks retry until the MID is settled or declined.
Nested HMAC · idempotent creates · signed webhooks
SPQR opens and services merchant IDs for PayIns and PayOuts. One signed API, local methods we underwrite, reserved balances, and a cabinet your ops team can actually run.
You integrate once. We issue the MID, accept the signed contract, keep gross, net, and reserved outflow honest, and operate the desk that finance and engineering both use.
Commercial setup, credentials, and a live account on rails we service — not a pass-through to someone else’s stack.
Nested HMAC-SHA256, timestamps, and idempotency keys. Secrets stay on your backend.
Pay-in, pay-out, and reserved outflow stay reconcilable instead of “dashboard math”.
Statuses, limits, incidents, and settlement — one cabinet and a 24/7 ops channel.
Customers pay the way their market already pays. You keep one status machine, one webhook, one settlement view — on accounts we issue and service.
Every operation is a versioned state, not a screenshot. Webhooks retry until the MID is settled or declined.
Return the customer action the method needs — redirect, QR, or instructions — then wait for the signed callback.
Reserve outflow first. Release or capture against the same natural key the ledger already knows.
const payment = await spqr.payments.create({
merchant: "acme_my",
amount: 12500,
currency: "MYR",
payment_method: "duitnowqr"
});
Write @spqr_operations with markets and volume.
We open the merchant ID and issue cabinet access after commercial setup.
HMAC keys stay in your backend. First PayIn from staging.
Your MID is live: local methods, signed webhooks, 24/7 desk on the same channel.
MID onboarding, incidents, and settlement — one handle, no ticket queue as the front door.
@spqr_operations