Case study · Client under NDA
Payments readiness
A store in a regulated, high risk vertical taken from a failing processor audit to 15 of 18 requirements passing.
- Role
- Sole developer
- Status
- Delivered
- Stack
- CodeIgniter 4, React 19, Pay by bank, HMAC SHA256 webhooks, GDPR policy pages
- Scale
- 15 of 18 processor requirements passing
18 point readiness checklist
Summary
- Problem
- Payment processors reject most applicants in this vertical, and the store was failing the processor's readiness audit.
- System
- The full requirement checklist worked in code and content: six EU policy pages generated from business settings, a consent gate, and a native pay by bank gateway with HMAC signed webhooks.
- Outcome
- 15 of 18 requirements passing. The other three wait on the client's live merchant credentials, legal review and go live.
What needed to exist
A store a payment processor would approve.
One deployment of the headless commerce platform served a regulated, high risk vertical, where payment processors reject most applicants. I ran the store through the processor's full requirement checklist and closed every gap that code and content could close.
Constraints
Some requirements belong to the client, not the code.
Three of the requirements depend on the client's live merchant credentials, legal review and go live. The work had to get everything else to passing, and leave those three ready for the moment the client completes them.
Architecture
A new rail on the same contract as the card gateways.
The store runs on the same CodeIgniter 4 and React stack as the rest of the platform, so the new pieces had to fit the existing order flow rather than sit beside it.
Decisions
Policy text the business can edit, and a new rail held to the card contract.
Render the policy pages from business settings
- Context
- The processor requires a full set of EU policy pages with the business's own details.
- Tempting answer
Write the legal text once and bake it into the templates.- What I did
- Generated the policy pages into the CMS and rendered them from the business settings at request time.
- Why
- The legal text stays editable, and a change to the business details reaches every page at once.
The pay by bank rail was built from scratch in CodeIgniter to the same contract as the card gateways: HMAC SHA256 signed webhooks, fail closed verification and server side repricing. A new rail passes the same checks as Stripe, Mollie and Viva Wallet before it can mark an order paid.
Hard problems
Reading as legitimate to an underwriter.
-
HP.01
EU policy pages
Six policy pages, generated and dynamic: privacy, distance selling terms, refunds and returns, shipping, cancellation with a withdrawal form, and cookies.
-
HP.02
Pay by bank gateway
An account to account rail with HMAC SHA256 signed webhooks, fail closed verification and server side repricing, alongside the existing card gateways.
-
HP.03
Underwriting ready content
A cookie consent gate that blocks non essential scripts until opt in, and original imagery that passes reverse image checks.
Result
15 of 18 requirements passing.
- processor requirements passing
- 15 of 18
- the rest gated on the client's merchant credentials, legal review and go live
- point readiness checklist
- 18
The store went from a failing processor readiness audit to 15 of 18 requirements passing on an 18 point readiness checklist. The other three wait on the client's merchant credentials, legal review and go live.