Server Integration
These pages describe the game server APIs required for Alogame payment integration.
Everything Alogame calls on your server belongs to exactly one of three contracts. They are not interchangeable — each has its own endpoints, signature algorithm and response format. Ask your Alogame Operations Manager which one applies to your title before writing any code.
Pick your contract
| Contract | Who it is for | What you implement |
|---|---|---|
| Mobile IAP | Any game selling through the iOS/Android SDK (Apple / Google billing) | 2 APIs — create order, deliver item |
| Web Payment — Standard | Co-publishing (co-pub) games. Use this unless told otherwise. | 3 APIs — check UID, create order, payment notify |
| Web Payment — Expub | Exclusive/Direct-publishing (expub) games | 4 APIs — character list, check UID, create order, exchange |
Which of the two web payment contracts applies depends on your game's publishing model, not on when it was integrated — co-pub and expub are two different account/character models, not an old and new version of the same thing.
An expub game always implements both Mobile IAP and
Web Payment — Expub — one for the in-app store, one
for the web top-up page; createOrder_url/exchange_url are shared between
them. A co-pub game only adds Mobile IAP on top of Web Payment — Standard if
it also has a mobile app.
On a PHP backend? Don't hand-implement either web payment contract from the table above — install Web Payment — PHP SDK instead. It covers both Web Payment — Standard (three PHP functions) and Web Payment — Expub, including Expub's shared Mobile IAP (four PHP functions) — same contracts either way, just without the field-name/ signature mistakes that come from re-typing them by hand.
Want the web top-up flow rendered inside the game instead of a separate portal page? That's not a fourth contract — see In-Game Top-Up.
How they differ
| Mobile IAP | Web Payment — Standard | Web Payment — Expub | |
|---|---|---|---|
| Signature | MD5 | HMAC-SHA256 | MD5 |
| Header | Signature | x-signature + x-timestamp | Signature |
| Timestamp unit | seconds | milliseconds | seconds |
| Errors reported via | HTTP status | errcode in a 200 OK body | HTTP status |
| Character selection | client-side, in the SDK | player types a UID | Alogame fetches your character list |
Signature verification is documented once, for all three, on the Authentication page.
Rules that apply to every contract
- Production endpoints must use HTTPS with a valid TLS certificate. Dev/staging may use HTTP.
- You register separate URLs per environment. Alogame routes to the correct one with no SDK or client change.
- Product IDs are yours. Send Alogame your product list during onboarding; Alogame configures it and sends the same IDs back to you in
productId. Whatever an ID means in your game is your definition — Alogame never invents one. - Every incoming request must have its signature verified before processing, and stale requests rejected.
- Item delivery must be idempotent. Alogame retries on timeout or error, so a delivery call can legitimately arrive more than once for the same order.
- Respond promptly. Alogame aborts slow requests and treats the timeout as a failure.