ifthenpay | Payments for GravityForms

Security Report Card

Readiness

PHP Compatibility

Categories with Findings

Positive Observations

• All four AJAX handlers (connect, disconnect, activate method, methods table) call check_ajax_referer('iftp_gf_admin') AND current_user_can('manage_options') before any state change.
• Browser return flow is authenticated with a per-entry 32-char random token (wp_generate_password) compared via hash_equals(); forged return URLs for arbitrary entries are rejected.
• Payment-state mutation is strictly separated from render state: setup_submission_state() is explicitly render-only, mutations happen only in callback() and handle_gateway_return().
• Webhook idempotency: already-paid entries cannot transition (terminal-state guard) and cancel/error require whitelist status values.
• All admin-rendered HTML passes through a custom wp_kses() whitelist (kses_admin_html) covering only needed tags/attributes; front-end output uses esc_html/esc_attr/esc_url consistently.
• SQL in FormPaymentInfo::delete_all() and uninstall.php uses $wpdb->prepare() with $wpdb->esc_like() for LIKE patterns and table names from $wpdb->prefix.
• HTTP client enforces sslverify=true, sets timeouts, checks response codes, and never leaks the backoffice key into error messages.
• Backoffice key is format-validated (regex) and verified against the live API before being stored; masked (asterisk-only) values are rejected on reconnect.
• Activation-request emails are rate-limited via a 24-hour per-(gateway, entity) transient cooldown.
• Amount stored at payment creation is the authoritative value; the webhook never trusts the client-supplied amount without matching it, and entry payment_amount is written server-side.
• Feed settings sanitize and clamp expire_days (0–9) server-side, bypassing the client-side-only oninput filter.
• ABSPATH guards present in every PHP file; uninstall.php guarded by WP_UNINSTALL_PLUGIN; declare(strict_types=1) used consistently.
• No PHP named-argument usage anywhere; code matches the declared Requires PHP: 8.2 (match expressions, typed properties are all valid).
• Single-payment-gateway enforcement (competing feed detection at validation time) prevents double-charge scenarios across add-ons.
• Readme includes a complete, well-structured External Services section disclosing exactly what data is sent to ifthenpay and when (setup keys, transaction data, callback payloads) — exceeding the minimum wp.org disclosure requirement.
• Documented architecture avoids storing card/bank data locally; only minimal payment-matching references are stored, reducing PCI scope by design.
• Network requirements are explicitly documented (outbound HTTPS to api.ifthenpay.com / ifthenpay.com), aiding administrators in firewall configuration and reducing misconfiguration-driven failures.
• Strict, modern platform requirements declared (WordPress 6.5+, PHP 8.2+) — running current, supported runtimes.
• Full GPLv3 license text properly bundled with the plugin.
• Changelog and upgrade notices maintained with version history.
• Support section includes pre-checks that reduce credential/configuration exposure in public support channels.
• Security hygiene is strong: AJAX handlers use `check_ajax_referer()` + `current_user_can('manage_options')`, the webhook validates an APK derived from the gateway key via `hash_equals()`, browser returns are authenticated with a per-entry token via `hash_equals()`, and amounts are re-checked server-side before completing payment.
• Admin-rendered HTML is consistently passed through a single `kses_admin_html()` helper, and dynamic output is escaped with `esc_html`/`esc_attr`/`esc_url` throughout.
• API calls are wrapped in try/catch with `wp_remote_*` + `is_wp_error()` handling, JSON decode errors are surfaced as `RuntimeException`, and `sslverify` remains enabled.
• The plugin uses WordPress HTTP/caching APIs (`wp_remote_get/post`, transients) rather than reinventing them, and the optional namespace-scoped autoloader avoids global collisions.
• uninstall.php correctly guards with `defined( 'WP_UNINSTALL_PLUGIN' ) || exit;` and removes options, transients and feed rows on the current site, and the text domain used everywhere matches the plugin header.
• The GPLv3 LICENSE file is bundled and the readme declares 'License: GPLv3' with a matching License URI, satisfying the wp.org licensing requirement.
• An 'External Services' section is present and documents the third-party ifthenpay API usage, the specific data transmitted, the outbound domains requiring allowlisting, and links to the provider's EULA and Privacy Policy — this is exactly the disclosure wp.org reviewers expect for plugins that phone home.
• The privacy FAQ clearly states that no card numbers or full bank details are stored, and that sensitive credentials are stored securely and not publicly exposed — good transparency.
• The requirement list is explicit (WordPress 6.5+, PHP 8.2+, GravityForms active, HTTPS), and there is a concrete troubleshooting note about server firewalls/VPNs blocking outbound HTTPS, which preempts a common support issue.
• Support section offers both a wp.org forum path and a commercial helpdesk, giving users multiple escalation routes.
• The plugin uses native `<button>`, `<input type="checkbox">` and `<select>` elements throughout, avoiding ARIA-role-on-div anti-patterns.
• The `.iftp-gf-message` feedback span on the plugin settings page carries `aria-live="polite"` (Addon.php) and admin.js focuses the input on validation error, a good pattern for the connect/disconnect flow.
• Decorative icons are wrapped with `aria-hidden="true"` (`iftp-gf-box__header-icon`) and images in the admin methods list provide alt text.
• The 'Hide field' editor checkbox uses a proper `<label for="iftp_hide_field">` pairing.
• Evidence of good form labelling on the methods-table checkboxes via a wrapping `<label>` element.
• Admin warning uses the standard `notice notice-warning` classes; errors are surfaced through GF's native validation-message mechanism rather than custom markup.
• readme.txt documents a security-first posture (no card numbers or full bank details stored) and server-side-only HTTPS requests, which reduces the exposure of any future payment-form UI to third-party iframe accessibility debt.
• readme.txt explicitly documents external-service data flows and the EULA/privacy-policy URLs, which is the kind of transparency that also supports the accessibility statement obligations under the European Accessibility Act.
• The plugin delegates rendering of the payment selection field and the payment window to GravityForms and to the hosted ifthenpay payment page respectively — GravityForms' own field rendering has established label/fieldset semantics, which is a favourable starting point once the plugin's own overrides are reviewed.
• Frontend gateway-return handler (handle_gateway_return on template_redirect) returns immediately when the request has no iftp_gf_pay param, so it adds no DB/HTTP load to ordinary page views.
• setup_submission_state is only hooked on `wp` when the return params are present in the request.
• replace_paybylink_merge_tag short-circuits on strpos() before issuing any gform_get_meta lookup.
• Per-form and per-feed snapshots are saved with autoload=false, avoiding wp_options autoload bloat.
• HTTP responses (gateway list + methods catalog) are wrapped in 300s transients and the class statically memoizes API results within a request.
• Scripts/styles are declared via GF enqueue arrays (field_types, admin_page) instead of being enqueued unconditionally on every page.
• The API client always passes an explicit timeout and sslverify=true rather than relying on the 5s default.
• IfthenpayClient caches nothing optional and delegates persistence to the caller, keeping the client testable.