AJ van der Gugten

Senior e-commerce developer

Phoenix, AZ

I build the parts of an online store the platform doesn't cover.

Email AJ What I've built
The layer I work at
Application. Orders, payments and inventory agreeing across systems that were never designed to talk to each other.
Client relationships
Most ran six years or more. Kunstmuseum Luzern ran from 2013 to 2026.
Currently building
BonaVault, a personal project, planned and directed end to end.
14
years building and maintaining commerce systems, for the same handful of clients.
3,300+
subscription records imported onto the new platform, with no customer re-authorizing.
$30,000
the top of the order range on a checkout I wrote from scratch, card not present.

MuseumsuferShop

An annual card for thirty-nine museums.

Sold online, billed by direct debit, scanned at the door.

The store itself is WooCommerce, off the shelf. Everything that made this hard is in the two plugins I wrote for it. Every existing subscription had to move off a legacy system onto WooCommerce Subscriptions without a single customer re-authorizing, because those people had signed direct debit mandates, which are ACH authorizations on file in US terms. Moving to an off-the-shelf processor would have meant collecting authorization from every one of them again. That is a churn event, so I wrote the payment method myself.

The same plugin generates the file the bank actually runs the collection from: an ISO 20022 pain.008.002.02 XML batch on the SEPA Core scheme, the European equivalent of a NACHA file for ACH. They were already on that schema, so I matched it and made it configurable rather than hard-coding it. Orders export one at a time or as a batch. Most people who claim payment experience integrated a gateway. This is a level below that.

The second plugin is the ticketing side, custom post types and all. A separate controller, run by another vendor and shared with other merchants, issues the QR code and answers the scanners at all thirty-nine venues. My plugin provisions and revokes against it. I could not modify it and did not need to.

What I wrote
Two WooCommerce plugins: the payment method and the ticketing integration.
Migration
3,300+ subscription records imported, no customer re-authorization.
Payments
Direct debit mandates, and a configurable ISO 20022 collection file, pain.008.002.02 by default.
Access
Entitlements provisioned into a live third-party system.

museumsufershop.de

Where my two plugins sit in the MuseumsuferShop system WooCommerce is the off-the-shelf store. Two plugins I wrote run inside it. The direct debit payment method handles mandates and generates the pain.008.002.02 bank collection file. The ticketing integration provisions and revokes entitlements on a third-party controller, and that controller, not WooCommerce, issues QR validity to the thirty-nine museum doors. WOOCOMMERCE, OFF THE SHELF Direct debit payment method Mandates, recurring billing, pain.008.002.02 Ticketing integration Provisions and revokes entitlements COLLECTION FILE PROVISION AND REVOKE QR VALIDITY Bank Runs the collection Ticketing controller Third party. Owns the readers 39 museum doors QR scanned at the gate OUTLINED, CODE I WROTE

Inside WooCommerce, off the shelf

Direct debit payment method

Mandates, recurring billing, pain.008.002.02

Collection file

Bank

Runs the collection

Ticketing integration

Provisions and revokes entitlements

Provision and revoke

Ticketing controller

Third party. Owns the readers

QR validity

39 museum doors

QR scanned at the gate

Outlined, code I wrote

The commerce side is deliberately not in the path of the door. A turnstile cannot depend on a website being up and fast, so validation lives with the system that owns the readers, and my side provisions and revokes instead of answering at the gate. When a collection fails and someone adjusts the order, that status change blocks the card automatically. Judgment stays with a person, state propagation does not.

ochs und junior

Configurator and checkout, one system

Mechanical watches priced between $6,000 and $30,000. Customers build the watch on screen, see it change in real time as composited high-resolution images, and buy it in the same flow. No e-commerce plugin did any of that, so the configurator and the checkout were written from scratch as a single system against the payment provider.

ochsundjunior.swiss
Engagement
2013 to 2021. The site has moved on since; the configurator and checkout are still the ones I built.
Order value
$6,000 to $30,000, card not present.
Failure design
Order created pending on submit, confirmed on the provider callback, so a lost callback can never leave a charge with no order behind it.

Private theme update server

Release distribution

Themes running across more than five client sites were being updated by hand. I built a version-check endpoint and wired WordPress's own update system to it, so a release ships once and every site pulls it from its own admin exactly like a theme from wordpress.org.

Constraint
Shared hosting, FTP deploys, no CI available.
Point
Building around the constraint instead of accepting it.

The layer I work at.

Orders, payments, inventory and records agreeing across systems that were never designed to talk to each other. Naming the layer is the point. I am not an infrastructure engineer. What I am good at is making two systems agree about a transaction without owning both of them.

The work is mostly WordPress and WooCommerce, at the code level rather than the settings level. Custom themes, custom plugins, PHP, and the APIs between them and whatever else the business already runs on.

Checkout
Custom checkout and payment flows, built where the platform stopped.
Payments
Gateway integration, recurring billing, and the bank collection files underneath.
Integration
Authenticated REST APIs between commerce systems and third-party platforms.
Practice
Sanitize on the way in, escape on the way out, prepared statements for anything touching the database.

Two things worth knowing.

I moved to Phoenix, and it is permanent. This is not a year abroad and it is not a test of the American market from a safe distance. Phoenix is where I am building the rest of it, and I am not going back. My legal name is Alain Johan van der Gugten, which is what turns up on paperwork. Everyone calls me AJ.

Fourteen years at a small agency in Germany, building and maintaining commerce systems for the same handful of clients. Most of those relationships ran six years or more, several of them past a decade. You learn different things that way than you do shipping a greenfield project every eight months. Mostly you learn what breaks two years after launch, because you are the one who gets the call. That chapter closed when I moved.

Open to senior e-commerce and integration roles in Phoenix.

I'm looking for a full-time role where custom checkout, payment work and systems integration are the actual job. Smaller companies over enterprise.

hello@ajvandergugten.com
Based
Phoenix, AZ
Languages
English, Dutch, German
Elsewhere
LinkedIn