Receive transaction updateswith signed webhooks.

Pementek sends server-to-server webhook events when important transaction changes occur, allowing your application to respond to payments and payouts without depending on customer browser activity.

Webhook events are signed so your backend can verify that the request originated from Pementek before updating your internal transaction or order state.

Why webhooks matter

Payment processing is asynchronous. A customer may leave the checkout page, close the browser or lose connectivity before a transaction reaches its final state.

For that reason, customer-side redirects and frontend messages should not be treated as the authoritative source of transaction success.

Pementek webhooks provide a secure server-to-server channel for delivering transaction updates directly to your backend.

Your backend should use signed webhook events or retrieve the current transaction through the Pementek API before treating a payment or payout as finally completed.

How webhook delivery works

When a relevant transaction state changes, Pementek creates an event and sends it to the webhook endpoint configured for your merchant integration.

Transaction changes

A payment or payout reaches a state that requires a merchant notification.

Event is created

Pementek creates a uniquely identifiable webhook event containing the relevant transaction data.

Event is signed

The outbound request is cryptographically signed using the webhook signing secret.

Your server verifies

Your backend verifies the signature before processing the event.

Webhook endpoint

Your webhook endpoint should be a publicly reachable HTTPS URL controlled by your backend.

For example:

https://example.com/webhooks/pementek

The endpoint should accept HTTPPOST requests containing JSON and should return a successful 2xx response after the event has been accepted for processing.

Avoid performing slow business operations before returning the response. A good pattern is to verify the event, record it safely, acknowledge delivery and process downstream work asynchronously.

Example webhook event

Each event contains an event identifier, event type, creation time and the resource associated with the event.

payment.succeeded

{
  "id": "evt_01JQ8P8X8K9M2X7T4N6A1B3C5D",
  "type": "payment.succeeded",
  "created_at": "2026-10-09T12:42:18Z",
  "data": {
    "transaction": {
      "id": "pay_01JQ8P6M4F8R2V7B1N5K9C3D6E",
      "merchant_reference": "ORDER-847291",
      "status": "SUCCESS",
      "amount": 50,
      "currency": "USD"
    }
  }
}

Verify every webhook signature

Do not trust a webhook request solely because it was sent to your configured endpoint.

Pementek signs webhook deliveries using a merchant-specific webhook secret. Your server should reconstruct the signed payload and compare the expected signature with the signature sent by Pementek.

Signature headers

HTTP headers

Pementek-Timestamp: 1791559338
Pementek-Event-Id: evt_01JQ8P8X8K9M2X7T4N6A1B3C5D
Pementek-Signature: v1=<signature>

The timestamp should be included in signature verification and checked against an acceptable time tolerance to reduce the risk of replaying an old signed request.

Verification example

The following Node.js example demonstrates the general pattern for validating an HMAC SHA-256 webhook signature.

Node.js

const crypto = require("crypto");

function verifyWebhook({
  payload,
  timestamp,
  signature,
  secret
}) {
  const signedPayload =
    timestamp + "." + payload;

  const expected =
    crypto
      .createHmac("sha256", secret)
      .update(signedPayload)
      .digest("hex");

  const received =
    signature.replace("v1=", "");

  return crypto.timingSafeEqual(
    Buffer.from(expected, "hex"),
    Buffer.from(received, "hex")
  );
}

Always verify the signature against the original raw request body. Parsing and re-serializing JSON before signature verification may change the payload bytes.

Webhook event types

Pementek may deliver events for important payment and payout lifecycle changes.

payment.created

A payment transaction has been created successfully in Pementek.

payment.processing

The payment is progressing through routing, customer action or verification.

payment.pending_reconciliation

The payment could not yet be definitively verified and requires additional reconciliation.

payment.succeeded

The payment has been verified and reached a successful final state.

payment.failed

The payment has reached a definitive unsuccessful final state.

payout.processing

The payout has been accepted and is progressing through the payout lifecycle.

payout.succeeded

The payout has been verified and reached a successful final state.

payout.failed

The payout has reached a definitive unsuccessful final state.

Understand transaction status

A webhook event may represent an intermediate or final transaction state.

States such as CREATED,ROUTING,WAITING_FOR_PROVIDER andVERIFYING indicate that transaction processing is still underway.

PENDING_RECONCILIATION means Pementek does not yet have sufficient definitive evidence to declare the transaction successful or failed. It should not be treated as an automatic failure.

Only a final transaction state should trigger final merchant-side fulfillment or financial accounting behavior.

Handle duplicate delivery safely

Webhook delivery follows an at-least-once delivery model. The same event may therefore be delivered more than once.

Your integration should record the unique event identifier and avoid executing the same business action twice when a previously processed event is delivered again.

Webhook handlers should be idempotent. Receiving the same event twice must not cause duplicate order fulfillment, duplicate balance changes or another financial action.

Delivery retries

If your webhook endpoint cannot be reached or does not return a successful response, Pementek may retry delivery according to the platform's webhook retry policy.

Because delivery can be retried, your endpoint should handle repeated events safely and should remain available independently of customer browser sessions.

If webhook delivery is interrupted, you can also retrieve the latest transaction state through the Pementek API.

Do not depend on delivery order

Distributed systems can deliver events at different times, and your application should not assume that webhook events will always arrive in exactly the same order as the underlying transaction transitions.

Use the transaction status contained in the event and, where necessary, retrieve the current transaction from the Pementek API before making an irreversible business decision.

Respond quickly

After successfully validating and accepting a webhook, return a 2xx HTTP response as soon as practical.

Long-running tasks such as order fulfillment, email delivery, downstream API calls or reconciliation work should normally be processed after the webhook has been durably recorded.

Webhook security

Your webhook endpoint is part of your financial transaction infrastructure and should be protected accordingly.

Recommended practices include:

Use HTTPS for every webhook endpoint
Verify every Pementek webhook signature
Verify signatures using the original raw request body
Protect webhook signing secrets
Reject invalid or expired signatures
Process duplicate events idempotently
Do not expose webhook secrets in frontend code
Log event identifiers for operational troubleshooting
Do not use browser redirects as proof of payment

Need help with webhooks?

If you are troubleshooting webhook delivery or signature verification, include the relevant event ID, transaction ID and request context when contacting Pementek.

Never send your webhook signing secret, API key, password or other private credentials in a support message.

Contact Pementek Error Codes