Optional webhook — This webhook is completely optional. Payment links work normally without it. Configure
payment_link_inquiry_notif_url only if you need view or expiry notifications. For completed payments, use the Payment Link Transaction webhook instead.Information
| Method | Path | Format | Authentication |
|---|---|---|---|
| POST | https://your-webhook-url/callback | json | HMAC SHA512 Signature |
POST request to your configured payment_link_inquiry_notif_url when:
- A customer opens or views a payment link (
payment_link.inquiry) - A payment link history record expires (
payment_link.inquiry.expired)
Separate URL: Unlike money-in transaction webhooks on
transaction_notif_url, inquiry events use a dedicated payment_link_inquiry_notif_url. If this URL is not configured, no inquiry webhooks are sent. For batch product expiration, see Product Expiration. For batch unpaid transaction expiration, see Transaction Money-In Expiration.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 a system event (link opened or session expired), 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.
payment_link.inquiry when a link is opened; payment_link.inquiry.expired when a history session expires.Event timestamp in format
"d M Y H:i:s". Example: "26 Dec 2025 13:35:45"Container for payment link and history details.
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).
Payment Link Inquiry specific notes
When to use this webhook
Use when
- Track views and engagement on payment links
- Monitor conversion (views vs completed payments)
- Alert when high-value links are accessed
- Detect abandonment when inquiry sessions expire
- Trigger follow-up when email was captured but payment was not completed
Skip when
- You only need completed payment notifications (Payment Link Transaction)
- You do not need view or inquiry tracking
- Simple payment links without analytics requirements
Event types
| Event | When it fires |
|---|---|
payment_link.inquiry | Customer opens or views the payment link; creates a payment_link_history with status pending |
payment_link.inquiry.expired | Inquiry session timeout reached; payment_link_history status becomes expired |
Data structure
The payload contains two objects:payment_link_history— This inquiry or payment attempt (unique per link open)payment_link— Parent link configuration and usage counters (current_usage/max_usage)
Handle inquiry and expired events
Customer data handling
Customer fields inpayment_link_history may be null on initial inquiry and populated after the customer submits the form or selects a payment method. Always check for null:
Timestamp format
| Field | Format | Example |
|---|---|---|
timestamp (root) | d M Y H:i:s | 26 Dec 2025 13:35:45 |
payment_link_history.*_at | Y-m-d H:i:s | 2025-12-26 13:35:45 |
payment_link.*_at | Y-m-d H:i:s | 2025-12-20 10:00:00 |
X-Timestamp (Unix seconds in the header), not the body timestamp field.
Parse body timestamps
Access token format
TheAuthorization header contains a random system-generated token, not a user JWT:
Idempotency
Usepayment_link_history.reff_no to detect duplicate deliveries:
