Skip to main content
The SDK exports webhook helper functions from the package root. They are not methods on vivawallet.webhooks; use vivawallet.webhooks for subscription management, and import these helpers when building your webhook receiver.
These helpers are intentionally tolerant. Viva webhook payloads can gain extra fields over time, and some fields differ between event families. The validators check the fields that matter for routing, reconciliation, idempotency, and business expectations; they do not perform strict schema validation.
Soft validation does not replace a server-side confirmation step when your workflow requires one. For payment state changes, you can still retrieve the order or transaction from Viva before mutating critical internal state.

URL verification helpers

When configuring webhooks, Viva can verify your endpoint by expecting your receiver to return a JSON body containing the webhook verification key. Merchant/Marketplace verification uses Key, while ISV verification uses key. Retrieve the key with the client module first:

buildVivaMerchantWebhookVerificationBody(key)

Builds only the JSON body expected by merchant and marketplace webhook verification.
Use this when your framework already controls the HTTP status and headers.

buildVivaMerchantWebhookVerificationResponse(key)

Builds a framework-agnostic response object for merchant and marketplace webhook verification.
The returned object has:

buildVivaIsvWebhookVerificationBody(key)

Builds only the JSON body expected by ISV webhook verification.
Use this with ISV webhook endpoints created through vivaIsv.webhook.create().

buildVivaIsvWebhookVerificationResponse(key)

Builds a framework-agnostic 200 JSON response for ISV webhook verification.

Data Services signature verification

verifyVivaDataServicesWebhookSignature(options)

Verifies signed Data Services webhook notifications, especially Sale Transactions file notifications. It uses the raw request body and Viva’s HMAC headers:
Pass algorithm: 'sha256' or algorithm: 'sha1' to require one algorithm. When omitted, the helper tries Viva-Signature-256 first and falls back to Viva-Signature when only the SHA-1 header is present.
Signature verification requires the raw request body before JSON parsing. Configure your HTTP framework to expose a Buffer, Uint8Array, or string containing the exact bytes Viva sent.
The result includes:

Identity and idempotency helpers

extractVivaWebhookIdentity(payload, headers?)

Extracts envelope identity fields and Data Services headers into one small object for logging, tracing, and routing.
It reads envelope fields such as EventTypeId, MessageId, CorrelationId, Created, RetryCount, RetryDelayInSeconds, RecipientId, and MessageTypeId. It also reads Viva-Delivery-Id and Viva-Event from headers when present. Use this helper to add structured logs before branching on an event. It does not validate that the event is trusted.

getVivaWebhookIdempotencyKey(payload, headers?)

Builds a stable key you can use to deduplicate retries. The helper checks fields in priority order:
  1. MessageId from the Viva envelope.
  2. Viva-Delivery-Id from headers.
  3. Stable event data identifiers such as TransactionId, OrderCode, TransferId, ObligationId, CaptureId, ConnectedAccountId, PersonId, SessionId, CommandId, or BankTransferId.
The result tells you which field was used and whether the key came from the envelope, headers, or event data.

Soft validation pattern

Every validation helper returns VivaWebhookSoftValidationResult<T>:
The payload can be either the full Viva envelope ({ EventData: ... }) or the event data object itself. The optional expectations object lets you verify business values such as order code, amount, status, connected account, wallet, session, or command identifiers.
Decide your HTTP response policy deliberately. Signature failures usually warrant a non-200 response. Soft validation mismatches may be better acknowledged with 200 and quarantined internally if you do not want Viva to retry the same delivery.

Payment result validators

validateVivaPaymentResultWebhook(payload, expectations?)

Generic validator for payment-result style events. It requires OrderCode, TransactionId, StatusId, and Amount, and can compare CurrencyCode when expectedCurrencyCode is provided. Use it when you intentionally handle several payment-result events through one branch.

validateVivaTransactionPaymentCreatedWebhook(payload, expectations?)

Semantic wrapper for Transaction Payment Created. Use it for successful Smart Checkout payment notifications.

validateVivaTransactionFailedWebhook(payload, expectations?)

Validates the same core payment fields and additionally requires ResponseEventId, which is useful for failed-payment diagnostics.

validateVivaTransactionReversalCreatedWebhook(payload, expectations?)

Semantic wrapper for Transaction Reversal Created. Use it for reversal/refund-style transaction notifications where you expect the same core payment-result fields.

Order validator

validateVivaOrderUpdatedWebhook(payload, expectations?)

Validates Order Updated events. It requires OrderCode and IsCancelled, and can compare both with expectedOrderCode and expectedIsCancelled.
Use this event to detect order cancellation updates. Check validation.data?.IsCancelled before treating the order as cancelled.

Connected account validator

validateVivaAccountConnectionWebhook(payload, expectations?)

Validates account lifecycle events for Marketplace and ISV integrations, including Account Connected and Account Verification Status Changed payload shapes. It requires ConnectedAccountId and can compare optional values such as PersonId, PlatformPersonId, WalletId, and Verified.
Use it when syncing seller or connected merchant onboarding status.

Marketplace and obligation validators

validateVivaTransferCreatedWebhook(payload, expectations?)

Validates Transfer Created events. It requires TransferId and can compare transaction, amount, currency, target wallet, target person, and transfer type values.

validateVivaObligationWebhook(payload, expectations?)

Validates deprecated obligation webhook payloads. It requires ObligationId and can compare CaptureId, amount, currency, target wallet, and target person values. Use it only for integrations that still rely on Viva’s deprecated obligation flow.

POS and operational validators

validateVivaPosSessionWebhook(payload, expectations?)

Validates POS ECR session webhooks such as session-created and session-failed notifications. It checks SessionId, TransactionId, StatusId, Amount, and CurrencyCode, and requires at least one stable session identifier: SessionId or TransactionId.

validateVivaTransactionPriceCalculatedWebhook(payload, expectations?)

Validates Transaction Price Calculated payloads. It can compare TransactionId, OrderCode, Amount, and CurrencyCode when you pass expectations. This helper is intentionally lightweight because the event can be used for pricing and fee-related flows where only a subset of fields may matter to your application.

validateVivaAccountTransactionWebhook(payload, expectations?)

Validates Account Transaction Created events. It requires TransactionId and can compare amount, currency, wallet, and account IDs.

validateVivaBankTransferCommandWebhook(payload, expectations?)

Validates Command Bank Transfer Created and Command Bank Transfer Executed events. It checks command, bank transfer, transaction, amount, currency, and wallet fields. At least one of CommandId, BankTransferId, or TransactionId must be present.

Complete receiver sketch

Official webhook references