Providers

HMAC-SHA256 v1

Signature verification is implemented. A real provider sandbox delivery has not been certified in this catalog.

Raw-body HMAC-SHA256

Only the raw-body header scheme is implemented; this does not cover every Adyen webhook product.

HMAC-SHA256

Signature verification is implemented. This validator does not enforce a timestamp window.

HMAC-SHA256

Signature verification is implemented. This validator does not enforce a timestamp window.

No signature validator available

Signature verification is not implemented in Acklane. Capture remains available with verification off.

HMAC-SHA256

General webhooks only. Uses the configured secret, never client-secret-key from the request. Remote authorization has a different protocol.

v4 HMAC-SHA256

v4 only. Legacy v3 verif-hash is a static token and is unsupported.

Direct HMAC-SHA256

Worldline Direct profile. Webhook key ID/secret, not API credentials. Unknown key IDs fail.

Merchant v1 HMAC-SHA256

Merchant webhooks. Preserves original bytes; accepts a matching v1 signature during rotation.

HMAC-SHA256 / HMAC-SHA512

Allows HMAC_SHA256_HEX and HMAC_SHA512_HEX only. Deprecated SHA-1 is rejected; no missing-algorithm fallback.

HMAC-SHA256

Uses the team's API key as signing key.

HMAC-SHA512

Current official documentation says sandbox notifications omit the signature. Production-only signed transport cannot be certified here; offline fixtures are possible.

HMAC-SHA256

Gateway notification profile; raw bytes, no whitespace normalization. Volt requires HTTP 200 acknowledgement; Acklane returns 202, so the provider may retry even after durable capture.

HMAC-SHA256

Entrust Identity Verification (formerly Onfido), webhook endpoint token.

HMAC-SHA256

Decision notifications; uses the account auth token. Public provider SDK is the protocol reference.

HMAC-SHA256

Webhook formula excludes HTTP method. URL is trusted configuration, including any configured query; never inferred from Host. Forwarding to a different destination URL does not re-sign the webhook, so a receiver validating against its own URL cannot assume the original signature will pass.

Non-SNAP HMAC-SHA256

Non-SNAP notifications only. Configure exact public notification path without query or fragment. Forwarding can change that path and does not re-sign the webhook; a receiver validating against its own path cannot assume the original signature will pass.

HMAC-SHA256

Plaintext webhook variant only; message-level JWE encryption is unsupported. Configure the digital-signature key, not REST API credentials.

Access Account Payouts HMAC-SHA256

Access Account Payouts profile only. Signature header and key require Implementation Manager enablement.

PGW backend JWT HS256

Authenticates the JWT payload. Only an envelope containing payload is accepted; unsigned SoftPOS outer fields are unsupported. merchantID must match configured merchant.

HMAC-SHA1 with SHA1-derived key

Authenticates encoded XML in bt_payload; form accepts only bt_payload/bt_signature. API public/private key pair; no merchant ID or network call required. HMAC-SHA1 is provider's documented MAC, not an unsigned SHA1 checksum.

HMAC-SHA256 v1

Configured webhook secret from the Fintoc dashboard. Exact UTF-8 body; no JSON reserialization. SDK specifies 300-second tolerance; Acklane also rejects timestamps more than 300 seconds in the future. Requires a Fintoc account for external sandbox delivery; local fixtures do not represent provider delivery.

HMAC-SHA256

Requires the original query and request ID. A body data.id, when present, must match. Other body fields are not authenticated. Fetching authoritative payment details is outside signature validation. Public docs lowercase data.id; the current Go SDK preserves case, so this profile follows the published protocol. The original query is used only for ingress verification and is not retained or forwarded; a downstream receiver cannot reconstruct the original signed query from the delivered request.

Platforms HMAC-SHA256

Platforms notifications only. This does not claim compatibility with other dLocal payout/OAuth or API authentication schemes. dLocal Platforms requires HTTP 200 and can retry for up to seven days; Acklane returns 202, so the provider may retry even after durable capture.

Latam HMAC-SHA256 confirmations

URL-encoded POST confirmation, HMAC mode only. Two different credentials. Other fields are not signed. No MD5/SHA1 fallback; excess nonzero amount precision is rejected.

Colombia SHA256

Only selected values are covered. Event secret differs from API private key. A redundant checksum header, when present, must agree. The published worked example has an inconsistent expected digest; implementation follows the documented SHA256 formula and has not been certified against a provider callback.

v2 Payment Status HMAC-SHA256

Only v2 PAYMENT_STATUS_CHANGED (code 1). Null/absent signed values become empty. Customer/amount/event metadata are not signed. Other event families require their own documented canonicalization.

Charges/authorize HMAC-SHA256

Only charge/authorize for AED, QAR, SAR, USD, EUR, GBP, EGP (2 decimals), BHD, KWD, OMR, JOD (3). No whole-body guarantee. Invoice/refund/payout profiles excluded; excess nonzero precision rejected.

Callback/IPN HMAC-SHA256

Use the profile server key selected for the transaction. This profile excludes browser return forms and their different sorted-form signature.

Payment webhooks HMAC-SHA256

Payment API key, not Secret Key or transfer key. Covers selected fields only. Payout webhooks use a different ordering/encoding/key and are excluded. Kashier requires HTTP 200 or 409 acknowledgement; Acklane returns 202, so the provider may retry even after durable capture.

HMAC-SHA256

URL must exactly match the configured provider notification URL, including query. HTTPS only, no credentials or fragment. Never inferred from inbound Host or forwarded headers.

Signed webhooks HMAC-SHA256

Enable webhook signing in the provider dashboard. Works with signed Checkout raw form bytes and Payment Links JSON bytes. Configured exact HTTPS URL required. Legacy body-only checkout signature is excluded. Peach Payments requires HTTP 200 and can retry for up to 30 days; Acklane returns 202, so the provider may retry even after durable capture. Forwarding to a different URL does not re-sign the original request.

Checkout SHA256

Checkout profile only, signed fields only. Rejects deprecated unprefixed SHA1 notifications. Gateway, payment-link and onboarding profiles differ and are excluded.

HMAC-SHA256

Enable signed notifications with event_signature_key. Preserve original bytes; do not reserialize or strip whitespace before verification.

POST confirmations SHA256

IMPORTANT: response/status/customer fields are not authenticated by this signature. Signed metadata only; do not treat it as proof of successful payment. URL-encoded POST profile; GET/browser flows excluded.

Strong signature HMAC-SHA256

Only the strong signature over the body, following the raw-body PHP example. Timestamp-only X-Kushki-SimpleSignature is rejected. Documentation has JSON serialization inconsistencies; no permissive alternate serialization fallback.

Legacy postbacks v1/v2 HMAC-SHA1

Explicit legacy profile. This does not certify current v5 webhook support. Configure only for documented v1/v2 postbacks.

SHA512

Only order_id, status_code and gross_amount are authenticated. transaction_status, fraud_status, currency and customer fields are not signed. No status lookup or provider callback has been executed.

HMAC-SHA512

CryptoProcessing callbacks only. CoinsPaid requires HTTP 200 or 201 acknowledgement; Acklane returns 202, so the provider may retry even after durable capture. Provider retry behaviour has not been certified.

Embedded Wallets HMAC-SHA256

Embedded Wallets only. Payments API and PaysafeCash use different configurations and are outside this profile.

RSA-SHA256 (PKCS#1 v1.5)

Uses the configured public key; never retrieves keys from incoming URLs. Rotate the source configuration when the provider rotates its key.

ECDSA P-256/SHA256

v2 notifications only, not legacy SNS. A pinned key ID and public key are required; key retrieval and rotation are manual. No incoming certificate URL is trusted.

Charge ID HMAC-SHA256

Only the charge ID is authenticated. Amount, status and other fields are NOT covered; confirm payment state with OpenNode's API. Form-encoded charge callbacks only.

HMAC-SHA512

Transaction Processed callbacks (type TRANSACTION) only. Card token/subscription callbacks and null-valued signed fields are unsupported. Only the selected fields are authenticated. The original query carries the signature but is used only at ingress, not retained or forwarded; a downstream receiver cannot reverify the original signature from the delivered request.

HMAC-SHA3-512

Transaction-status only; not top-ups. Only selected fields are signed. Refunded is encoded as t/f. Quoted or escaped values in signed fields are rejected to prevent ambiguous interpolation.

Payment DMN SHA256

Payment DMNs with SHA256/UTF-8 SiteId configuration only. Pre-deposit approval callbacks, MD5, Control Panel and REST 2.0 are unsupported. Other fields are not authenticated.

Webhook SHA256

Only the documented selected fields are authenticated. Null amount is omitted; numeric zero is included. Unsupported composite values are rejected.

API v3 SHA512

API v3 wallet callbacks only. Uses the configured callback secret and exact incoming body.