Optional webhook — This webhook is completely optional. Products expire normally without it. Configure
product_expiration_notif_url only if you need batch expiration notifications for products (links, VAs, QR codes). For expired unpaid transaction attempts, see Transaction Money-In Expiration.Information
| Method | Path | Format | Authentication |
|---|---|---|---|
| POST | https://your-webhook-url/callback | json | HMAC SHA512 Signature |
POST request to your configured product_expiration_notif_url when payment products reach their expiration time. Unlike transaction webhooks, this is a batch notification that can include multiple expired products in a single call.
Batch notification: One webhook may contain expired Payment Links, Virtual Accounts, and QRIS transactions together. Arrays can be empty when no products of that type expired. If
product_expiration_notif_url is not configured, no expiration webhooks are sent.Request Details
Headers
| Field | Value | Type | Mandatory | Description |
|---|---|---|---|---|
Content-Type | application/json | Alphabetic | Yes | Specifies JSON format for the request body |
User-Agent | SingaPaymentGateway/1.0 | Alphabetic | Yes | Identifies the source of the webhook |
Accept | application/json | Alphabetic | Yes | Expected response format |
X-PARTNER-ID | — | Alphanumeric | Yes | Your API Key from the merchant dashboard |
X-Signature | — | Alphanumeric | Yes | HMAC SHA512 signature (128 chars) for request verification |
X-Timestamp | — | Numeric | Yes | Unix timestamp in seconds when the request was sent |
Authorization | Bearer <random_token> | Alphanumeric | Yes | System-generated random bearer token; used as a component in the signature |
The
Authorization token is a randomly generated string — not a user access token. This webhook is triggered by the system’s scheduled expiration checker, not a user API call. Extract the token as-is and use it in the string to sign. See How to Validate Signature below.Body Parameters
HTTP status code. Example:
200Indicates whether the webhook was sent successfully. Example:
trueEvent type identifier. Always
"product_expiration" for this webhook.Event timestamp in format
"d M Y H:i:s". Example: "26 Dec 2025 14:00:00"Merchant information.
Container for expired products. Each array is always present and may be empty.
Summary counts for the batch.
Payload Examples
Security and responses
Return HTTP200 promptly after validating the request. For retry behavior, see Webhook retry mechanism.
Verify every webhook using Security and signature validation. Use your configured callback path when building StringToSign.
Handle duplicate deliveries idempotently using stable identifiers from the payload (for example transaction_id or reff_no).
Product expiration specific notes
When to use this webhook
Use when
- Automated cleanup of expired products in your system
- Customer notifications for expired payment links or VAs
- Expiration analytics and operational reporting
- Trigger re-engagement flows (new links, new VAs)
- Alert operations on high expiration volumes
Skip when
- You poll product status via API on demand
- Manual monitoring is sufficient
- You need real-time expiration handling (use product APIs or individual webhooks)
Batch notification
This webhook is unique: it batches multiple expired products into one call.- Multiple product types — Payment Links, Virtual Accounts, and QRIS in one payload
- Multiple items per type — Each array can contain many records
- Scheduled execution — Triggered by a system cron job, not real-time
- Efficient — Fewer webhook calls than one notification per product
Processing batch webhooks
Process all expired products
Product types included
| Array | Product | Key fields | Typical action |
|---|---|---|---|
data.payment_links | Payment link pages | id, reff_no, title, expired_at | Resend or create new links |
data.virtual_accounts | Temporary and permanent VAs | id, reff_no, virtual_account_number, expired_at | Archive VA numbers, notify customers |
data.qris_transactions | QRIS payment transactions | id, reff_no, nmid, expired_at | Update lifecycle status |
Simplified payload
The webhook sends minimal fields per product to keep batch payloads manageable. The following are not included:- Amount, currency, payment URL, usage counts
- Bank code (VAs), QR string (QRIS)
- Created or updated timestamps
id or reff_no to fetch full details via the product API when needed.
Timestamp format
| Field | Format | Example |
|---|---|---|
timestamp (root) | d M Y H:i:s | 26 Dec 2025 14:00:00 |
expired_at (per product) | Y-m-d H:i:s | 2025-12-26 14:00:00 |
X-Timestamp (Unix seconds in the header), not the body timestamp field.
Parse timestamps
Access token format
TheAuthorization header contains a random system-generated token, not a user JWT. Extract it normally and include it in the string to sign.
Idempotency
Use a batch-level identifier to avoid reprocessing the same scheduled run:Summary statistics
Scheduling and timing
- Triggered by a system cron job (typically hourly or daily — confirm schedule with SingaPay support)
- Batches all products that expired since the last check
- Not real-time — plan for a delay between expiration and notification
Use cases
Automated cleanup — Archive expired VAs and remove them from active lists. Customer re-engagement — Follow up when payment links expire; issue new links where appropriate. Analytics — Generate expiration reports usingsummary counts by product type.
Operations monitoring — Alert when total_expired exceeds historical averages.