Skip to main content
Your webhook endpoint is public, so anyone can call it. TapiPay offers several mechanisms so you can check that each request comes from TapiPay before processing it. You can enable one or combine several.
Security is not configured through the API. You must contact the TapiPay team directly to request a security configuration. Until you do, your webhooks arrive with no mechanism enabled.
This page applies to the bank debit, card, order creation, order payment and payment method registered webhooks. The payment notification is sent by another platform and its mechanisms are on that page.

The mechanisms

Combine at least two, for example fixed headers plus an IP allowlist, or a bearer token plus the encrypted hash. A single header-based mechanism is vulnerable if the value leaks.
The notificationType header always arrives, with the same value as the type in the body. It is for routing, not for authentication.

Fixed headers

TapiPay adds the headers you agree on to each request, with a fixed value. The most common case is an API key in x-api-key.
  • What you provide: the name and value of each header, through the secure channel the TapiPay team indicates.
  • What you validate: that the header comes and that its value matches the one you provided. Compare in constant time so you do not leak the value through timing differences.
  • Rotation: to change the value, agree on the date and time of the change with the TapiPay team. During the change window, accept both the old and the new value.

Bearer token

TapiPay sends a token in the Authorization: Bearer <token> header. There are two variants: In the OAuth 2.0 variant, your endpoint validates the token like any other one your authorization server issues: signature, expiration and audience.

Encrypted hash

TapiPay includes a hash field in the body, encrypted with the RSA public key you provide. Only you can decrypt it, with your private key. In v2, operationId is the identifier of that notification: the id field in the order and payment method registered webhooks, and the operationId field in the bank debit and card ones. Check that they match: this way a hash copied from another notification does not validate this one.
The hash does not sign the payload. It proves that TapiPay built the request for your integration, but not that the rest of the body was not altered on the way. Combine it with another mechanism.
If you did not provide a public key, the hash field arrives anyway, with value null. The version (v2 or default) is set when your integration is configured: ask for v2. To generate the key pair:

IP allowlist

TapiPay can provide you with the list or ranges of IPs the webhook requests come from, so your endpoint accepts only those IPs. Request it from the TapiPay team for each environment (staging and production).
Ask to be notified before any change to that list. A new IP your allowlist does not know makes you reject legitimate webhooks.

Example: validating a request

The right order in your handler is: validate the origin, answer 2xx quickly and only then process. This example combines a fixed header with the encrypted hash in its v2 version.
In the default version of the hash, the decrypted content is only your integration user: compare it directly with CLIENT_USERNAME, without JSON.parse.

Retries after a rejection

If your endpoint does not answer 2xx, TapiPay retries the delivery a limited number of times over the following minutes and then stops retrying. A rejection because of credentials (401 or 403) is also retried, but it keeps failing until the configuration is fixed.
Test the configuration in staging before going to production. If a mechanism is misconfigured, for example a header with a different value, your endpoint rejects every webhook and the notices of that period are lost. If you start rejecting webhooks you expected, contact the TapiPay team.

How to request the configuration

1

Choose the mechanisms

Decide which mechanisms you want to combine and for which environments: staging, production or both.
2

Contact the TapiPay team

Request the configuration and indicate the mechanisms and the webhooks you receive. The order and payment method webhooks share a single configuration; ask for the security to cover all the groups of webhooks you receive, so none of them arrives without it.
3

Provide the data through a secure channel

Provide the values (headers, tokens, credentials, public key) through the channel the TapiPay team indicates. Never send a secret by email or chat in plain text. The public key is not a secret.
4

Test in staging

Check that your endpoint accepts the staging webhooks with the mechanisms enabled before requesting the same configuration in production.