Prevent a duplicate webhook payment
Understand the webhook idempotency check.
Exact navigationStripe webhook → /ideal/webhook
Before you begin
- Use the exact navigation above and confirm the intended invoice, case, client, property, document or environment.
- Confirm 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 covers
Understand the webhook idempotency check. These instructions follow the supplied module’s live hooks, menus, controllers, forms, model rules and downstream effects.
Exact step-by-step process
- Allow Stripe retries.
- Verify repeated events return HTTP 200 without adding another payment.
Fields, choices and supported possibilities
Duplicate keyinvoicepaymentrecords.transactionid
Category/help-centre/category/stripe-ideal-payment-gateway/
Topic/help-centre/topic/stripe-ideal-payment-recording/
Code-backed validations and workflow rules
- The webhook checks transactionid before addPayment.
Expected result and verification
- 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.