Payment and tax surfaces, designed and merged
- Problem
- Payouts, collections, tax classification and the payment methods a seller can offer sit across two product teams at ablefy — the surfaces where what a seller is owed, charged and taxed becomes visible. Both teams share one designer.
- Solution
- I cover both: the seller-facing design, and the front-end code that puts it in production. Where a direction is still open, it goes to the team as a running branch — working code an engineer can open and run, not a mock-up.
- Result
- Merged into the production web client — the payment, tax and product-access surfaces for both teams, designed and coded in one pass.
Role & team
Sole designer across two product teams
- ablefy, a creator-commerce platform — the teams that own payments and compliance.
- Design and the front-end that ships it: pull requests into the production web client.
- Open directions handed to engineers as working branches.
Scope
Payouts, collections, tax, payment methods, product access
- Two product teams, one seller cabinet — the surfaces where money, tax and access become visible.
- Seller-facing and server-side both: a classification the seller sets has to resolve behind it.
- Power sellers and normal sellers; course and digital product types.
Working practice
Open directions handed over as running branches
- A bank-wire page rebuilt to cut payment errors — copy, progressive disclosure, responsive behaviour.
- A bank-account modal, version 2.
- Email configuration settings, returned to full width.
At ablefy, two product teams own the surfaces where money changes hands: what a seller is owed, what happens once a payment fails and collections begin, how a product is taxed, which payment methods a seller can offer, and what a buyer can open after paying. A money surface has to answer the question a seller is about to act on — what is owed, what is on its way, when collections stop — and hold that answer on first read.
I am the only designer on both teams, and the design reaches production as code I write and merge into the web client. That changes the job: what the web client already supports is where the design starts, and the pages around a surface set its conventions before I do.
The page next door sets the width
The email configuration settings page sat centred, with its width capped. Read on its own, that is a defensible typographic choice. Read in the cabinet, beside the other settings pages in the same section, it read as half an empty page.
The redesign returned it to full width, left aligned, matching the pages around it.
The lesson I kept: on an existing surface, the reference is the page next door. However well-reasoned a local choice is, a deviation no neighbouring page shares reads as a mistake.
A tax choice is only useful if the rule behind it agrees
The seller-facing part of tax classification is a choice a seller sets on a form. The part that decides the outcome is how that choice resolves server-side. Because the design and the front-end are one pass of work here, the interface and the resolution were settled together — the form could only offer what the resolution behind it honours.
Admission tax for ticket products arrived the same way: a compliance rule reaching the seller as a choice on a screen, designed where the seller meets it.
What went into production
Surface by surface, this is the seller's money. Each line is a merged change in the production web client, grouped by the question it answers for the seller.
View full size- What am I owed — payout balance summary cards: a seller's balance stated as a summary in the cabinet.
- What happens when a payment fails — dunning (payment reminders) and Inkasso (German debt collection) deactivation: collections handling that can be switched off, covering power sellers and normal sellers.
- How is my product taxed — seller-side tax classification with its server-side resolution, and admission tax for ticket products.
- How can buyers pay — a Pay Later payment method, added to the seller cabinet flow.
- What did buyers get — access and duration settings for course and digital product types, and seller order-rate management, merged as a prototype.
- Housekeeping in the same web client — outdated tooltips replaced, a background fix on the sales-regions profile page.
Directions handed over as branches
Some work goes to the team as a branch — built, committed, pushed, handed over for an engineer to check out and run: a bank-wire page rebuilt to cut payment errors, a bank-account modal built with Cursor, and the email-settings redesign above. When a direction is still open, the team gets a version that runs, not a picture of one.
What the thread adds up to
Of the employed work, this is the thread I lead with. Four reasons:
- One designer covers both teams, so all of it sits inside a single scope.
- The design and the front-end are one job. Every surface on the shipped list is a change I designed and then merged.
- Compliance is seller-facing. Dunning, Inkasso, tax classification and admission tax reach the seller as choices on a screen, and that is where they get designed.
- A branch is a deliverable. When a direction is still open, the team gets a version that runs.