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

Custom checkouts, payment integrations, and membership cards that have to be valid at thirty-nine museums. 14 years of it, for stores in Germany and Switzerland.

Email AJ What I've built
Location
Phoenix, AZ
Layer
Application. Orders, payments and inventory agreeing across systems.
Client relationships
7 to 12 years, several running the whole 14.
Longest client relationship
Kunstmuseum Luzern, 2013 to 2026
Anchor system
MuseumsuferShop: 3,000 annual cards, direct debit billing, valid at 39 museums
Currently building
BonaVault, a personal project, planned and directed end to end

What I've built

MuseumsuferShop

An annual membership 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. Three thousand existing cards 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 all three thousand 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 batch, the European equivalent of a NACHA file for ACH. 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.

museumsufershop.de
What I wrote
Two WooCommerce plugins: the payment method and the ticketing integration.
Migration
3,000 active recurring cards, no customer re-authorization.
Payments
Direct debit mandates, and the ISO 20022 pain.008 collection file.
Access
Entitlements provisioned into a live third-party system.
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 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 file Ticketing integration Provisions and revokes entitlements Bank Runs the collection Ticketing controller Third party. Owns the readers 39 museum doors QR scanned at the gate COLLECTION FILE PROVISION AND REVOKE QR VALIDITY ACCENT OUTLINE, CODE I WROTE

Inside WooCommerce, off the shelf

Direct debit payment method

Mandates, recurring billing, pain.008 file

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

Accent rule, 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. That is the application layer, and naming it 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

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