Skip to main content
Money In Operation — This webhook fires when a customer completes an e-wallet payment, transferring funds into your SingaPay account.

​
Information

MethodPathFormatAuthentication
POSThttps://your-webhook-url/callbackjsonHMAC SHA512 Signature
SingaPay sends a POST request to your configured transaction_notif_url when a customer completes payment via e-wallet native checkout.
This webhook may share a callback URL with other event types. See Shared webhook endpoints for routing by event value.

​
Request Details

​
Headers

FieldValueTypeMandatoryDescription
Content-Typeapplication/jsonAlphabeticYesSpecifies JSON format for the request body
User-AgentSingaPaymentGateway/1.0AlphabeticYesIdentifies the source of the webhook
Acceptapplication/jsonAlphabeticYesExpected response format
X-PARTNER-ID—AlphanumericYesYour API Key from the merchant dashboard
X-Signature—AlphanumericYesHMAC SHA512 signature (128 chars) for request verification
X-Timestamp—NumericYesUnix timestamp in seconds when the request was sent
AuthorizationBearer <random_token>AlphanumericYesSystem-generated random bearer token; used as a component in the signature
The Authorization token for e-wallet webhooks is a randomly generated string — not a user access token. This webhook is triggered by a payment notification (system event), not a user action. Extract the token as-is and use it in the string to sign. See How to Validate Signature below.

​
Body Parameters

​
status
number
required
HTTP Status Code. Example: 200
​
success
boolean
required
Indicates if the transaction was successful. Example: true
​
event
string
required
Event type identifier. Always "ewallet-native-transaction" for this webhook.
​
timestamp
string
required
Event timestamp in format "d M Y H:i:s". Example: "26 Dec 2025 13:35:45"
​
data
object
required
Container for transaction, customer, and payment details.

​
Payload Example

Success
{
  "status": 200,
  "success": true,
  "event": "ewallet-native-transaction",
  "timestamp": "26 Dec 2025 13:35:45",
  "data": {
    "transaction": {
      "id": 42,
      "reff_no": "INV-2026-001",
      "merchant_reff_no": "INV-2026-001",
      "type": "ewallet",
      "ewallet_vendor": "GOPAY",
      "status": "paid",
      "amount": {
        "value": 95000,
        "currency": "IDR"
      },
      "total_amount": {
        "value": 100000,
        "currency": "IDR"
      },
      "post_timestamp": "26 Dec 2025 13:35:43",
      "processed_timestamp": "26 Dec 2025 13:35:45"
    },
    "customer": {
      "name": "John Doe",
      "email": "john@example.com",
      "phone": "081234567890"
    },
    "payment": {
      "method": "ewallet",
      "vendor": "GOPAY",
      "additional_info": {
        "payment_event_id": 1042,
        "vendor_reference_no": "PAY-XYZ-12345"
      }
    }
  }
}

​
Security and responses

Return HTTP 200 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).

​
E-Wallet Specific Notes

total_amount is the gross amount the customer paid. amount is the net amount after fees — this is what gets credited to your balance. Always use total_amount for display to the customer and amount for reconciliation.
The vendor_reference_no field may be null depending on the e-wallet provider’s API response. Always handle null gracefully in your code — don’t assume it’s always populated.
All customer fields (name, email, phone) are optional and depend on the data provided during checkout creation. Your handler should not assume any of these are present.
Both post_timestamp and processed_timestamp use the format "d M Y H:i:s" (e.g. "26 Dec 2025 13:35:45") in Asia/Jakarta (WIB) timezone — not UTC.