Understand the gateway key-check implementation caveat
This guide explains that that the internal helper returns true when the stored secret is empty. The guide then takes you through the correct route, the checks to complete before making changes, the workflow in order, and the evidence to review afterwards.
Where to goTechnical review → Ideal_gateway::isGatewayKeyConfigured
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 you’ll accomplish
Know that the internal helper returns true when the stored secret is empty. These instructions follow the supplied module’s live hooks, menus, controllers, forms, model rules and downstream effects.
Follow these steps
- Rely on the settings activation guard and deployment tests.
- Do not bypass normal settings activation.
- Treat this as a supplied-code limitation for future remediation.
Fields and options to review
ImplementationEmpty secret returns true
Compensating controlSettings activation guard checks submitted keys
Category/help-centre/category/stripe-ideal-payment-gateway/
Topic/help-centre/topic/stripe-ideal-security-troubleshooting/
Rules the system enforces
- The helper behaviour is counter-intuitive and should not be represented as successful configuration.
How to confirm it worked
- Understand the gateway key-check implementation caveat 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
- Protect credentials and invoice/payment data.
- Verify Stripe state before any retry or manual finance correction.
Continue with related guidance
Was this guide useful?Your response is stored only in this browser.
