Verification key
Fetch Anyway’s public Ed25519 key and cache it:publicKey is the prefixed raw-key representation, while keys is the equivalent JWKS representation. The delivery envelope follows Standard Webhooks and uses an asymmetric Ed25519 (v1a) signature. Refresh the cached key if verification begins failing after a key rotation.
Events
Current events are:
An empty endpoint event selection subscribes to all supported events, so an existing
endpoint with no selection starts receiving
refund.* events. Return a 2xx for event
types you do not handle, or select events explicitly. Fulfill only after a
verified order.paid. A period-end cancellation is reported through
subscription.updated; use cancelAtPeriodEnd and currentPeriodEnd to represent the
scheduled state before subscription.ended. When refund.succeeded arrives with
fullyRefunded: true, revoke what the refunded order granted. A partial refund
(fullyRefunded: false) is your own policy call; most merchants keep access.
Delivery headers and signed content
The signed message is the exact byte sequence:
Verify Ed25519 signatures
Payload
The signed envelope containstype, RFC 3339 timestamp, apiVersion, endpoint identity,
and data.order or data.subscription, according to the event type. Refund events carry
data.refund together with the refunded order in data.order.
Both order and subscription events use the same product structure. For example, an inline product is returned as:
product.id. The name is a display label, not an entitlement identifier. When neither a product ID nor a name is available, order events return product: null and subscription events omit product.
Important order fields include:
For a payment link opened with
merchant_reference=PUR_456&user_id=USR_123&source=web,
an order event contains the same values:
merchantMetadata. Signature
verification proves that Anyway delivered the payload; it does not make the original
buyer-visible query values suitable for authorization.
Never authorize access solely from merchantMetadata, a buyer note, email, or URL parameter. Compare the order, amount, currency, product, and reference with your own server-side record.
Subscription payload
Subscription events usedata.subscription. Important fields include:
merchantReference and merchantMetadata belong to order payloads. They are not fields
of data.subscription; use subscriptionId to query related orders when you need the
initial checkout context.
Refund payload
Every refund ends in exactly one event:refund.succeededonce the payment provider confirms the money was returned. An order refunded in two parts sends two events, each with its ownrefundId.refund.failedwhen the refund was rejected during Anyway’s review or declined when processed. Nothing was refunded.
data.order is the same order object as in order events, so you can match the refund to your
own records with orderId, merchantReference, or subscriptionId.
data.order.status reflects the order when the refund completed and can still read PAID
right after a full refund. Use the refund fields, not the order status, to decide what to revoke.
Delivery behavior
- Return a
2xxquickly after durable enqueueing. - Each attempt has a 10-second timeout.
- Transport failures,
408,429, and5xxresponses are retried. 3xxresponses and permanent4xxresponses other than408and429are not retried.- Delivery allows up to 12 attempts with exponential backoff capped at one hour.
Retry-Afteris honored for429and503, up to the one-hour cap.- Delivery is at least once and events can arrive out of order.
webhook-id as the delivery idempotency key. Do not let a late pending event regress a
locally paid order or let an older subscription update overwrite newer lifecycle state.