Peach Payments
Verification available
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.
Signature scheme
- Algorithm
- Signed webhooks HMAC-SHA256
- Signature
- X-Webhook-Timestamp; X-Webhook-Id; X-Webhook-Signature
- Signed data
- timestamp.webhook-id.configured-url.original-body
- Encoding
- hex
- Timestamp
- Signed Unix seconds; no freshness window enforced
Configure verification
Create or edit a source, enable Verify signature and search for Peach Payments. The source remains active independently of this switch. Save the provider and its configuration together.
Copy the exact ingress URL from your source when configuring the sender. Save every required field together; saved configuration is encrypted and never returned in source reads.
- Webhook signing secret (
key) (required). - Exact webhook URL (
url) (required).
For API clients, encode these fields as one JSON object inside the signing_secret string. The dashboard assembles it from the fields above.
Inspect the recorded valid, invalid or not-checked signature result after sending a new event. Changing configuration does not change historical results; replay preserves the original bytes and does not re-sign the webhook.
Capture, delivery and acknowledgement
Verification availability describes the inbound validator. The original incoming query string is not retained or forwarded, and the destination URL or path can differ from the signed request. Acklane does not re-sign deliveries; schemes using that original context may not be verifiable again at the destination.
With async enabled, a failed signature may still be captured and retained, but does not become eligible for signature-on delivery. Replay requires current source eligibility, preserves the event ID and original content, and creates a separate delivery history.
Async capture returns 202 after durable acceptance. A provider that requires HTTP 200 or a special acknowledgement may retry; an implemented validator does not establish compatibility with its acknowledgement rules. No real provider sandbox delivery is certified by this catalog.