Prevent a duplicate webhook payment
Pixie CRM guidance. Follow the route for your workspace, check your role and enabled modules, and verify the result before moving on.
This guide explains the webhook idempotency check.
Where to goStripe webhook → /ideal/webhook
Before you start
- Use the exact navigation above and confirm the intended invoice, case, client, property, document or environment.
- Verify module activation and the stated permission before attempting the action.
- Use a controlled test record for payments, emails, public/portal access, provider calls and deletion.
What this guide helps you do
Understand the webhook idempotency check. These instructions follow the supplied module’s live hooks, menus, controllers, forms, model rules and downstream effects.
Follow these steps
- Allow Stripe retries.
- Check repeated events return HTTP 200 without adding another payment.
Fields and options
Duplicate keyinvoicepaymentrecords.transactionid
Category/help-centre/category/stripe-ideal-payment-gateway/
Topic/help-centre/topic/stripe-ideal-payment-recording/
Rules and limits
- The webhook checks transactionid before addPayment.
Check it worked
- Prevent a duplicate webhook payment completes through the supplied module flow.
- Reopen the source record or settings page and verify the stored value, status, payment, file, timeline entry or notification.
Security, privacy and operational checks
- Use the least-privilege account that has the stated permission.
- Use a controlled test record before applying provider, financial, public-link, email or destructive actions in production.
Related guides
Was this guide useful?Your response is stored only in this browser.