Captured Payments Are Now Actually Recorded
A defect that let a captured PayPal payment succeed with no corresponding record has been fixed — captured payments now write to a real billing-history table.
We want to be precise about this one, because it's a serious defect and it deserves a precise explanation rather than a vague reassurance.
What was wrong
The PayPal payment-capture endpoint (/api/payments/paypal/capture-order) has always written its result to a billing-history table after a payment was captured. The problem: that table did not exist in the D1 database. Every insert attempt failed. Because the insert was wrapped in a try/catch that logged the failure and continued rather than surfacing an error, the capture flow itself completed successfully from the customer's point of view — the payment went through — while the platform silently kept no record of it having happened.
In plain terms: a customer could be charged, PayPal would confirm the capture, and Piskes' own database would have nothing to show for it.
What was fixed, and when
A migration (0017_finance_revenue_and_billing_history.sql) added the missing billing_history table. Captured payments now write successfully to that table as part of the same capture flow that was already running — no change to the payment logic itself, just the storage it was always supposed to have.
What this means for you
If this affected a payment on your account, it was a recording gap, not a charge gap — the payment itself went through PayPal correctly; what was missing was Piskes' own internal record of it. That gap is closed. Every captured payment from this point forward is recorded in billing_history as part of the capture itself, not as a best-effort afterthought.
We're stating exactly what the migration comment documents and nothing beyond it — if you have questions about a specific historical payment, reach out to support directly rather than relying on this summary alone.