The Problem

When you’re running multiple products and services, payments get complicated fast. Each product might need:

• Its own payment flow

• Different currencies (a client in Nigeria pays in NGN, one in the US pays in USD)

• Separate webhook notifications

• Isolated transaction records so one product’s data never leaks into another’s

The tempting answer is: use a different payment provider for each product. But that means managing multiple dashboards, multiple integrations, and multiple headaches. We chose a different path.

Why Paystack

Paystack is a solid payments infrastructure provider with strong support for African markets and international cards. For us, the decision came down to:

• Reliable APIs - Clean REST endpoints for initializing transactions, verifying payments, and handling refunds.

• Webhook support - Real-time event notifications when payments succeed, fail, or get refunded.

• Multi-currency acceptance - Customers can pay in their local currency.

• Settlement flexibility - We receive all payouts in a single settlement currency, which simplifies our accounting.

One Paystack account. Multiple products. Full isolation between them.

The Architecture (High Level)

Instead of connecting each product directly to Paystack, we built a payment layer that sits between our products and the provider.

┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│  Product A  │    │  Product B  │    │  Product C  │
└──────┬──────┘    └──────┬──────┘    └──────┬──────┘
       │                  │                  │
       └──────────────────┼──────────────────┘
                          │
                   ┌──────▼──────┐
                   │   Payment   │
                   │    Layer    │
                   └──────┬──────┘
                          │
                   ┌──────▼──────┐
                   │   Paystack  │
                   └─────────────┘

Each product registers once with our payment layer and gets its own credentials. From there, the flow is simple:

1. Product requests a payment - sends amount, currency, customer email, and any metadata it needs back later.

2. Currency conversion - if the customer’s currency differs from our settlement currency, we convert it transparently using live exchange rates.

3. Paystack checkout - the customer is redirected to a secure Paystack-hosted payment page.

4. Webhook relay - when Paystack confirms payment, we update our records and forward the event to the originating product’s own webhook URL.

5. Verification - the product can also query payment status directly via our API, rather than relying solely on webhooks.

Key Design Decisions

1. Service Isolation

Every product that uses our payment layer is fully isolated:

• Separate credentials - each product authenticates independently. Product A cannot see or modify Product B’s transactions.

• Scoped queries - when a product asks “show me my payments,” it only sees its own.

• Independent webhooks - each product receives payment events at its own endpoint, signed with its own secret.

This means adding a new product is just a registration step. No new Paystack integration, no new provider account.

2. Currency Conversion as a First-Class Feature

Our clients are spread across multiple countries. A customer in Kenya pays in KES, someone in the US pays in USD, and a client in the UK pays in GBP. Rather than forcing everyone into one currency, we:

• Accept the payment in the customer’s currency

• Convert to our settlement currency using live rates from a reliable data source

• Store the original amount, the converted amount, and the exchange rate used

This way, the customer sees familiar numbers, and our books stay clean.

3. Webhook Reliability

Webhooks are the backbone of async payment processing, but they’re unreliable by nature - networks fail, servers go down. We handle this with:

• Signature verification on every incoming Paystack webhook (HMAC validation - never trust unsigned events)

• Signed outbound webhooks to our products, so they can verify the event came from us

• Retry logic with backoff - if a product’s webhook endpoint is down, we retry with increasing delays

• Full delivery logging - every delivery attempt is recorded with status codes and response details

4. Idempotency

Duplicate payment requests happen - a user double-clicks, a network retry fires, a webhook is delivered twice. We handle this by accepting an idempotency key with each payment request. If we’ve already processed that key for a given product, we return the existing payment instead of creating a new one. No double charges.

5. Refund Support

Refunds flow through the same layer. A product requests a refund (full or partial), we process it through Paystack, and the product gets a webhook when it’s complete. The original payment record tracks refund status, amounts, and history.

What This Looks Like in Practice

Here’s a simplified example of how a product initiates a payment:

POST /api/v1/payments/initiate/
Authorization: Bearer <product_api_key>

{
  "email": "customer@example.com",
  "amount": 25.00,
  "currency": "USD",
  "description": "Monthly subscription",
  "callback_url": "https://myproduct.com/payment/complete",
  "metadata": {
    "plan": "standard",
    "user_id": "usr_12345"
  }
}

The response includes a checkout URL for the customer and a reference to track the payment. When the customer pays, the product gets a webhook:

{
  "event": "payment.success",
  "reference": "acoruss-abc123",
  "amount": 25.0,
  "currency": "USD",
  "settlement_amount": 3237.5,
  "settlement_currency": "KES",
  "metadata": {
    "plan": "standard",
    "user_id": "usr_12345"
  }
}

The metadata round-trips back - whatever the product sent in, it gets back. This means the product can reconcile the payment with its own records without any additional lookups.

Lessons Learned

Don’t multiply providers unnecessarily. If one provider covers your needs, build an abstraction layer instead of fragmenting across multiple integrations. You’ll save on maintenance, onboarding, and debugging.

Treat currency conversion as data, not a side effect. Store everything - original amount, rate, converted amount. When a customer disputes a charge six months later, you’ll want that trail.

Never trust the redirect. When a customer is redirected back to your site after payment, the URL parameters are informational only. Always verify payment status via webhook or API call. URLs can be tampered with.

Webhooks will fail. Plan for it. Retries, logging, and idempotent handlers aren’t optional. They’re the difference between “payments work” and “payments work reliably.”

Isolate early. Even if you only have one product today, building with multi-service isolation from the start means you won’t have to retrofit it later when product number two comes along.

At Acoruss, we help businesses set up exactly this kind of infrastructure - payment systems, integrations, and the operational tooliAcorussng around them. If you’re dealing with payment complexity and want a cleaner path forward, get in touch.

It sounds absurd at first, but Google Sheets paired with Google Apps Script is one of the most underrated stacks for building internal tools, MVPs, and lightweight data-driven applications. When you layer in Clasp for local development, Vite for a modern frontend, and Google Social Auth for identity - you get a surprisingly capable full-stack architecture that can go from idea to deployed app in hours, not weeks.

In this post, we’ll walk through the entire architecture: how it works, why you’d use it, what to watch out for, and where it shines.

The idea in 30 seconds

Here’s the stack:

• Google Sheets as the database

• Google Apps Script as the backend (serverless functions that talk to Sheets natively)

• Clasp for local development (write your backend in VS Code, push to Google from the terminal)

• Vite for the frontend (vanilla JS, fast builds, hot reload)

• Google Sign-In for authentication (OAuth 2.0 - the real deal)

The user opens your app, signs in with Google, and the frontend talks to an Apps Script endpoint over plain HTTP. The endpoint reads from and writes to a Google Sheet. That’s it. That’s the whole backend.

No servers. No databases. No Docker. No AWS. No monthly bill.

Wait, Apps Script can do that?

Yeah! This is the part that surprises most people.

Google Apps Script is a JavaScript runtime that lives on Google’s servers. It has native access to Sheets, Drive, Gmail, Calendar - the whole Google ecosystem. And crucially, you can deploy any script as a Web App, which gives you a URL that responds to GET and POST requests.

So you write two functions:

function doGet(e) {
  // Handle GET requests — read data from Sheets
  const action = e.parameter.action;
  
  if (action === 'getData') {
    const data = getSheetData('Data');
    return ContentService
      .createTextOutput(JSON.stringify(data))
      .setMimeType(ContentService.MimeType.JSON);
  }
}

function doPost(e) {
  // Handle POST requests — write data to Sheets
  const payload = JSON.parse(e.postData.contents);
  const sheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName('Data');
  
  sheet.appendRow([payload.name, payload.value, new Date()]);
  
  return ContentService
    .createTextOutput(JSON.stringify({ status: 'success' }))
    .setMimeType(ContentService.MimeType.JSON);
}

Deploy it, and you’ve got an API. Your frontend just does fetch(’https://script.google.com/macros/s/YOUR_ID/exec’) and gets JSON back. It works exactly like any other REST endpoint - except the data lives in a spreadsheet.

Reading from Sheets is beautifully simple. The spreadsheet is just a 2D array. You grab the first row as headers, map the rest into objects, and return JSON:

function getSheetData(sheetName) {
  const sheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName(sheetName);
  const data = sheet.getDataRange().getValues();
  const headers = data[0];

  return data.slice(1).map(row => {
    const obj = {};
    headers.forEach((header, i) => obj[header] = row[i]);
    return obj;
  });
}

That’s your ORM. That’s your database driver. Seven lines.

Clasp makes this actually pleasant

Now, I wouldn’t recommend this stack if you had to write all your code in Google’s browser-based script editor. It’s… fine for small scripts, but it’s no place to build an app.

That’s where Clasp comes in. It’s a CLI tool from Google that lets you develop Apps Script locally:

npm install -g @google/clasp
clasp login
clasp clone <your-script-id>

Now your Apps Script code is just .js files on your machine. Edit them in VS Code. Use Git. Run a linter. Then:

cd backend
clasp push                              # sends code to Google
clasp deploy --description "v2 roles"   # deploys a new Web App version

Your backend code lives right next to your frontend code in the same repo. It feels normal. It is normal - it’s just JavaScript files that happen to run on Google’s servers instead of yours.

Authentication that doesn’t make you cry

Here’s my favorite part of this whole setup: authentication is basically free.

You add Google Sign-In to your frontend with their Identity Services library. The user clicks “Sign in with Google,” and you get back a JWT token containing their verified email, name, and profile picture. Google handles the OAuth flow, the token verification, the session management - all of it.

function handleAuth(response) {
  const payload = decodeJwtPayload(response.credential);
  const email = payload.email;
  // That's it. You have a verified email address.
}

No passwords to hash. No forgot-password flow. No session tokens to manage. No auth middleware. Google just tells you who the user is, and you trust that because it’s Google.

But here’s where it gets really elegant.

Your user table is a spreadsheet tab

Instead of building a user management system, you create a Users tab in your Google Sheet:

Your backend checks the authenticated email against this list:

function isAuthorized(email) {
  const users = getSheetData('Users');
  return users.find(u => 
    u.Email.toLowerCase() === email.toLowerCase() && u.Status === 'active'
  ) || null;
}

Want to add a new user? Add a row to the spreadsheet. Want to revoke access? Change their status to “inactive.” Want to promote someone to admin? Edit their role cell.

No migration. No deployment. No admin panel to build. Your project manager can manage users from the same Google Sheet they’re already staring at all day.

Role-based access works the same way. Your backend just checks the role before allowing an operation:

if (payload.action === 'deleteRecord' && user.Role !== 'admin') {
  return jsonResponse({ error: 'Nope, admins only' });
}

It’s crude compared to a real RBAC system, but for a team of 5-50 people? It’s more than enough.

The frontend: fast and simple

On the other side, Vite gives you a modern dev experience - hot module replacement, ES modules, optimized builds - without the ceremony of React or Next.js.

Your project structure looks something like:

src/
├── main.js        # Entry point
├── auth.js        # Google Sign-In
├── api.js         # fetch() calls to your Apps Script endpoint
├── dashboard.js   # UI rendering
├── config.js      # API URLs, client IDs
└── style.css      # Tailwind + DaisyUI

The API layer is just fetch() with a wrapper:

export async function fetchData(action, email) {
  const url = `${API_URL}?action=${encodeURIComponent(action)}&email=${encodeURICoponent(email)}`;
  const response = await fetch(url);
  return response.json();
}

And with Tailwind CSS + DaisyUI, you can make it look good without writing much (or any) custom CSS. Tables, cards, buttons, modals - it’s all just class names.

The whole frontend can be deployed to GitHub Pages, Netlify, or Vercel for free. Combined with the free Apps Script hosting, your total infrastructure cost is $0.

When does this actually make sense?

This isn’t a stack for everything. But it’s great for:

Internal tools. Your team already lives in Google Workspace. The data’s already in Sheets. Just put a nicer UI on top of it.

MVPs and prototypes. You need to validate an idea by Friday. Skip the database, skip the deployment pipeline, skip the DevOps. Ship something real, with real data persistence, in a day.

Client portals. Small agencies that manage client data in spreadsheets (most of them) can build lightweight portals backed by the same data.

Approval workflows. Expense approvals, content reviews, onboarding checklists. The spreadsheet is both the database and the admin interface.

Financial tracking. Budgets, invoices, fund overviews - data that’s inherently tabular and that stakeholders want to access in spreadsheet form anyway.

Event management. Registration, attendee tracking, check-in systems. Organizers get real-time access to the data without needing a login to your app.

The risks (let’s be honest)

I’d be doing you a disservice if I didn’t talk about the sharp edges. There are real ones.

Security

Google Sheets is not a database. There’s no row-level security, no encryption at the field level, and no query parameterization. If someone has edit access to the Sheet, they see everything. Don’t store passwords, secrets, or sensitive PII here.

Your Apps Script Web App URL is also a public endpoint. If you deploy it with “Anyone” access, the only thing protecting your data is the auth check in your code. Make sure you’re validating identity server-side in every doGet() and doPost() handler.

And there’s an attack vector most people don’t think about: formula injection. If a user submits =IMPORTRANGE(...) as input and you write it to a cell, it’ll execute in the Sheet context. Sanitize your inputs. Prefix user-generated text with a single quote to force Sheets to treat it as plain text.

Scale limits

Apps Script has hard quotas. Consumer accounts get 90 minutes of total execution time per day, with a 6-minute cap per execution. You get 20,000 URL fetch calls per day. Sheets performance degrades noticeably past ~10,000 rows. And there are no transactional guarantees - two simultaneous writes can conflict.

You can mitigate some of this with CacheService (Apps Script’s built-in caching) and LockService (for serializing writes), but fundamentally, this stack wasn’t built for high concurrency or large datasets.

CORS quirks

Apps Script Web Apps have unusual redirect behavior that can trip up fetch() calls. You’ll want redirect: ‘follow’ in your fetch options, and you should test deployments carefully - each new deployment can get a different URL if you don’t pass the —id YOUR_ID when deploying with Clasp.

Vendor lock-in

Your entire backend runs on Google’s platform. If Google changes quotas, deprecates a feature, or has an outage, you’re down. Keep your code version-controlled with Clasp, and keep the business logic separable from the platform bindings so you can port it if needed.

No real audit trail

Sheets tracks edit history, but bulk writes from Apps Script may not show granular changes. If you need accountability, build your own audit log - write every operation to a dedicated “Audit” tab with timestamps and user emails.

The gains (and they’re real)

So why bother with all those caveats?

Because the upside is enormous for the right use case.

Speed. You go from idea to working app faster than with any traditional stack. No database setup, no ORM, no migrations, no server provisioning, no CI/CD pipeline. The backend is a spreadsheet and some functions.

Cost. $0 infrastructure. Google Apps Script is free within quotas. The frontend can be hosted free on any static platform. You’re not paying for anything until you outgrow the stack.

Accessibility. Your non-technical stakeholders can view, edit, and manage data directly in Google Sheets. They don’t need an admin panel - the spreadsheet is the admin panel. Everyone knows how to use a spreadsheet.

Collaboration built in. Real-time editing, comments, version history, sharing controls. These are features you’d spend weeks building in a traditional app. Sheets gives them to you for free.

The Google ecosystem. Need to send a notification email? GmailApp.sendEmail(). Generate a PDF? DriveApp.createFile(). Schedule a task? Use a time-driven trigger. It’s all one function call away.

Production-grade auth for free. Google Sign-In gives you OAuth 2.0, JWT tokens, and MFA is enterprise-grade identity without building or maintaining any of it.

Git-friendly. With Clasp, your entire application - frontend and backend - lives in one Git repo. Code reviews, branching, CI/CD will all works like any other project.

When to graduate

This stack won’t scale forever. Here are the signals that it’s time to move to a real backend:

• You’re hitting quota limits regularly

• You need JOINs, aggregations, or complex queries

• You’ve got more than ~10,000 rows of data

• You need transactional integrity for financial or compliance operations

• You have more than ~50 concurrent users

• You need sub-second response times

But here’s the thing: that’s fine. The point of this stack isn’t to build the final version of your product. It’s to build the first version which is the one that proves the idea works, gathers real user feedback, and tells you exactly what the final version needs to do.

When you outgrow the spreadsheet, you’ll have a working app and real usage data to guide your migration. That’s infinitely better than spending months building infrastructure for a product nobody wanted.

The deployment flow

For the curious, here’s the full loop:

1. Write your frontend in Vite (vanilla JS + Tailwind)

2. Write your backend in Apps Script (locally, via Clasp)

3. clasp push - sends backend code to Google

4. clasp deploy - generates a Web App URL

5. Put that URL in your frontend config

6. npm run build - produces optimized static assets

7. Deploy the frontend to any static host

8. Users sign in with Google and get a verified email

9. Frontend fetches data from the Apps Script endpoint

10. Apps Script reads/writes Google Sheets

11. Data flows back to the browser

That’s it. No servers, no databases, no DevOps team. Just a spreadsheet, some JavaScript, and a URL.

Final thought

The best architecture for your project isn’t always the most sophisticated one. Sometimes the best database is the one your stakeholders already have open in another browser tab.

Give this stack a try next time you need to build something fast. You might be surprised how far a spreadsheet can take you.

Our mission is simple: help organizations and individuals harness software, AI, and strategic technology adoption—without the heavy costs of building from scratch. From advisory to implementation, we make technology accessible, practical, and growth-focused.

What We Do

We specialize in:

• Custom Software Development – delivering tailored solutions that simplify operations and unlock new opportunities.

• AI & Automation – enabling businesses to leverage AI tools and workflows that drive efficiency and insight.

• Process Optimization & Cost Reduction – auditing current systems to cut waste and improve performance.

• Security & Trust Engineering – ensuring the technologies you rely on are safe, resilient, and future-ready.

Why This Substack?

This publication will be your window into how Acoruss and the expert partners think, build, and innovates. Expect insights on:

• Emerging trends in software and AI adoption

• Lessons from real-world implementations

• Practical guides for optimizing business processes with tech

• Updates from our products and open-source projects

We’re excited to share our journey and invite you to be part of it. Whether you’re a business leader, developer, or simply curious about the future of technology, Acoruss is here to help you harness it with confidence.

Thank you for subscribing — the journey starts here.

Subscribe now