=== RyanPay Card Payments with accept.blue for Formidable ===
Contributors: ryanplugins
Tags: formidable, payment, accept.blue, gateway, credit card
Requires at least: 6.0
Tested up to: 7.0
Requires PHP: 7.4
Stable tag: 1.0.8
License: GPL-2.0-or-later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

Accept credit card payments through accept.blue directly inside your Formidable Forms.

== Description ==

**Secure Form Checkout** connects your Formidable Forms payment forms to the accept.blue payment processing platform. All card data is handled inside a secure accept.blue Hosted Tokenization iFrame — it never passes through your server, keeping your site PCI-compliant.

This is the **free Lite version**.

= What's Included in Lite =

* **Credit card payments** via accept.blue Hosted Tokenization iFrame — card data never touches your server
* **Test / Sandbox mode** — safely test payments with accept.blue sandbox credentials before going live
* **Test Connection** — verify your API credentials without leaving WordPress
* **Debug logging** — dedicated per-month log file with an in-admin log viewer, gated behind a settings toggle
* **card authentication** — optional EMV card authentication browser-based authentication per Form Action
* **Per-form API credential override** — run different forms against different accept.blue merchant accounts
* **Processing overlay** — animated spinner shown on form submit while payment processes
* **Minified assets** — production-ready JS and CSS; source files served automatically when WP_DEBUG is on


= Requirements =

* WordPress 6.0 or higher
* PHP 7.4 or higher
* Formidable Forms Pro (required for payment fields)
* An active accept.blue merchant account (sign up at https://accept.blue)

== Source code ==

The unminified source files for all JavaScript and CSS are included in the plugin's assets/ directory alongside the minified production files. No separate build step is required to review the source.

== Installation ==

1. Upload the plugin folder to /wp-content/plugins/ or install via Plugins > Add New > Upload Plugin.
2. Activate via Plugins > Installed Plugins.
3. Go to Formidable > Global Settings > Accept.Blue.
4. Enter your credentials:
   - API Key — from your accept.blue portal under API Keys
   - PIN — if your API key requires one (optional)
   - Hosted Tokenization Key — from accept.blue Settings > Hosted Tokenization
5. Click Save Changes and use the Test Connection button to confirm your credentials work.
6. Create or open a Formidable Form.
7. Drag the Accept.Blue Card field onto the form canvas.
8. Open Form Actions and add the Accept.Blue Payment action.
9. Set your amount and currency.
10. Click Update and publish your form.

== Frequently Asked Questions ==

= Does this store card numbers on my server? =

No. Card data is tokenised entirely within the accept.blue Hosted Tokenization iFrame. Your server only ever receives a short-lived nonce token. No card numbers, CVVs, or expiry dates are stored on your server or in your database.

= Can I use this in test/sandbox mode? =

Yes. Enable Test / Sandbox Mode in Formidable > Global Settings > Accept.Blue and use your accept.blue sandbox credentials. No real charges are made. Disable the setting and switch to live credentials when you are ready for production.

= What statuses does the plugin use? =

complete — charge captured and settled; auth — authorised but not yet captured; failed — charge declined or errored; voided — authorisation cancelled before capture; refunded — charge refunded in full or in part.

= Does debug logging store sensitive data? =

API request and response bodies are logged when debug logging is enabled. Card numbers are never present (they are handled by the accept.blue iFrame and never reach your server), but disable debug logging once you have finished troubleshooting.

No card data is stored on your server. All sensitive payment data is handled exclusively by accept.blue's PCI-compliant infrastructure.



== External Services ==

This plugin connects to the accept.blue payment processing platform. Two distinct accept.blue services are contacted:

= 1. accept.blue Payment API =

Used to authorise and capture credit card payments. When a visitor submits a payment form, the plugin sends a server-side request to the accept.blue API to process the charge.

Data sent: a short-lived card nonce token (generated by the Hosted Tokenization iFrame — never the raw card number or CVV), the payment amount, currency code, and the site's accept.blue API credentials.

When data is sent: only when a visitor submits a payment form and the tokenization step has completed successfully.

* API endpoint (live): https://api.accept.blue/api/v2/
* API endpoint (sandbox): https://api.sandbox.accept.blue/api/v2/
* accept.blue website: https://accept.blue
* API documentation: https://docs.accept.blue/api/v2
* Terms of Service / Privacy Policy: https://accept.blue/terms-of-use/

= 2. accept.blue Hosted Tokenization Service =

Used to securely capture card details inside an iFrame. When a visitor views a payment form, the browser loads a secure iFrame from accept.blue's tokenization service. The visitor enters their card number, expiry, and CVV directly into this iFrame. That card data is sent from the visitor's browser directly to accept.blue — it never passes through your WordPress server.

Data sent: raw card details (card number, expiry, CVV) sent from the visitor's browser directly to accept.blue's tokenization servers. Your server receives only a short-lived nonce in return.

When data is sent: when the visitor enters card details and submits the payment form.

* Tokenization endpoint (live): https://tokenization.accept.blue/tokenization/v0.3/
* Tokenization endpoint (sandbox): https://tokenization.sandbox.accept.blue/tokenization/v0.3/
* Terms of Service / Privacy Policy: https://accept.blue/terms-of-use/


== Changelog ==

= 1.0.8 =
* Docs: Removed Paay external service section from readme. Replaced all "3D Secure" references with "card authentication".

= 1.0.7 =
* Fix: Added phpcs:ignore annotations for frm_payment_status_complete (Formidable Forms own hook) and $frmProErrors (Formidable Forms core global) — these cannot be renamed as they are part of Formidable Forms API.

= 1.0.6 =
* Fix: All plugin identifiers (functions, classes, constants, options, transients, AJAX actions, script/style handles, shortcodes, DB table) renamed from frm_ab_lite_ / Frm_AB_Lite_ / FRM_AB_LITE_ to ryancapa_ / Ryancapa_ / RYANCAPA_ to satisfy the WordPress.org 4-character unique prefix requirement.
* Fix: Include files and asset files renamed to match new prefix (class-ryancapa-*.php, ryancapa-card.js, ryancapa.css).

= 1.0.5 =
* Fix: Dependency notice (Formidable Forms required) now shown only on the Plugins screen instead of every admin page, complying with Guideline 11.

= 1.0.4 =
* Fix: Card config delivery rewritten to be JS-optimizer-proof. Configs are now collected across all card fields on the page and output as a single `wp_add_inline_script( 'before' )` block that travels with the registered script handle, preventing WP Rocket / Autoptimize / LiteSpeed from stripping or deferring it. `wp_localize_script` retained as a secondary fallback for strict-CSP environments.

= 1.0.3 =
* Fix: Replaced raw inline `<style>` tag in card field output with `wp_add_inline_style()` per WP enqueue best practices.
* Fix: Replaced raw inline `<script>` config output (printf) with `wp_add_inline_script()` per WP enqueue best practices.
* Fix: Added nonce verification (`wp_verify_nonce`) to the log viewer GET handler; all log viewer links updated to use `wp_nonce_url()`.
* Docs: Updated External Services documentation.

= 1.0.2 =
* Fix: Multisite / Network activation — payments table now created for every subsite; settings stored per-site so each subsite has independent API credentials.
* Fix: Card iframe now loads correctly on all themes — CSS overrides prevent themes from collapsing the iframe to zero height; MutationObserver forces visibility the instant the SDK injects the iframe.
* Fix: JS config (ryancapaCardConfigs) output as a direct inline script in form HTML, immune to WP Rocket / Autoptimize / LiteSpeed JS optimizers stripping wp_localize_script data.
* Fix: Nonce refresh via admin-ajax (same session context) instead of REST endpoint, preventing -1 / HTTP 403 errors after authentication challenge.
* Fix: AJAX payment call migrated from jQuery.post() to fetch() with X-Requested-With header, preventing Apache 403 blocks on some server configurations.
* Fix: 10-second ready timeout with actionable error message; HTTP detection shows clear admin notice when page is not HTTPS.
* Tested: Verified working on WordPress Multisite with Network activation.


= 1.0.1 =
* Fixed: Added nonce verification to settings save path in route() to prevent CSRF
* Fixed: Removed recurring, installment, and trial fields from prepare()/get_defaults() — recurring is not implemented in Lite and was dead code
* Fixed: Updated accept.blue Terms of Service and Privacy Policy URLs to correct paths (/terms-of-use/ (contains both terms and privacy policy))
* Fixed: Updated admin upsell notice and readme to accurately reflect which features are in Lite vs Pro
* Fixed: card authentication and per-form API credential override are fully functional in Lite — moved from Pro-only list to Lite feature list
* Fixed: Removed recurring-related JavaScript toggle code from admin panel (no recurring UI in Lite)
* Fixed: Removed screenshot reference to recurring payment settings panel (no such UI in Lite)

= 1.0.0 =
* Initial Lite release based on Pro v1.0.0
* Core credit card payments via accept.blue Hosted Tokenization iFrame (PCI-minimised)
* Debug logging with in-admin log viewer and Clear Log function
* card authentication browser-based authentication per Form Action
* Per-form API credential override for multi-merchant support
* Licensing system fully removed
* All PHP identifiers prefixed with _lite (classes, functions, constants, options, hooks, DB tables)
* Plugin entry file renamed to formidable-acceptblue-lite.php
* All include files renamed to class-ryancapa-*.php
