Skip to main content
POST
Mint receipt token
Reopening the authoritative receipt for a past payment needs a receipt token — a read-only credential the SDK sends as Authorization: Bearer on GET /receipt. Like the session token, Zennopay mints it; you request one with a single HMAC-signed call for an intent you own. There is no request body. The token’s sub is derived from the stored intent’s partner_user_id — you don’t supply it. That makes the token user-scoped: it can open any of that user’s receipts within its window, but no one else’s. See Reopen a receipt for the full SDK flow.

Headers

Server-to-server only; HMAC-signed. See Authentication.
string
required
Identifies which signing key was used.
string
required
ISO-8601 / RFC 3339 UTC timestamp. ±5 minute skew.
string
required
Random 32-byte hex string (64 chars). Replays within 10 minutes are rejected.
string
required
Base64 HMAC-SHA256 of the canonical request string. The body is empty, so the body-hash line of the canonical request is the empty string.

Path parameters

string
required
The intent whose user should be able to reopen receipts, e.g. zp_AbCd1234EfGh5678. The partner identified by the HMAC key must own it.
No existence leak. If the intent isn’t yours — a cross-partner id or an unknown id — the response is an identical 404. It does not distinguish “doesn’t exist” from “not yours”.

Response

string
A Zennopay-minted, read-only receipt token (aud: zennopay-receipt). Return it to your app; the SDK sends it as Authorization: Bearer on GET /receipt. Reusable — the SDK reuses it to poll a pending receipt to a terminal state.
integer
Unix epoch seconds at which the token stops verifying (TTL 300s).

Example

Example uses the sandbox host. Swap to https://api.zennopay.com in production. The legacy api.zennopay.in hosts are still served for existing integrations. See Environments.
Response