Triggers
Validate and test
Check trigger boundaries and payment readiness before publication.
Testing should prove both what the trigger blocks and what it leaves available.
Configuration review
Confirm:
- The selected tool still exists. Choose the exact technical identifier shown in monospace, not its human-readable title.
- Condition fields match the current tool definition.
- Any quota has a defined unit and counting behavior.
- Amount, currency, and payment type are correct.
- The intended Stripe account is connected.
- User-facing text describes the offer accurately.
Behavior review
Use safe test inputs for:
- A case that should not match.
- The first case that should match.
- Values immediately around a threshold.
- A failed upstream call, when safe to reproduce.
- A returning user case when the payment type grants continued access.
Check the client result and Activity after each case. Do not infer a successful payment configuration from a non-matching call.
Publication applies to the current environment. Make sure the connected payment account and the test you perform belong to that same environment.
If a save is rejected, Gooshi restores the attempted trigger and checkout appearance in the current browser session. Correct the highlighted value and save again; a validation error should not require rebuilding the draft.