← All posts
07 Aug 2026· 3 min readBuilding in publicPaymentsAuctions

An art store grew a currency switcher and an auction house

Hans Rooseboom Art went from a single-currency ZAR checkout to five currencies and live bidding in about a week — plus the payment-processor swap that made it possible.

An art store grew a currency switcher and an auction house

Ten days ago, Hans Rooseboom Art was a straightforward gallery store: browse the originals, pay in rand via Payfast or in dollars via Stripe, done. This week it grew a currency switcher and a live auction house, and the thing that made both possible was a payment-processor swap most visitors will never notice.

Why Payfast had to go

The store originally shipped with Stripe for international cards and Payfast for South African rand — the pairing the original marketing-strategy doc called for. Payfast got replaced with Paystack. Nothing about that decision needed announcing at the time; it just meant one afternoon of migration and a renumbered SQL file after the branch got rebased onto main. But it's the reason everything that followed was possible: Paystack's API made it straightforward to charge in a currency other than ZAR, which Payfast's SA-first integration didn't give us cleanly.

Five currencies, priced server-side

Once Paystack was in place, the real work started: a multi-currency data layer — schema, types, money-handling helpers — followed by a currency switcher and checkout across ZAR, USD, GBP, EUR and AUD. The important detail isn't the switcher UI, it's where the price comes from. Each original can carry an optional price in pounds, euros or Australian dollars, set by Hans in admin; the cart prices in the buyer's actual selected currency rather than converting USD-as-fallback on the fly. That distinction is the difference between "looks international" and actually being safe to sell art to a stranger in another currency.

Then: an auction house

With currencies sorted, the store gained a second sales mechanism entirely. Step one was the lot schema and an admin screen to create one. Step two was bids: a place_bid function that's atomic at the database level, so two people bidding on the same lot within the same second resolve correctly instead of racing each other. That's not a detail you can retrofit safely — it has to be right from the first bid.

Alongside the auction work, the gallery got tier filtering (All / Tier 1 / Tier 2 / Tier 3 / Private Reserve, server-side and URL-driven so it stays fast at scale), and artwork tiers and collections became first-class data instead of something bolted onto the pricing copy. A pricing band that used to say "three tiers, one hand" — confusingly, next to the new Tier 1/2/3 filter pills — got renamed to "How the work is priced" so "tier" means one thing across the whole site.

The smaller stuff that makes a store trustworthy

In between the headline features: reservation holds on originals that are releasable and self-reclaimable rather than locking a piece indefinitely, iPhone HEIC photo uploads converted to JPEG on the way in (so Hans can shoot on his phone without a format fight), and a fix for artwork images that weren't loading because Supabase's storage host wasn't allowlisted in next/image. None of that is glamorous. All of it is the difference between a demo and a store someone's actual buyers use.

Why this is the story this week

Most weeks across the portfolio look like steady maintenance — a bug fixed here, a page added there. This one was different: a single project went from "sells art in two currencies via two processors" to "sells and auctions art in five currencies via one processor," in about ten days, without a single day where the site was broken for a real buyer. That's the part worth writing down — not that it shipped fast, but that the payment path stayed correct the whole way through.

Want one of these built for your business?

I build custom AI platforms and go-to-market engines end-to-end. Book a session and let's map it out.

Book a session