Keep your custom foundry site, and change what runs behind it.

Why foundry sites are custom

A foundry’s site is its specimen. Type testers, long setting samples, variable-font sliders and an identity of its own are the reason buyers stay on the page, and website builders and themes rarely do them well. So most of the foundries whose shops our studio has run commissioned a site, often from a designer-developer they know, and wrote the shop into the same code.

Generic carts made that seem necessary. A contributor to a TypeDrawers thread on foundry shops pointed out that they are built for many products with few variations each, and a font catalogue is the reverse. The result is a shop that is part of the site, built once, at a cost one foundry owner in the same thread put at $20,000 and more.

What a home-made shop costs to keep running

Pricing logic

Styles times licences times tiers times currencies, with family prices, bundles that mustn’t charge a style twice, discount codes and upgrades from one tier to the next. Each new licence or a change to the pageview bands means editing code, and a mistake shows up as a wrong price on a real order.

Fulfilment

Packaging the right formats for each licence, expiring download links, letting a buyer download again two years later, and stopping downloads after a refund. Home-made shops often send the same file to every buyer and keep links working indefinitely.

Licence records

A buyer writes to ask what their studio licensed in 2019. The answer needs the licensee’s name, the tier, the styles and the EULA text they accepted. Many custom shops kept the order and the payment and little else, so the answer comes from email archives.

Updates

Payment providers version their APIs and retire old ones. Plugins and frameworks lose support: One widely used front-end framework reached its end of life at the end of 2021, and foundry shops we know of still run on it. Each change needs the developer who knows the code, at a time that suits the provider.

Tax

A shop written before a country taxed digital sales from abroad charges the wrong amount until someone changes it. Rates, thresholds and the rules for business buyers with a VAT number all change, and a custom shop needs each change made by hand, or a tax service wired into the checkout. An accountant who knows digital sales should check whatever you use.

Security

A shop holds customers’ names, addresses and order histories, admin logins and payment keys. It needs patching, backups and someone who notices when something is wrong. Card details should never touch your server. Hosted payment fields keep them with the payment provider, and an older integration that predates them is worth replacing for that alone.

Splitting the site from the back office

The pages and the shop do different jobs and age at different speeds. The pages change when the foundry releases something. The shop has to keep up with payment providers, tax rules and security fixes every month. They can be separated: your site keeps the pages, and a back office run by someone else handles the selling.

The two connect in two directions.

• Your site reads from the back office. An API gives your site the catalogue, prices and licence tiers, so a price changed in one place shows everywhere. Your site can cache what it reads and rebuild when it changes.
• The back office tells your site about sales. A webhook is a signed message sent to an address on your site when an order is paid or refunded. Your site can use it to update a customer area, your accounts or a mailing list.

Buyers choose a licence and pay in the back office’s shop, which can sit on a subdomain such as shop.yourfoundry.com, styled to match. The links from your typeface pages go to the matching pages there. Your site never handles a card or a font file.

Before you choose a back office

Check what the API reads and what it leaves out, whether webhooks are signed and retried when your site is down, and whether the shop can live on your own domain. Ask what the export holds and whether it works after you cancel. Ask whether payments go to an account in your name, because that decides whether your payment history and customers move with you if you change back office again. The questions to ask a font shop service has the full list.

A migration checklist

1. List every licence you sell. Each licence, its tiers, the multiplier or price of each tier, terms, and the custom licences you quote by hand.
2. Write down the price rules. Base prices per style, family and bundle prices, currencies, discounts in use and how upgrades are priced. Compare a dozen real past orders against the new prices.
3. Collect every EULA version. Including the old ones your past buyers accepted, with the dates each was in force.
4. Export your past orders and customers. Keep them in a form you can search, even if the new back office can’t import them, so you can still answer licence questions.
5. Record designers’ shares. Per typeface, with the date each contract started, and the balance owed on the day you switch.
6. Find your webfont buyers. Note who self-hosts and who uses fonts you serve, and plan how hosted kits move without breaking their sites.
7. Map your URLs. Every cart, checkout, account and download address on the old shop needs a redirect, including links in old receipts.
8. Keep the same payment account. Connecting the account you already use keeps your payment history and customer records in one place.
9. Set up the domain. Add the DNS record for the shop’s subdomain and check the certificate before you link to it.
10. Place test orders. One per licence, in each currency, with a discount, with tax, then a refund. Check the files, the EULA and the webhook your site receives.
11. Tell existing buyers. Where they download from now, and whether their old download links still work.
12. Run both for a while. Leave the old shop able to answer re-downloads and licence lookups for a few months after the new one takes orders.

Where Typetin fits

Typetin is a licensing and sales back office with a shop on top, and a foundry with a custom site can put it behind that site. Your site reads the catalogue, prices and licence presets through the API, and webhooks tell it when an order is paid or refunded. Each webhook is signed with HMAC-SHA256 and sent up to 8 times over about 45 hours. Buyers pay in your Typetin shop, on your own domain if you add one, into your own Stripe account. The API starts on the Foundry plan. What the API reads.