Skip to main content
Beta - Payment data is currently in beta. The payload structure may still evolve before general availability. Share your feedback at support@bookingshake.com.

List and get payments

Overview

The payment endpoints expose the payments recorded on your venue’s invoices:
  • GET /payments?invoice_id={id} - list every payment attached to an invoice
  • GET /payments/{id} - retrieve a single payment by its document ID
Both return the same per-payment shape. Useful to reconcile an invoice’s payments on demand, or to back-fill a missed payment.* webhook.
Security deposits (holds) are out of scope - they are excluded from the list and return 404 on the single-get, consistent with the payment webhooks (which never emit for holds). Amounts are integer cents, dates are YYYY-MM-DD strings in the Europe/Paris timezone, timestamps are Unix milliseconds, and missing values are explicit null.

Authentication

All requests require a Bearer token (your BookingShake API key):

List payments of an invoice

GET /payments?invoice_id={id} returns every payment attached to the given invoice. The result is scoped to the authenticated venue, so an invoice that does not exist or belongs to another venue simply returns an empty array.
string
required
ID of the invoice whose payments you want to list - the invoice_id carried by the payment.* webhooks, and the id of GET /invoices/{id}.
The payments are returned wrapped in the standard { message, data } envelope, where data is an array of payment objects (each identical in shape to GET /payments/{id}).

Get a payment

GET /payments/{id} returns a single payment by its document ID, in the same shape as the list items.
string
required
The payment document ID - the id field carried by the payment.* webhooks.

Fields

Amounts are signed: a negative amount with status paid represents a refund - see Refunds. See the payment webhook documentation for the full field reference.

Errors

Out-of-scope payments are never disclosed: the single-get returns a uniform 404, and the list silently omits them - an invoice belonging to another venue returns an empty array, never an error revealing its existence.

Next Steps

Get an Invoice

Retrieve the invoice linked to a payment via invoice_id

Payment Events

Receive payments in real time via the payment.* webhooks

Update a payment

Overview

PATCH /payments/{id} updates a single payment by its document ID. It is a partial update: only the fields you include in the body are modified, everything else is left untouched. The request body uses the same conventions as the response - amount in integer cents, dates as YYYY-MM-DD (interpreted in the Europe/Paris timezone), and status verbatim. So you can read a payment with GET /payments/{id}, change a few fields, and send them straight back.
Updating a payment automatically emits the payment.updated webhook when at least one exposed field changes. Security deposits (holds) are out of scope and return 404, consistent with the payment webhooks.

Authentication

All requests require a Bearer token (your BookingShake API key):

Path Parameters

string
required
The payment document ID - the id field carried by the payment.* webhooks.

Body Parameters

All body fields are optional, but at least one must be provided.
string
Payment label.
integer
Amount in integer cents (e.g., 90000 = €900.00). Must be a non-negative integer.
string
One of waiting, paid, or canceled.
string
Stable ID of a payment method from the venue catalog - see GET /payment-methods. Must reference an active (non-archived) method; the display label stored on the payment is derived from the catalog.
string
Date the payment was received, YYYY-MM-DD. Pass null to clear it.
string
Date the payment is expected, YYYY-MM-DD. Pass null to clear it.

Request

Response

The full payment is returned in its post-update state, wrapped in the standard { message, data } envelope - identical in shape to GET /payments/{id}.
See the Get a Payment reference for the full field descriptions.

Errors

A 404 is returned uniformly whenever the payment is outside your scope, so the existence of another venue’s payment is never disclosed.

Next Steps

Get a Payment

Retrieve a payment before updating it

Payment Events

Receive payment changes in real time via the payment.* webhooks