Cloud Payment API

Every new payment terminal required a rebuild of the POS system and a physical rollout to every restaurant. When we added Nuvei, Dejavoo, Windcave, Adyen, and Stripe, each had a completely different API format, different authentication, different webhook structures. Without a standard layer, adding one provider meant changing everything.

The Cloud Payment API, a middleware layer that sits between all POS systems and all payment terminal providers.

The POS sends one standard request with device ID, amount, currency, and unique order reference. Cloud API reads the device ID, identifies the provider from the prefix, translates the request to that provider's format, XML for Windcave, JSON for Nuvei and Dejavoo, and routes to the correct terminal. The terminal activates, customer taps their card, and the provider fires a webhook back to our callback URL.

Cloud API stores the status in DynamoDB. The kiosk polls our status endpoint every few seconds and picks up the result. Foodhub never sees card data at any point, tokenisation happens at the terminal via P2PE.

Adding a new provider became a translation layer only. The POS system never needed to change.

I also personally reviewed API documentation for every integration, mapped fields, identified gaps, for example stripping the nuvei prefix from device IDs before sending as TPN, and wrote engineering specs directly without needing the EM to interpret for me.

Abstract all providers behind one standard interface. Use device ID prefix routing so the POS never needs provider awareness. Webhooks as primary status mechanism with polling as safety net.

Added Nuvei, Dejavoo, Windcave, Adyen via Datman, and Stripe without changing EPOS or Kiosk code once. Delivered integrations 85 percent faster than industry benchmark. Foodhub never handles card data in any flow, fully P2PE compliant.