How payments work

A book transfer, signed twice, reconciled nightly.

There is no card. There is no third-party PSP. There is a single authenticated request from us to you that moves money between three accounts inside your bank.

CUSTOMER
Bank App
identity + session
MINI-APP
Alpha Store
WebView + bridge
BANK CORE
Settlement API
HMAC + mTLS
VENDOR
Key Issuance
Asiacell / PUBG / …
LEDGERS
3-account split
Customer · Alpha · Bank
authorize · HMACissue keykey receiptcapture · atomic
synchronousasync receiptall arrows complete in 4.7s median
End-to-end flow
01

Authorize

Customer hits 'Pay' in the mini-app. We POST a signed authorization request to your settlement endpoint with: customer token, item ID, gross amount, our share, your share, idempotency key.

POST /authorize · HMAC
02

Verify

Your core verifies HMAC, customer balance ≥ gross, and AML/velocity limits. Returns 200 with a hold reference, or 4xx with a structured reason code.

200 OK · hold ref
03

Capture

We deliver the digital key (or fail closed). On success, we POST capture: which atomically debits customer for gross, credits Alpha Store account for cost, credits bank revenue account for margin.

POST /capture · atomic
04

Receipt

Bank returns final ledger reference. Customer sees the key inside the mini-app and a transaction line in your statement, side-by-side, in the same session.

ledger ref · receipt
05

Reconcile

At T+1 02:00, we send a signed CSV of every transaction. Your reconciliation engine compares against your ledger. Differences open an automatic ticket.

T+1 02:00 · CSV
What you control
  • 01Per-customer daily and monthly limits (overrides our defaults)
  • 02Per-category enable/disable (e.g. you may exclude gaming)
  • 03Margin split per category, renegotiable quarterly
  • 04Reason-code library for declines, mapped to your existing UX