Events vs. Decision Exchanges | The Penny Inc

Both flows send a JSON POST to a notification endpoint and use the same optional bearer-token and HMAC signing mechanisms. Their purpose and response contracts differ.

	Event delivery	Decision exchange
Purpose	Tell you an event occurred.	Ask your endpoint to approve or decline while authorization is in progress.
Configuration	Subscribe with endpoint `trigger_events`.	Attach a Spend Control `live_decisioning` rule referencing the endpoint ID; no `trigger_events` entry is needed.
Request identifier	`type` such as `card.issued`; also has `category`.	`type: "transaction.authorization"`; request carries authorization details.
Request ID	`event_id`.	`exchange_id`.
Main content	`data` selected by `category`.	`request` with `subject`, `timeout_seconds`, `fallback`, and `authorization`.
Receiver response	Return a 2xx promptly to acknowledge delivery.	Return 2xx with `{"outcome":"approved"}` or `{"outcome":"declined"}` before the timeout.
Failure	Penny retries event delivery; deduplicate by `event_id`.	Penny applies the rule’s fallback on timeout or failure; authorization does not wait for event-style retries.
Inspect later	Event and delivery-history endpoints.	Decision exchange endpoints, with outcome and fallback status.

An event can describe a transaction after it was created or updated; it cannot approve that transaction retroactively. A decision exchange is part of the authorization path and may never be sent if an earlier local Spend Control rule has already declined.

See Event Types and Payloads for the event envelope, Event Catalog for available subscriptions, and Live Decisioning for the full decision request and response.