CUSTOM WORDPRESS INTEGRATIONS
Paid means verified: a Fygaro gateway for FluentCart
A Fygaro hosted-checkout gateway for FluentCart, built for a merchant who needed to take cards without touching them — where the buyer’s return marks nothing, and only a signed webhook can mark an order paid.
2
plugins shipped
9
checks before an order is paid
672
lines of PHP
0
custom tables
| Client | A merchant selling through FluentCart (anonymised at their request) |
|---|---|
| Payment provider | Fygaro — hosted checkout for Visa, Mastercard, American Express and regional methods, with direct bank settlement |
| Challenge | No Fygaro gateway existed for FluentCart, and neither platform documented how to reach the other: the cart’s contract lives in its bundled gateways, Fygaro’s Payment Button holds one redirect URL, and its validator rejects any claim it does not expect. |
| Delivery | The FluentCart gateway and a lighter Fluent Forms gateway, the signed-token checkout redirect, the nine-check webhook verification ladder, merchant settings with encrypted keys, sandbox-to-live verification against a real Fygaro account, a hardening pass, and ongoing maintenance. |
| Stack | WordPress, PHP, FluentCart, Fluent Forms, HMAC-SHA256 JWT, Fygaro Payment Button and signed webhook |
| Timeline | April 2026 |
The merchant is withheld at their request. Endpoint paths and reference formats described here are illustrative equivalents of the real ones.
The challenge
Fygaro’s product is a hosted checkout: the buyer leaves the merchant’s site, pays on Fygaro’s page, and Fygaro calls the merchant’s server back with a signed confirmation. That keeps card data off the merchant’s site — and turns every payment into a conversation between three parties: the buyer’s browser, the store, and Fygaro’s servers. The merchant wanted that conversation to work on FluentCart with nothing custom to babysit: keys pasted from the Fygaro dashboard, no code, sandbox and live modes that cannot be half-configured, ordinary WordPress hosting with no build tooling or new tables — and the same Fygaro checkout for their Fluent Forms order forms. No gateway existed, and neither platform documented how to reach the other.
Three constraints shaped every decision. FluentCart’s gateway contract had to be read out of its own code — the working specification was its bundled gateways plus one reference add-on, and getting the endpoint wrong produces no error: Fygaro’s webhook simply never arrives, the buyer has paid, and the order stays pending. Fygaro’s hosted checkout is strict in two ways: each Payment Button stores exactly one redirect URL, and its token validator rejects any claim it does not expect. And the buyer’s return is not evidence — anyone can load a return URL with any reference, so a gateway that marks an order paid when the browser comes back can be talked into marking anything paid.
What ScalarWP built
ScalarWP built the gateway redirect-only, riding FluentCart’s own machinery — its gateway base class, settings store, key encryption, activity log, receipt page and shared listener — so the integration owns only what nobody else could: the token and the checks. At checkout the gateway signs an HMAC-SHA256 JWT carrying exactly three claims — amount, currency, reference — because Fygaro’s validator rejects anything more, a rule confirmed with Fygaro directly and written into the contributor guide; buyer details prefill the hosted page through ordinary URL parameters instead. If a key, secret or Payment Button ID for the current mode is missing, checkout stops with an error the merchant can read rather than sending the buyer to a broken page.
The first webhook design was dead on arrival — an advertised webhook URL and an admin-ajax return handler that both looked right and were never called. Reading FluentCart’s dispatcher and bundled gateways showed why: the cart routes every gateway request through one shared payment-listener URL. Both jobs moved onto that listener, and since a Fygaro Payment Button stores a single redirect URL anyway, one query flag now decides — no flag, Fygaro’s server is posting a confirmation; flag present, a buyer is coming back. The settings panel prints both URLs, ready to paste into the Fygaro dashboard.
An order becomes paid through one path only: the webhook handler’s nine-check ladder, stopping at the first failure. Well-formed JSON, a reference that matches a strict pattern, a transaction that exists and is not already succeeded, a configured secret, a timing-safe signature check with the token’s reference matched against the body’s, an amount at least the transaction total, a currency match — Fygaro does not convert currency, so a mismatch means a misconfigured Payment Button — and then a re-read to narrow the window between two deliveries arriving together. Duplicates answer 200, because a 4xx would tell Fygaro to keep retrying. The buyer’s return, by contrast, only looks up the reference and safe-redirects to FluentCart’s receipt — it never touches a status.
Around the core: a settings panel with four fields and an enable toggle, the secret encrypted at rest with FluentCart’s key helper, and the gateway tied to FluentCart’s own Store Order Mode so the merchant cannot run live payments against a store that thinks it is testing. A lighter second plugin — 282 lines, built first — registers Fygaro as a Fluent Forms payment method for the merchant’s order forms, with the same signed token. Development ran against Fygaro’s sandbox cards through an HTTPS tunnel, the eight-point checklist ran again against the live Payment Button before go-live, and a dedicated hardening pass with its own pull request added access guards, input sanitisation, safe redirects and a tightened reference pattern — reviewed as security changes, not lost inside feature diffs.
The outcome
- In production for the merchant and maintained by ScalarWP; the same nine checks run in sandbox and live.
- Only Fygaro’s signed webhook can mark an order paid — the path the buyer can reach marks nothing.
- The FluentCart gateway is 672 lines of PHP across 8 files and 5 classes; the Fluent Forms gateway 282 lines across 3.
- Zero JavaScript, zero custom tables, zero REST routes, zero cron jobs — two hooks registered in total.
- Four settings fields with the secret encrypted at rest; 30 translatable strings; 4 commits and 2 pull requests, 20 to 24 April 2026.
What ScalarWP delivered
- The FluentCart gateway: signed-token redirect, shared-listener webhook and return handling, receipts and logging through the cart’s own plumbing.
- The nine-check webhook verification ladder, idempotent against provider retries.
- Merchant settings with encrypted keys, tied to FluentCart’s Store Order Mode.
- The Fluent Forms gateway for the merchant’s order forms.
- Sandbox-to-live verification against a real Fygaro account, the security hardening pass, and ongoing maintenance.
Why it mattered
A payment gateway is a trust boundary: the moment an order can be marked paid by anything other than Fygaro’s signature, the store’s word is worthless. With no documentation on either side, the boundary was proven instead — precedent read from FluentCart’s bundled gateways, a token that carries nothing it does not need, and a ladder that makes “paid” a verified state rather than a page visit. The result is small enough to audit in an afternoon, which for payments is a feature.
Taking payments through a flow nobody documented?
Gateways, webhooks, signed callbacks — we read the contract out of the code and build the integration that treats “paid” as something you can prove.
