Mint receipt token
Payment Intents
Mint receipt token
Mint a read-only, reusable receipt token so the SDK can reopen the authoritative receipt for a past payment.
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.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 tohttps://api.zennopay.com in
production. The legacy api.zennopay.in hosts are still served for existing
integrations. See Environments.
Response