TokenGate

The client wanted to sell access to its tokenisation APIs. Every new customer needed a manual key, a manual plan and a manual invoice.

The APIs already sat behind a Tyk gateway. Moesif could measure usage, Stripe could bill, and Auth0 handled identity. Nothing joined these services into one place a developer could use alone.

Manual onboarding slowed sales and made billing error-prone. Each new customer cost engineering time.

Constraints:

• Four third-party services to connect.
• Stripe and Moesif secret keys must never reach the browser.
• No paid access without an active subscription.
• Three environments: develop, staging and main.

Success meant a developer could sign up, pick a plan, get a key and watch their usage with no help from the team.

The portal walks a developer from sign-up to a working key, then shows what they used and what it costs.

The end-user flow, as the code implements it:

1. 01

   Sign up: The developer enters first name, last name, email and password. The form checks each field ("Email is required", "Invalid email address", "Password should be at least 6 characters long") before creating the account. Login runs through Auth0.

2. 02

   Choose a plan: A payment guard checks the developer's Stripe subscription on every protected page. With no active subscription they land on the pricing page: "Select a payment plan to finish setting up your account." They can take the free plan or pay through Stripe Checkout. When Checkout returns, the portal registers the Stripe customer and loads the subscription.

3. 03

   Create API keys: The keys page explains that a token must go with every request. The developer names a key (for example "Private Credit") and gets it back with a Live status. They can rename or delete keys. Each account can hold 3 keys; a fourth attempt shows a warning.

4. 04

   Call the API: The key goes in each request to the Tyk gateway. Tyk policies enforce rate limits and monthly quotas per plan, and each call is recorded in Moesif.

5. 05

   Watch usage: The dashboard shows usage charts from Moesif. Below it, an activity table lists calls for a chosen date range, with paging and a download to Excel.

6. 06

   Manage billing: The billing page shows the current plan and a plan picker with each plan's features and monthly price. The button on the current plan reads "Current Plan" and is disabled, so a developer cannot subscribe to the plan they already have. Changing plan updates the Stripe subscription in place. Payment methods are listed from Stripe, and adding a card opens the Stripe-hosted page, so card numbers never touch the portal.

Key design decisions:

I also looked at a hosted developer portal product. It did not fit the custom plan and billing rules, so I built a light portal instead.

1. 01

   The developer signs in through Auth0. An Axios interceptor adds the access token to every portal request.

2. 02

   The payment guard asks the proxy for the Stripe customer and subscription. If the status is not active, it redirects to pricing.

3. 03

   The proxy lists plans from Stripe, starts the free plan or confirms the Checkout session, and updates the subscription on a plan change.

4. 04

   The portal API service creates, renames and deletes keys in the Tyk gateway, with policies for rate and quota.

5. 05

   The gateway forwards calls to the tokenisation API and sends each event to Moesif.

6. 06

   The proxy queries Moesif by time interval (minutes up to quarters), shapes the result into chart series and table rows, and streams an Excel file on request.