DEV Community: Northbeam Technologies

Multi-Tenant Stripe Connect Payments in a Go SaaS Platform

Northbeam Technologies — Fri, 10 Jul 2026 08:30:17 +0000

The problem

We build Verify365, a white-label SaaS platform used by several law firms, each under its own brand. Every partner firm needs payments to land directly in their own Stripe account — not a shared platform account — while the platform still needs to skim a processing fee before the rest of the money moves on.

Stripe Connect solves the "money to the right account" part. The interesting engineering problem was building a clean, per-partner client pattern around it in Go.

The design

We wrote a small stripe365 package that wraps Stripe's Go SDK, with one core rule:

One Client365 instance per request — never a shared, app-wide client.

Each instance is initialised with either the partner's own Stripe credentials, or the platform's default credentials as a fallback. Everything downstream (fee math, transfer destination, webhook secret) branches off an IsDefault flag set at construction time.

Here's the flow, end to end:

Request comes in for a partner (or the platform default)
Client365 is built fresh, credentials picked based on IsDefault
Checkout session created, with fee math applied only for partner accounts
Stripe routes the net amount to the partner's connected account via TransferData
Webhook confirms the payment on the correct endpoint (platform vs. connect)

Per-request client initialisation

Instead of building one global Stripe client at app startup, we build a fresh one on every call, picking credentials based on whether the partner has their own Stripe account configured:

// thirdparty/stripe365/Stripe365.go

func NewStripeClient(logger *zerolog.Logger, partner *domain.Partner) Client365 {
    stripeKey := ""
    stripeSecret := ""
    stripeWebhook := ""
    stripeWebhookConnect := ""
    isDefault := false

    if partner == nil || partner.StripeSecret == "" {
        // Platform default — env vars
        stripeKey = os.Getenv("STRIPE_KEY")
        stripeSecret = os.Getenv("STRIPE_SECRET")
        stripeWebhook = os.Getenv("STRIPE_WEBHOOK")
        stripeWebhookConnect = os.Getenv("STRIPE_WEBHOOK_CONNECT")
        isDefault = true
    } else {
        // Partner-specific Stripe account
        stripeKey = partner.StripeKey
        stripeSecret = partner.StripeSecret
        stripeWebhook = partner.StripeWebhook
        stripeWebhookConnect = partner.StripeWebhookConnect
    }

    stripeClient := &client.API{}
    stripeClient.Init(stripeSecret, nil)

    return &client365{
        StripeClient:         stripeClient,
        IsDefault:            isDefault,
        StripeWebhook:        stripeWebhook,
        StripeWebhookConnect: stripeWebhookConnect,
        // ...
    }
}

Building the client per-request keeps things stateless and rules out one partner's credentials accidentally leaking into another partner's request — a real risk if you cache a Stripe client keyed by tenant in a long-lived map.

Fee math and transfer routing

Partner accounts get a platform fee deducted before the rest is routed to their connected account. The platform's own default account skips that — the platform just eats Stripe's processing cost instead:

const (
    StripeFeePercentage = 0.0185 // 1.85% — to be confirmed with client
    StripeFeeFixed      = 0.20   // £0.20 fixed per transaction
)

func (c *client365) CreateCheckoutSession(...) (*stripe.CheckoutSession, error) {
    amount := payment.Amount * 100 // pounds → pence
    roundedResult := math.Round(amount)
    netAmount := roundedResult
    platformFee := 0.0

    if !c.IsDefault {
        // Partner account: deduct platform fee before routing
        platformFee = (payment.Amount * StripeFeePercentage) + StripeFeeFixed
        netAmount = math.Round((payment.Amount - platformFee) * 100)
    }
    // IsDefault: netAmount = full amount (platform covers Stripe fees)

    params := &stripe.CheckoutSessionParams{
        // ...line items, mode, URLs...
        PaymentIntentData: &stripe.CheckoutSessionPaymentIntentDataParams{
            StatementDescriptor: stripe.String(fmt.Sprintf("V365 %s", payment.DisplayId)),
            Description:         stripe.String(description),
            TransferData: &stripe.CheckoutSessionPaymentIntentDataTransferDataParams{
                Amount:      stripe.Int64(int64(netAmount)),
                Destination: stripe.String(stripeAccountId), // the connected account ID
            },
        },
    }
    return c.StripeClient.CheckoutSessions.New(params)
}

Two things worth calling out:

Everything gets converted to integer pence and passed through math.Round() before touching Stripe — floating-point drift is a classic way to end up with amounts like £10.000000001.
TransferData.Destination is what actually routes the net amount to the partner's connected account at checkout time, rather than requiring a separate manual transfer afterwards.

Onboarding partners with Stripe Express

New partner firms get a Stripe Express account rather than a full custom onboarding flow — Stripe handles the KYC UI, and we just create the account and hand back an onboarding link:

func (c *client365) CreateAccount(request domain.StripeAccountInfo, user domain.User) (*stripe.Account, error) {
    params := &stripe.AccountParams{
        Capabilities: &stripe.AccountCapabilitiesParams{
            CardPayments: &stripe.AccountCapabilitiesCardPaymentsParams{Requested: stripe.Bool(true)},
            Transfers:    &stripe.AccountCapabilitiesTransfersParams{Requested: stripe.Bool(true)},
        },
        Country: stripe.String(request.Country),
        Email:   stripe.String(user.Email),
        Type:    stripe.String(string(stripe.AccountTypeExpress)),
        Settings: &stripe.AccountSettingsParams{
            Payouts: &stripe.AccountSettingsPayoutsParams{
                Schedule: &stripe.PayoutScheduleParams{
                    Interval: stripe.String(string(stripe.PayoutIntervalDaily)),
                },
            },
        },
    }
    return c.StripeClient.Account.New(params)
}

func (c *client365) CreateAccountLink(id string, request domain.StripeAccountInfo) (*stripe.AccountLink, error) {
    params := &stripe.AccountLinkParams{
        Account:    stripe.String(id),
        RefreshURL: stripe.String(request.RefreshURL),
        ReturnURL:  stripe.String(request.ReturnURL),
        Type:       stripe.String("account_onboarding"),
    }
    return c.StripeClient.AccountLinks.New(params)
}

Daily payout schedules keep cash flow predictable for the law firms on the other end.

Two webhook endpoints, two secrets

Platform-level events (a checkout completing on the platform's own account) and connected-account events (transfers, connected-account payouts) come through separate webhook endpoints, each verified with its own secret:

// Both registered in the Gin router
router.POST("/webhook/stripe",         paymentController.HandleStripeWebhook)
router.POST("/webhook/stripe/connect", paymentController.HandleStripeConnectWebhook)

// In PaymentService:
func (s *PaymentService) HandleWebhook(payload []byte, signature string, isConnect bool) error {
    webhookSecret := s.stripeClient.GetStripeWebhook()
    if isConnect {
        webhookSecret = s.stripeClient.GetStripeWebhookConnect()
    }
    event, err := webhook.ConstructEvent(payload, signature, webhookSecret)
    if err != nil {
        return fmt.Errorf("stripe webhook signature verification failed: %w", err)
    }

    switch event.Type {
    case "checkout.session.completed":
        // Update Payment.status → "paid"
    case "payment_intent.payment_failed":
        // Update Payment.status → "failed"
    case "transfer.created":
        // Reconcile connected account transfer
    }
    return nil
}

Mixing up STRIPE_WEBHOOK and STRIPE_WEBHOOK_CONNECT is an easy mistake, and it fails quietly with a signature-verification error rather than an obvious "wrong secret" message — worth a comment or two in the code so future-you doesn't lose an afternoon to it.

Takeaways

One client per request, not one client per app. Building the Stripe client inside the request path (rather than once at startup) keeps the logic stateless and avoids cross-tenant credential leakage.
Fee logic only applies to partner accounts. The IsDefault flag is the single switch that decides whether the fee formula runs at all.
Stripe Express removes a whole KYC flow from your scope. Let Stripe own onboarding UI and compliance; you just create the account and generate the link.
Two webhook secrets, two endpoints. Don't try to multiplex platform and connected-account events through one handler with one secret.
Round to integer pence before calling Stripe. Floating-point math and money don't mix.

Stack: Go · stripe-go/v72 · Stripe Connect · Stripe Express Accounts · PostgreSQL · Gin

Building multi-tenant payments in a Go SaaS? Happy to compare notes in the comments.

Building an RTL Hebrew Video Platform with Nuxt 2 SSR and Video.js

Northbeam Technologies — Tue, 07 Jul 2026 03:07:46 +0000

The Problem

Hebrew is a right-to-left language. Building a video platform where Hebrew is the primary language — not an afterthought — means RTL has to be the default at every layer: layout, navigation, text direction, input alignment, and icon mirroring. On top of that, the site needed server-side rendering for SEO (video titles, channel names, and category pages all need to be crawlable), and a player that remembers exactly where a user left off across sessions and devices.

What We Built

kolel.org is a Nuxt 2 universal app — SSR on first load, client-side navigation thereafter. Vuetify 2 handles the UI with RTL enabled globally. @nuxtjs/i18n manages locale detection with Hebrew (he) as the default and English (en) as a fallback. Video playback uses Video.js 7 with a custom Vue wrapper that tracks position and syncs it to the Rails API on a 5-second interval.

How It Works

Key Technical Decisions

1. Vuetify RTL enabled globally

Setting rtl: true in vuetify.options.js flips all Vuetify components — navigation drawers open from the right, icons mirror, flex directions invert, and text aligns right by default. One flag, entire UI:

// vuetify.options.js
export default {
  defaultAssets: {
    font: false,
    icons: 'mdi'
  },
  theme: {
    themes: {
      light: { primary: '#1e88e5' },
      dark:  { primary: '#1e88e5' }
    }
  },
  rtl: true  // flips the entire Vuetify UI to right-to-left
}

2. Hebrew as the default locale, no URL prefix

@nuxtjs/i18n is configured with strategy: 'no_prefix' so Hebrew URLs are clean (e.g. /video/123 not /he/video/123). Browser language detection is disabled — every visitor gets Hebrew first, with English available via a manual toggle:

// config/i18n.js
const messages = {
  en: { ...require('../locales/en.json'), $vuetify: en, dir: 'ltr' },
  he: { ...require('../locales/he.json'), $vuetify: he, dir: 'rtl' },
}

export default {
  locale: 'he',
  fallbackLocale: 'en',
  messages
}

// nuxt.config.js
i18n: {
  locales: ['en', 'he'],
  defaultLocale: 'he',
  localeDetection: false,
  detectBrowserLanguage: false,
  strategy: 'no_prefix',
  vueI18n: i18n
}

3. Video.js player with watch-position tracking

The player is a Vue component that mounts Video.js imperatively in mounted(). A setInterval running every 5 seconds calls storeVideoPosition(), which sends the current playback time to the Rails API — so a user who closes the tab resumes from the exact second on any device:

import videojs from 'video.js';

// mounted()
this.player = videojs(this.$refs.videoPlayer, this.playerOptions);

this.player.ready(() => {
  this.playVideo(this.videoUrl);
});

this.player.on('ratechange', this.playerRateChanged);
this.player.on('play',  this.playing);
this.player.on('pause', this.stopInterval);
this.player.on('ended', this.stopInterval);

// watch-position sync — fires every 5 s while playing
storeVideoPosition() {
  const payload = {
    id: this.video.id,
    position: Math.ceil(this.player.currentTime()),
  };
  this.video.user_watch = {
    ...(this.video.user_watch || {}),
    position: payload.position,
  };
  this.markWatch(payload); // Vuex action → Rails API PATCH /watches/:id
}

4. SSR + hydration without layout shift

Because Video.js requires a real DOM, the player component is wrapped in a <client-only> tag in Nuxt. The server renders the video metadata, title, and channel info (crawlable by search engines) while the player hydrates client-side after JavaScript loads — no layout shift because the player slot is sized with CSS before hydration.

Results / What Changed

Full Hebrew RTL layout across every page — no per-component dir overrides needed
Video titles, channel pages, and category routes are indexed by search engines via SSR
Watch position resumes cross-device — creators report viewers completing more long-form lessons
English toggle works without a page reload — Vuetify + i18n switch both layout direction and copy simultaneously

Stack

Nuxt 2.15 · Vue 2 · Vuetify 2 (RTL) · @nuxtjs/i18n · Video.js 7 · Axios · Rails 7 API · Google Cloud Storage

Building an internationalized or RTL web platform? Get in touch.

Originally published on the Northbeam Technologies Insight.

Automating Student Onboarding via WhatsApp in SugarCRM

Northbeam Technologies — Fri, 26 Jun 2026 07:41:34 +0000

A multi-step conversation engine that captures leads and creates CRM records automatically — no staff required.

The Problem

When prospective students first contact the school via WhatsApp, staff had to manually collect their details and create a record in SugarCRM by hand. Leads that arrived outside business hours were simply missed or delayed — there was no way to capture them without a person in the loop.

The school was already using Twilio for outbound WhatsApp messages from SugarCRM, but replies from unknown numbers went nowhere.

What We Built

A multi-step conversation engine built directly into SugarCRM. When an unknown number sends a WhatsApp message, the system:

Intercepts the message via a Twilio webhook
Checks whether the phone number already exists as a student record
If yes → routes to the existing follow-up flow (no change)
If no → starts a guided intake questionnaire, validates each answer, and creates the student record automatically

Zero admin involvement for new contacts.

How It Works

Key Technical Decisions

State machine, not a script.

Each conversation is a session with a current_step pointer. Questions can be reordered, toggled, or mapped to any CRM field without changing code. Admins manage the question bank directly from SugarCRM's UI.

Phone number normalization.

The system normalizes Israeli, US, and Vietnamese number formats before matching — preventing duplicate records from format variations like +1-555... vs 001555....

Media guard.

If a student sends a photo or voice note, the system replies politely that only text is supported and automatically resends the current question.

Partial completion handling.

If a student stops mid-flow, automated reminders go out at 2h and 24h. If minimum data (name + phone) is collected and the student still doesn't respond, a partial record is saved so the lead isn't lost.

Multi-number support.

Multiple Twilio sender numbers can be registered in SugarCRM. Each conversation session locks to the number the student originally contacted.

What Changed After Launch

✅ Student record creation from WhatsApp is fully automated for new contacts
✅ Leads outside business hours are captured without any staff intervention
✅ Admins can view full chat history, manually resume sessions, or override any step from inside SugarCRM
✅ The existing outbound messaging workflow for known students is completely unchanged

Stack

PHP — core logic and SugarCRM custom modules
SugarCRM — custom modules for session management, question bank, and student records
Twilio WhatsApp API — inbound webhook + outbound messaging
MySQL — session state persistence

The main lesson here: WhatsApp bots don't need a separate platform. If your CRM already has a webhook endpoint and an API, you can build the conversation engine right inside it — and keep everything in one place for your team.

Originally published on northbeam-tech.com

Client-Side Video Transcoding with FFmpeg.wasm — No Server Required

Northbeam Technologies — Wed, 24 Jun 2026 08:02:20 +0000

The problem

The Kolel Creator Dashboard lets educators and rabbis upload video lessons directly from their browser. Creators record on phones, tablets, and cameras — producing files in every format imaginable: .mov, .webm, .avi, .mkv.

Our Google Cloud Video Transcoder pipeline expects MP4 input. The original solution was a dedicated pre-upload server that re-encoded every file before it hit cloud storage. One more service to deploy, monitor, and pay for.

We needed a way to normalize the format before the file ever left the creator's machine.

The solution: FFmpeg running inside the browser

We integrated @ffmpeg/ffmpeg into the Vue 2 upload component. When a creator picks a non-MP4 file, the browser:

Downloads the FFmpeg WASM core (~30 MB, cached after first load)
Transcodes the file to MP4 inside a Web Worker
Uploads the resulting blob directly to a GCS Signed URL

The Rails API and the downstream transcoding pipeline never see anything other than a clean MP4.

The core transcoding function

import { createFFmpeg, fetchFile } from '@ffmpeg/ffmpeg';

async convertToMp4(file) {
  const supportedTypes = ['video/mp4', 'video/mov', 'video/m4v'];
  if (supportedTypes.includes(file.type)) {
    return; // already compatible — skip transcoding
  }

  const ffmpeg = createFFmpeg({
    log: true,
    corePath: 'https://unpkg.com/@ffmpeg/core@0.10.0/dist/ffmpeg-core.js',
  });

  if (!ffmpeg.isLoaded()) {
    await ffmpeg.load();
  }

  const fileName = file.name;
  const outputFileName = 'output.mp4';

  ffmpeg.FS('writeFile', fileName, await fetchFile(file));
  await ffmpeg.run('-i', fileName, outputFileName);

  const data = ffmpeg.FS('readFile', outputFileName);
  this.selectedFile = new Blob([data.buffer], { type: 'video/mp4' });
}

A few things worth noting:

We pin a specific CDN version of @ffmpeg/core so the WASM binary is cached in the browser after the first upload session. Repeat visitors pay zero load cost.
We bail early for common formats (mp4, mov, m4v). Running FFmpeg.wasm on a file that's already compatible wastes time and memory.

Uploading without exposing credentials

The browser never holds GCS credentials. The Rails API generates a short-lived Signed URL for the specific file path, then the browser PUTs directly to GCS:

async uploadFileToSignedUrl(signedUrl, selectedFile) {
  await axios.put(signedUrl, selectedFile, {
    headers: { 'Content-Type': selectedFile.type },
  });
}

async prepareVideoUpload() {
  this.loading = true;
  await this.getSignedUrl();
  await this.uploadFileToSignedUrl(this.signedUrl, this.selectedFile);

  if (this.pickedThumbnail) {
    await this.getImageSignedUrl();
    await this.uploadFileToSignedUrl(this.thumbnailSignedUrl, this.pickedThumbnail);
  }

  this.addVideo(); // notify Rails API to create the video record
}

Results

Before	After
Pre-upload transcoding microservice	Removed entirely
Format errors reaching the pipeline	Zero
GCS credentials in the browser	Never
Upload experience for MP4/MOV users	Unchanged

Key takeaways

FFmpeg.wasm is production-ready for this use case. The WASM core is large, but browser caching makes repeat sessions fast.
Signed URLs are the right pattern for direct browser-to-cloud uploads. No credentials ever leave your server.
Always allow-list known-good formats before invoking WASM — it saves real time for the majority of your users.

Stack

Vue 2 · @ffmpeg/ffmpeg 0.10 · @ffmpeg/core (WebAssembly) · Google Cloud Storage · GCS Signed URLs · Google Cloud Video Transcoder · Rails 7 · Axios

Originally published on the Northbeam Technologies blog.