Security Deposits API
Create a card authorization link for a booking, send it through your own guest communication system, and synchronize its status using signed webhooks. All endpoints require an OAuth bearer token. Usebilling.write to create, capture, or release deposits and billing.read to retrieve them.
Create a deposit link
authorization_url. Send this URL to the guest. Repeating the request with the same Idempotency-Key returns the original deposit instead of creating a duplicate.
Retrieve deposits
status and per_page. Available statuses are pending, authorized, partially_captured, captured, released, expired, and failed.
Dashboard labels and authorization attempts
The dashboard uses more descriptive labels without changing these API status values:
Authorization-attempt metadata is provider-confirmed where available. Its absence does not prove that a customer has never opened a link. The new dashboard labels are not accepted as
status query parameters; use the API values above.
Capture or release
Capture the full remaining amount by omittingamount, or capture part of it:
Webhook events
PayRequest sendsdeposit.created, deposit.authorized, deposit.partially_captured, deposit.captured, deposit.released, deposit.expired, and deposit.failed to the webhook URL configured under Settings β API & MCP.
A final partial Stripe capture emits deposit.captured, not a promise that another capture remains available. Updates to pending authorization-attempt metadata do not introduce new deposit webhook event names. Retrieve the deposit to read the latest metadata.
Verify the X-PayRequest-Signature header using the configured webhook secret. The signature format is sha256= followed by the HMAC-SHA256 digest of the raw request body. The X-PayRequest-Event header contains the event name.
Card authorizations expire. Create the link close enough to check-in for the selected payment providerβs authorization window.