Webhooks

Webhooks are HTTP callbacks that deliver real-time notifications to your server when events occur in your division.

How webhooks work

When an event occurs (e.g., a seller’s KYC status changes), Nuvei for Platforms sends an HTTP POST request to your configured webhook URL. The request body contains a JSON payload with details about the event.

Authentication

All webhook requests are signed using HMAC-SHA512 to ensure authenticity. Each request includes the following headers:

HeaderDescription
x-signatureBase64-encoded HMAC-SHA512 signature
x-timestampISO 8601 timestamp of the request (e.g., 2023-08-21T10:56:59.849101Z)

Verifying the signature

To verify the authenticity of a webhook request:

  1. Construct the data string using the format:

    {webhookUrl}:{accountOwnerCode}:{timestamp}
    

    Where:

    • webhookUrl is your configured webhook endpoint
    • accountOwnerCode is extracted from the request body
    • timestamp is the value of the x-timestamp header
  2. Compute the HMAC-SHA512 signature using your API access token as the secret key.

  3. Base64-encode the computed signature.

  4. Compare the computed signature with the value in the x-signature header.

Verification example

Given:

  • API key: my_super_secret_key
  • Webhook URL: http://my-service.com/api
  • x-timestamp: 2023-08-21T10:56:59.849101Z
  • Body: {"accountOwnerCode": "test account code", "payoutStatus": "REJECTED", ...}

The data string would be:

http://my-service.com/api:test account code:2023-08-21T10:56:59.849101Z

The expected x-signature value:

tMtbhpFv/FIZqrkD75M97wrCLM2Vl381Ou+3UObpYANw8jrZGHUQxuR/2EWcx/ycZAalT4MjtXua1+EdEAgucg==

KYC Status Update

Sent when a seller’s KYC status changes. The webhook contains information about the status change, whether new KYC data is needed, and a hosted onboarding link that can be shared with the seller to collect the necessary data.

Possible statuses:

StatusDescription
MISSING_DATAKYC data is incomplete. Additional data needs to be submitted.
IN_PROGRESSKYC verification is in progress.
ACTIVEKYC has been approved. The seller is fully verified.
FAILEDKYC verification failed.
REJECTEDKYC was rejected.

Sample payload:

{
  "accountOwnerCode": "FD5CM7GKttVTf7Gt7KcTVKU37fx7StTxvcc",
  "kycStatus": "MISSING_DATA",
  "kycMessage": "Missing data for the following fields: address.city, phone, registrationNumber, ubos.address.country, ubos.lastName, address.houseNumber, address.street, ubos.firstName",
  "hostedOnboardingUrl": "https://onboarding.payaut.com?token=eyJhb..."
}
FieldTypeDescription
accountOwnerCodestringThe unique code identifying the seller.
kycStatusstringThe new KYC status. One of: MISSING_DATA, IN_PROGRESS, ACTIVE, FAILED, REJECTED.
kycMessagestringA human-readable message explaining the status, including which fields are missing if applicable.
hostedOnboardingUrlstringA URL that can be shared with the seller to submit or correct KYC data via the hosted onboarding page.

Payout Status Update

Sent when the status of a payout request changes.

Possible statuses:

StatusDescription
WAITINGPayout request is created and waiting for validation (e.g., KYC approval, sufficient balance).
ACCEPTEDPayout will be included in the next payout batch.
PROCESSEDPayout has been paid out to the receiving bank.
RETURNEDPayout was sent but returned by the bank. Funds are added back to the seller’s payout balance.
CANCELLEDPayout request was cancelled. Only possible before processing.
FAILEDPayout request failed (e.g., insufficient balance or KYC not completed).

Sample payload:

{
  "accountOwnerCode": "FD5CM7GKttVTf7Gt7KcTVKU37fx7StTxvcc",
  "payoutStatus": "PROCESSED",
  "payoutCode": "FD5CMdGdJD7gUGVfTtDUU77vYtUSaa37tJ7",
  "payoutMessage": "Payout was requested."
}
FieldTypeDescription
accountOwnerCodestringThe unique code identifying the seller.
payoutStatusstringThe new payout status. One of: WAITING, ACCEPTED, PROCESSED, RETURNED, CANCELLED, FAILED.
payoutCodestringThe unique code identifying the payout request.
payoutMessagestringA human-readable message about the status change.

Transaction Status Update

Sent when a transaction status changes during the reconciliation process.

Possible statuses:

StatusDescription
PENDING_SPLITA PSP report was received, pending split to the transaction.
PENDING_SETTLEMENTA split was received, pending settlement to the transaction.
RECONCILEDTransaction is reconciled — the split matches the correct PSP report item.
CANCELLEDThe split was cancelled, therefore the transaction was also cancelled.

Transaction types: PAYMENT, REFUND

Sample payload:

{
  "originalEventTime": "2024-06-15T10:20:30.638627Z",
  "virtualAccountCodes": [
    "FD5CKXQSMQWnvyP8CQqgjceVLJGbr1Y2DzG"
  ],
  "splitCode": "FD5CKXSctdwrzkUUQCTWGXzKkQDqxRDnq4C",
  "extRef": "order-12345",
  "pspExtRef": "pspExtRef_123",
  "pspMutationExtRef": "pspMutationExtRef_123",
  "type": "PAYMENT",
  "status": "RECONCILED"
}
FieldTypeDescription
originalEventTimestring (ISO 8601)The original timestamp of the event.
virtualAccountCodesarray of stringsThe virtual account codes associated with the transaction.
splitCodestringThe unique code identifying the split.
extRefstringYour external reference for the transaction.
pspExtRefstringThe PSP’s external reference for the payment.
pspMutationExtRefstringThe PSP’s mutation external reference.
typestringThe transaction type: PAYMENT or REFUND.
statusstringThe new transaction status. One of: PENDING_SPLIT, PENDING_SETTLEMENT, RECONCILED, CANCELLED.