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
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 inx-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 theAuthorization: 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 ahash 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.
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 itsv2 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.
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.

