Operations
Day-to-day checks for a self-hosted vantezzen/pay instance.
vantezzen/pay sits in the payment path, so operate it like a small billing service.
Routine checks
- Webhook events are being processed.
- Orders move from pending to paid after checkout.
- Provider webhook secrets are present.
- Provider service healthcheck returns OK.
- Database backups are running.
- Signup access is locked down if the instance is private.
- Consuming apps use the correct publishable key and base URL.
Webhook replay
The dashboard webhook log includes replay for stored verified payloads. Use it when provider delivery succeeded but fulfillment failed because of a temporary issue.
Replay is idempotent for normal payment events, so repeated replay should not duplicate credits.
Rate limits
Publishable-key endpoints and anonymous wallet creation use Postgres-backed
token buckets stored in rate_limit_buckets. Limits are shared across app
instances, and concurrent requests for the same key spend from the same row.
Because rate limiting depends on Postgres, database health is part of API abuse
protection. Monitor database availability and growth of the rate_limit_buckets
table on high-traffic instances.
Common fixes
| Symptom | Check |
|---|---|
| Checkout cannot start | Product has an active synced price and provider account. |
| Checkout returns provider error | Provider service is reachable and PAY_PROVIDER_SERVICE_SECRET matches on both services. |
| Paid checkout did not credit wallet | Provider webhook endpoint and signing secret. |
Browser app gets 403 Origin not allowed | Project allowed origins include the app origin. |
Users see Insufficient credits | Purchase UI is visible and prices are active. |
| Secret key works in dashboard but not app | Secret keys must stay server-side; browser code needs publishable keys. |
Upgrades
After pulling code changes:
- Review environment changes.
- Run migrations.
- Deploy.
- Complete a small test checkout.
- Check the webhook log.