> ## Documentation Index
> Fetch the complete documentation index at: https://storekit.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Payout Reconciliation Sheet
> Track every storekit payout in a ledger keyed by svix-id, with a reconciled tick-box and CSV export, fed by the payments.payout.created webhook.
Every payout storekit sends to your bank becomes a row in your own ledger the moment it is created: amount, currency, which bank account, and when to expect it. Tick each row off as it appears on your bank statement, and download the month as CSV for your accountant.
The dashboard lists payouts under **Analytics** → **Accounting** → **Payouts** (see [How payouts work](/docs/payouts/overview)). Build this recipe when you want your own reconciliation state (ticked off, notes, expected-vs-arrived), an export shaped for your bookkeeping software, or a Slack nudge when a payout is due.
## How It Works
1. storekit sends `payments.payout.created` to your app when a payout is created.
2. Your app adds a row per payout with the total by currency, the last four digits of the bank account, and the estimated arrival date.
3. You tick rows off against your bank statement; anything past its arrival date and still unticked is highlighted.
## What You Need
* Webhooks enabled on your storekit plan (**Settings** → **Developers**).
* A [Replit](https://replit.com) account — the ledger needs a database and a URL that stays up.
* Optional: a Slack incoming webhook URL for a weekly "still not reconciled" reminder.
## Step 1: Build the App
Paste the whole block into the builder in a single message.
Either button opens the builder with the whole prompt below already filled in. Nothing starts until you press send, so read it through and edit the parts marked as yours first.
```text theme={null}
I want a small private web app that keeps a ledger of the payouts storekit sends to my bank account, so I can reconcile them against my bank statement. storekit tells the app about each payout by webhook. The app must never lose a payout, never record the same one twice, and never make storekit wait.
Build it with a database so the ledger survives restarts and an always-on public HTTPS URL.
```
```text theme={null}
CONTEXT ABOUT STOREKIT
I run a hospitality business on storekit (storekit.com), an online ordering and payments platform for restaurants, cafés and bars. storekit can notify my own app about things that happen in my store by sending webhooks.
How storekit webhooks work:
- Each event is an HTTP POST with a JSON body to a URL I register in the storekit dashboard.
- The body always has the shape { "event": "", "data": { ... } }.
- Requests are signed with Svix. Every request carries the headers svix-id, svix-timestamp and svix-signature. Verify them with the official `svix` library for your language, using a secret I will provide in an environment variable called STOREKIT_WEBHOOK_SECRET. Reject anything that fails verification with HTTP 400.
- My endpoint must respond with a 2xx status within 15 seconds. Save the event to the database first, respond 200, then do the work from the saved copy.
- Once I have responded 200, storekit will not send that event again, so the work must not be lost: store each event with a status (pending, done, failed) and only mark it done after the work has actually succeeded. On startup and on a timer, pick up anything still pending or failed and retry it. Never do the work only in memory after responding.
- The same event can occasionally be delivered more than once. Use the svix-id header as the unique key for the saved event: a repeat of an event already saved is ignored, whatever its status.
- Any page or endpoint protected by a password must be served over HTTPS only; redirect or refuse plain HTTP.
- Money fields (total, tip, deliveryFee, discountTotal, item price, modifier price) are integers in minor units: 2500 means £25.00.
- orderType is one of Delivery, Pickup, InStore, Curbside, CateringDelivery, CateringPickup or Billpay.
- table and deliveryAddress can be null. notes can be null or empty.
Example order.created payload:
{
"event": "order.created",
"data": {
"id": "ord_abc123",
"code": "A1B2",
"asap": true,
"total": 2500,
"tip": 250,
"deliveryFee": 299,
"discountTotal": 0,
"orderType": "Pickup",
"createdAt": "2024-01-15T10:30:00Z",
"deliveryTime": "2024-01-15T11:00:00Z",
"notes": "Ring doorbell",
"customer": {
"firstName": "John",
"lastName": "Doe",
"email": "john@example.com",
"phone": "+44123456789",
"marketingConsent": true
},
"items": [
{
"name": "Margherita Pizza",
"price": 1200,
"quantity": 1,
"plu": null,
"posId": null,
"taxRate": null,
"modifiers": []
}
],
"venue": {
"id": 1234,
"name": "My Restaurant",
"slug": "my-restaurant",
"address": {
"street1": "123 Main St",
"street2": "",
"city": "London",
"postCode": "W1A 1AA",
"country": "UK",
"companyName": "My Restaurant Ltd",
"coordinates": { "latitude": 51.5074, "longitude": -0.1278 }
}
},
"table": {
"id": "tbl_123",
"name": "Table 5",
"covers": 4,
"posId": "pos_tbl_5",
"area": { "id": "area_1", "name": "Main Floor", "posId": null }
},
"deliveryAddress": {
"street1": "456 Oak Ave",
"street2": "Flat 2",
"city": "London",
"postCode": "E1 6AN",
"country": "UK",
"coordinates": { "latitude": 51.5155, "longitude": -0.0722 }
}
}
}
The full list of event types and payloads is at https://storekit.com/docs/developers/webhooks/webhook-events
```
```text theme={null}
THE EVENT THIS APP USES: payments.payout.created
Ignore the order example above; this app only cares about payments.payout.created, which looks like this:
{
"event": "payments.payout.created",
"data": {
"amounts": [
{ "currency": "GBP", "value": "3210.50" },
{ "currency": "GBP", "value": "1030.00" }
],
"bankAccount": {
"id": "db97e205-105c-42ff-8460-d06c25cb6830",
"IBAN": "GB15HBUK40127612345678",
"accountNumber": "0001234",
"branchCode": "001234",
"currency": "GBP"
},
"estimatedArrivalDate": "2024-01-17"
}
}
Important differences from the order events:
- Money here is NOT in minor units. Each value is a decimal string in major units: "3210.50" means 3,210.50. Parse it as a decimal, never as a float you then round — use a decimal library or store it as a string and sum with integer pence.
- amounts is a list. Sum the values per currency; a payout usually has one currency but do not assume it. Show each currency total on the row.
- The payload has no payout id and no store name. Use the svix-id header as the unique key for the row.
- bankAccount contains full bank details. Store only the last four characters of accountNumber (or of IBAN if accountNumber is missing) and the bankAccount.id. Do not store or display the full IBAN or account number anywhere, including logs.
- estimatedArrivalDate is a date (YYYY-MM-DD) and may be null.
WHAT TO BUILD
1. POST /webhooks/storekit — verify the Svix signature with the official svix library and STOREKIT_WEBHOOK_SECRET against the raw request body; 400 on failure. Save the row and return 200 immediately. Ignore any svix-id already saved. Handle payments.payout.created; save and acknowledge any other event type but do nothing with it.
2. A ledger table with: received time (UTC, display in TIMEZONE), amounts per currency, bank account last four, bank account id, estimated arrival date, reconciled (yes/no), reconciled on, statement reference (free text), notes (free text).
3. GET / — protected by HTTP basic auth with ADMIN_PASSWORD. A table of payouts newest first with a month filter (default: current month), showing the columns above. Each row has a Reconciled tick-box and editable statement reference and notes fields that save without a page reload. Rows whose estimated arrival date is more than 2 working days in the past and are not reconciled are highlighted amber. Above the table: total paid out this month per currency, total reconciled, total outstanding.
4. Download CSV for the filtered month, one row per payout, columns: received_date, currency, amount, bank_last4, estimated_arrival, reconciled, reconciled_on, statement_reference, notes. Amounts as plain decimals with two places and no currency symbol so bookkeeping software imports them cleanly. If a payout has more than one currency, write one CSV row per currency.
5. Optional weekly reminder: if SLACK_WEBHOOK_URL is set, every Monday at 09:00 in TIMEZONE post "N payouts totalling X not yet reconciled, oldest from ", or nothing if there are none. Skip entirely if the variable is unset.
6. GET /health that returns 200 and { "ok": true } and nothing else.
DEFINITION OF DONE
- [ ] The example payload above creates one row showing 4,240.50 GBP with estimated arrival 17 Jan 2024.
- [ ] The same event delivered twice creates one row.
- [ ] A bad signature returns 400 and records nothing.
- [ ] Nothing in the database, page or logs contains the full IBAN or account number — only "5678" style last-four values.
- [ ] Ticking Reconciled saves immediately and survives a reload and a restart.
- [ ] The CSV opens in a spreadsheet with amounts as numbers.
- [ ] A payout with an estimated arrival a week ago and not reconciled is highlighted.
WHAT TO GIVE ME WHEN YOU ARE DONE
1. The public webhook URL (…/webhooks/storekit) and the ledger URL.
2. The environment variables to set (STOREKIT_WEBHOOK_SECRET, ADMIN_PASSWORD, TIMEZONE, optionally SLACK_WEBHOOK_URL) and where to set them on this platform.
3. Confirmation that the app stays up 24 hours a day.
```
## Step 2: Connect storekit
In the dashboard sidebar, go to **Settings** → **Developers** and click **Manage Webhooks** (it reads **Enable Webhooks** the first time). Webhooks are a subscription feature — if you see **Upgrade to enable webhooks**, [contact support](/docs/getting-started/contact-support) first.
In the embedded portal, add a new endpoint, paste the webhook URL your app builder gave you, and tick only the event types the recipe needs.
Open the endpoint you just created and copy its signing secret. In your app builder, save it as the environment variable `STOREKIT_WEBHOOK_SECRET` (builders call this "secrets" or "environment variables"). Redeploy if the builder asks you to.
Use the portal's test option on the endpoint to send a sample event. The delivery log shows the response code from your app. A `2xx` means your app accepted it; anything else, read the response body in the log — it is usually a missing secret.
Tick only `payments.payout.created` for this endpoint. Use the portal's test option with that event type to create your first row.
## Step 3: Reconcile
When the next real payout lands, compare the row against **Analytics** → **Accounting** → **Payouts** in the dashboard and against your bank statement, then tick it off. Payouts follow your [payout schedule](/docs/payouts/payout-schedule), so the first real row may take a few days.
## Ideas
* **Send to your accountant automatically**: ask the builder to email the month's CSV on the 1st via a provider such as Resend or Postmark.
* **Match by amount**: paste a bank-statement CSV in and let the app suggest matches by amount and date.
* **Multiple stores**: run one endpoint per storekit account and add a "store" label from an environment variable so the ledger can be merged.
## What This Does Not Do
* **It does not explain what is inside a payout.** The event has the totals, not the orders, fees or refunds behind them; use the [fee report](/docs/guides/reports/fee-report) and [transactions report](/docs/guides/reports/transactions-report) for that.
* **It starts from the day you connect it.** Earlier payouts are in the dashboard, not the event stream.
* **It is not proof of payment.** The event says a payout was created; whether and when it arrives is between the payment provider and your bank.
* **It is your service.** storekit support can confirm the event reached your URL and the response code; the ledger and export are yours.
## Related
The full payload, including the fields this recipe deliberately does not store.
Timing, fees and where payouts appear in the dashboard.
The structure behind this prompt, and what to say when the builder gets it wrong.
What was deducted before the payout.
## Related topics
- [Build Your Own Tools on storekit](/docs/guides/build/overview.md)
- [Payout Schedule](/docs/payouts/payout-schedule.md)
- [How storekit payouts work: timing, fees, and verification](/docs/payouts/overview.md)
- [Sales and accounting reports in storekit](/docs/guides/reports/overview.md)
- [Refunds & Payouts](/docs/guides/payments/refunds-payouts.md)
Build with Lovable