Provider support
Verification applies to a documented signature profile, with explicit authenticated fields and configuration.
Find a profile
The provider directory is the current catalog. Search by name or alias and open the provider’s scheme and official documentation. Only implemented profiles appear in the source form’s provider picker.
Understand what is authenticated
Some schemes sign the original request bytes; others authenticate a timestamp, identifier, a nested payload or a specific set of fields. A valid signature proves only what that scheme covers. Check Signed data and the profile notes before interpreting an event as authentic.
A provider can publish several incompatible webhook products or versions. For example, Adyen’s raw-body header profile does not cover canonical notificationItems signatures. Configure the documented profile instead of substituting a similarly named provider or credential.
Configuration and source state
Sources start active with verification off. Enabling Verify signature reveals a searchable selector and fields for the chosen profile: a secret, public key or structured configuration. Save them together. Changing provider clears drafted credentials; an existing saved configuration can be reused only for the same provider.
Generic capture and providers without an implemented verifier can receive events with verification off. Receiving a request, retaining its body or extracting metadata does not establish a valid signature. Turning verification off does not pause a source or rewrite past results.
Provider-side behavior
Implemented verification describes the incoming request only. The original query is not retained or forwarded, and a destination can have a different URL or path. Acklane does not re-sign deliveries, so a downstream verifier requiring the original query, URL or path cannot assume that the received request has the same signature context.
Provider retry schedules, dashboards and payload formats can change independently. Consult the linked official documentation for the exact product. The catalog does not claim that a real provider account or sandbox delivery has been certified.
Async acceptance responds with a durable 202 acknowledgement. Some providers require HTTP 200 or a special response body and may retry despite successful capture. An implemented signature validator does not certify that the provider accepts this acknowledgement; check its delivery protocol separately.
Acklane does not fetch missing payment objects or translate one provider’s signing scheme into another. Trusted keys and endpoint details come from source configuration. A timestamp window is enforced only where the profile explicitly says so.
Acklane delivery retries are separate from a provider retrying its request to Acklane. A provider retry can create another captured event; no universal deduplication or response-latency guarantee is claimed.