Skip to content
Sections

Guides

Payment callbacks

Report payment-attempt events through a configured provider profile.

Configure access

Use a configured payment-provider profile and the provider key associated with the attempt. Provider secrets stay in the sending server and Hallify configuration. A documented simulator contract is not proof of a certified production provider integration.

The restaurant works with payment attempts in /venues/:venueId/pos. Issuing a provider webhook secret is deployment/provider configuration, not a public self-service key action in the cabinet. Arrange this setup with the Hallify administrator before sending callbacks.

First successful workflow

Follow these steps in order. Open each method for its exact body, required headers and response schema.

  1. Prepare the Hallify payment attempt ID, unique provider event ID, provider status and occurrence time.
  2. Sign stable JSON with the provider UTF-8 secret, RFC3339 timestamp and v1=<hex> signature.
  3. POST to the provider webhook endpoint and check whether the event was applied or recognized as a replay.

State, retries and recovery

Reusing an event identity with another payload is a conflict. An unknown attempt is not created implicitly. A failure reported after capture creates settlement-exception evidence instead of silently reversing captured money.

Hallify uses essential cookies and optional analytics.

Essential cookies keep sign-in, locale, and theme preferences working. Analytics is off until you choose to allow it.